Claude Desktop (macOS): malicious file in a Cowork folder could run commands on the host

What it is

GHSA-v234-4jrq-mgg6 rates the Claude Desktop (macOS) Cowork block-list gap High, CVSS 8.5 (v4). The summary you have describes the mechanism; what it omits is the severity breakdown and, more importantly, who still has to act.

Preconditions / Affected

The CVSS v4 vector is worth reading because it clarifies what the "user opens the file" step actually costs an attacker:

• Attack Vector: Local, Attack Complexity: Low, Attack Requirements: None, Privileges Required: None.
• User interaction: Passive — not "active/deliberate." The rating treats the open as something a user can be led into, not a knowing "run this" click.
• Vulnerable System impact: Confidentiality / Integrity / Availability all High.
• Subsequent System impact: all None — the 8.5 scores the file-handling flaw on its own, explicitly not the combined VM-escape chain. So the real-world worst case (VM-privileged code triggering the open with no interaction via CVE-2026-43284) is worse than the headline number suggests, not captured by it.

The underlying weakness is CWE-style incomplete-blocklist: a protection relying on an enumerated deny-list that missed an entry.

What to do

The single operational fact the summary does not surface:

Users on standard Claude Desktop auto-update have already received these fixes. Users performing manual or managed updates are advised to update to the latest version.

So the action item is scoped: auto-update installs are already patched; manually-managed or MDM-managed fleets are the ones that need to be pushed to ≥ 1.15962.0. If you are the engineer deciding whether to act, that is the deciding line — check your update channel, not your version guess.

One dated fact for sequencing: the VM-kernel half was fixed earlier, in 1.11847.5, released 9 June 2026; the block-list half lands in 1.15962.0. A fleet sitting between those two versions has the patched kernel but the still-vulnerable block-list.

Caveats

The advisory gives no file-type name, no proof-of-concept, and no detection query — only the affected/patched version boundaries and the CVSS reasoning above. Everything actionable here is version- and update-channel-based.