SneakPeek disclosed: Check Claude Desktop patches and past exposure

On October 14, 2026, Noma disclosed SneakPeek, a flaw that let malicious HTML rendered in Claude Code Desktop's preview pane read local files. Noma identifies Claude Desktop 1.30096.1 and later as fixed on August 17. Today's event is the disclosure of an already-patched vulnerability. Check which Desktop installations missed the fix, then decide whether their earlier preview activity needs investigation.

The fixed-version claim comes from Noma's report, which lists the GitHub advisory and CVE as pending publication. General Analysis has not reproduced the exploit or independently verified the patch. The procedure below combines that disclosure with Anthropic's deployment documentation and our recommendations for an enterprise response.

The preview is an execution surface#

Noma describes a size-dependent rendering path: HTML files over 256KB loaded through file:// without the script restrictions applied to smaller previews. A static-file request filter also failed to cover that path. The first mitigation missed requests from Web Workers; Noma reports that the final fix addressed the remaining issues.

A developer can approve a harmless-looking edit while existing content in the rendered document performs a separate action. The proposed diff covers only the edit; the preview renders the document around it too.

Electron's security guidance explains why this boundary matters: local pages served through file:// have privileges beyond ordinary web content. It recommends a custom protocol that serves only intended files. That is architectural context, not independent confirmation of Anthropic's implementation or fix.

For response planning, keep the renderer in scope alongside agent tools. A Bash approval rule or a model refusal is insufficient evidence about a different process's file access. The broader deployment controls belong in our coding-agent security guide.

Verify the Desktop build and who updates it#

Inventory the Desktop app independently of the terminal CLI. For each installation, record the device, user, operating system, installation location, installed version, update source, and version observed after relaunch. Use a current approved Desktop release; the reported historical minimum helps identify installations needing attention.

Anthropic's Windows deployment guide distinguishes two update owners:

• If MDM owns versions, administrators set disableAutoUpdates to 1 and distribute new MSIX builds themselves. An assigned package must therefore advance when the approved release changes.
• If the app owns updates, leave that policy unset. Anthropic recommends version-aware package detection so MDM continues to recognize the installation after the app updates itself.

Check the effective policy as well as the package assignment. An MDM console showing a successful installation can describe an old package, while an exact-version detection rule can misclassify a newer self-updated app.

This read-only PowerShell example lists the package registered for the current user. Run it through your normal endpoint inventory process; repeat in the appropriate user context where needed. It neither installs an update nor proves which version an existing process has loaded.

Code source: Anthropic's Windows package detection guidance, adapted to display inventory fields.

On macOS, Anthropic documents both user and system Applications locations. System installations can require administrator permissions to update. Include both locations in inventory and resolve update failures through the deployment owner; do not infer that the copy a user launches matches the one MDM replaced.

An update can be prepared while the old process keeps running. The Desktop policy reference describes autoUpdaterEnforcementHours as the delay before a forced restart applies a prepared update, with a default of 72 hours. Arrange a controlled restart and record the observed version afterward. Changing that delay does not repair a failed download or a pinned MDM package.

Investigate the period before the verified update#

A device running an affected build is a reason to scope an investigation, not proof that someone stole its credentials. Reconstruct its actual installed-version history and relevant repository work. The August patch date does not establish when that particular machine updated, and the October disclosure date is not the start of its possible exposure.

Preserve available records before routine cleanup removes them. Handle suspect HTML as evidence through the incident team's approved static-analysis process; reopening it in the affected preview is unnecessary for this review.

Use the following matrix to assign evidence collection. It is a proposed investigation plan, not a list of indicators observed by General Analysis.

Join these records by device, user, process, and time. Keep local timestamps and time zones explicit. An agent transcript may explain why an HTML file was opened, but it should not be treated as a complete account of renderer behavior. Our Claude Compliance API guide covers the collection's scope and exclusions; preserve endpoint and downstream evidence separately.

Where evidence supports credential exposure, revoke or rotate the affected credentials through their owners and investigate subsequent use. If telemetry is missing, record the unresolved period and let the incident owner decide whether the privileges at risk warrant precautionary revocation. Keep that decision separate from what the logs establish.

Close the patch task with a separate exposure decision#

The platform owner should be able to show the approved package, effective update policy, completed relaunch, and observed Desktop version for each managed installation. Leave unreachable devices or unverified launch paths assigned rather than counting them as patched.

The incident owner should record the period reviewed, available evidence, any suspicious activity, credential actions, and unresolved gaps. A fixed app can return to approved use while a historical investigation remains open.