# Noma tells LDS how a Claude Code preview could steal credentials > Source: > Published: 2026-10-15 14:56:36+00:00 # Noma tells LDS how a Claude Code preview could steal credentials Noma researcher Eli Ainhorn tells LDS that asking Claude to inspect a malicious HTML file was enough to trigger credential theft through its desktop preview in a controlled test. The demonstrated issue was file read and exfiltration, not arbitrary host code execution. He explains why the first fix missed a background execution path and reports that Anthropic shipped the final fix in August, before the research became public. A developer asks a coding assistant to look at a test-coverage report. The assistant reads the file and displays a preview. In Noma Security's SneakPeek demonstration, that preview was enough to run embedded JavaScript and send readable credentials from the developer's computer to an external server. The distinction matters for anyone reviewing unfamiliar code with an AI assistant. A permission prompt for editing a file does not necessarily govern what the surrounding application does when it displays that file. Eli Ainhorn, Senior AI Vulnerability Researcher at Noma Security, clarified the minimum trigger in written answers to Let's Data Science: "One action: the developer asks Claude to look at the file and the preview pane renders it automatically." Noma says Anthropic fixed the issue before the research was published. Ainhorn reports that the final fix shipped through auto-update in Claude Desktop 1.30096.1 on August 17, 2026. His account concerns the vulnerable application tested during the research, not a claim that an updated installation remains exploitable. ### The preview did more than show a file Ainhorn said Noma's first demonstration involved an edit that the developer approved. The researchers subsequently triggered the same preview behavior by asking Claude to inspect the file, without an edit or an additional permission prompt. Noma has updated its [public research](https://noma.security/noma-labs/sneakpeek-how-the-preview-pane-in-claude-code-desktop-can-exfiltrate-your-data) to reflect that simpler sequence. That does not make the attack interaction-free. The scenario still involves a developer using an untrusted project and asking the assistant to inspect attacker-controlled HTML. What disappeared from the minimum sequence was the separate approval to change a file. The model did not need to follow a hidden instruction. According to Ainhorn, it read the requested file; the application then rendered the content and executed its script. The security failure lay in the protections around that rendering step. For teams building coding tools, this separates two reviews that can otherwise become confused. Checking what the model proposes to change is useful, but it does not establish that the application's preview treats untrusted content safely. ### File size changed the security protections Ainhorn described two rendering paths in the tested desktop application. Smaller HTML files loaded through a data URL with restrictions on their origin and script execution. Files larger than 256 KB took a different path: the application wrote them to a temporary file and loaded them from disk. That second path did not receive the same Content Security Policy, the rule intended to block scripts, and its request filtering did not prevent the local-file reads used in the demonstration. Noma's script could read files accessible to the user account and transmit their contents. The important boundary is the specific application's configuration. A local-file URL is not, by itself, proof that every browser or preview can read an entire computer. Here, Noma describes a combination of missing protections in the desktop renderer. Ainhorn said the researchers demonstrated theft of SSH keys, cloud credentials, package-publishing tokens and other configuration secrets. That access was bounded by the permissions of the user account running the application. It should not be described as overriding every operating-system restriction. ### Why the first fix was not enough The first patch stopped the original direct file-read method in the main page, according to Ainhorn. A retest moved the request into a Web Worker, a background browser execution context, and found that the protection did not cover that route. Ainhorn told LDS: "So the fix was scoped to where the original payload ran but didn't account for the browser's ability to spawn additional contexts." The supplied correspondence excerpts show the vendor acknowledging an incomplete fix after that retest. Ainhorn says the eventual fix covered both the original method and the Worker bypass, and that Anthropic closed the report. LDS has not independently reproduced the vulnerability or retested the patched application. The excerpts supplied with the interview support the account of the first fix's limitation; they are not a complete final regression-test record. The engineering lesson is to test the intended restriction across every relevant rendering and execution path. A test that confirms the original demonstration no longer works can pass while another route still reaches the same protected resource. ### File theft is not the same finding as host code execution The impact needs equally careful wording. Ainhorn explicitly said that Noma did not demonstrate arbitrary code execution on the host. The observed exploit read files through the renderer and sent their contents out; it did not demonstrate running shell commands on the machine. A vendor-response excerpt supplied by Noma describes an 8.7 High severity assessment and treats the impact as equivalent to host code execution for that assessment. That is a severity judgment, rather than a different demonstrated capability. Stolen credentials could enable further compromise of systems they authorize. Whether that happens depends on the credentials, their privileges and the protections around those systems. It should not be presented as a tested outcome for every exposed machine. Ainhorn also drew a clear limit around the platform evidence: "We confirmed exploitation on macOS with Claude Desktop 1.17377.2 running Electron 42.5.1, and that's the only platform we tested on." Windows and Linux were not tested. The interview therefore does not establish a complete affected-platform or version list. Nor should the desktop version numbers be confused with the Claude Code command-line tool. Ainhorn distinguishes that text-based interface and the web application's architecture from the tested desktop preview; that is not an independent security assessment of either interface. ### What developers can change Ainhorn's recommendations go beyond updating the application. He points to long-lived credentials on developer machines, excessive token permissions and limited visibility into which AI tools and integrations people are using. Short-lived credentials and narrowly scoped tokens reduce what a stolen secret can authorize. An inventory of coding tools, their versions and their access gives a team something concrete to patch and monitor. If exposure is suspected, the affected credentials need to be assessed and revoked or rotated as appropriate. For builders of preview features, our reading is that display behavior belongs in the security review alongside tool calls and proposed edits. Tests should cover different file sizes and loading paths, background execution, access to local resources and outbound communication. Harmless test files can help verify those boundaries without using real credentials. Those are complementary controls. Restricting a token does not repair a renderer, and repairing a renderer does not remove the consequences of credentials already stolen. ### What to watch At the time of the written reply, Ainhorn said the CVE and GitHub advisory were still awaiting publication. Those records could provide additional vendor-facing detail on affected versions and remediation. The useful follow-up is the documented scope and regression evidence, not an assumption that every Claude interface shared the same flaw. Noma says it was unaware of exploitation outside its controlled research. That describes the researchers' knowledge; it is not proof that no other exploitation occurred. ### Reporting note This LDS Exclusive is based on six written answers supplied directly to Let's Data Science and attributed to Eli Ainhorn, Senior AI Vulnerability Researcher at Noma Security, alongside Noma's public research and supplied vendor-correspondence excerpts. Patch status and the research findings are attributed to Noma. LDS did not independently exploit the issue or verify the final fix. The implications for engineering teams are LDS's analysis. ## Key Points - 1The minimum demonstrated trigger was asking Claude to inspect malicious HTML; an edit and separate approval were not required. - 2The researchers confirmed file theft on one macOS desktop configuration. They did not demonstrate arbitrary host code execution. - 3The first patch missed a background execution context. Noma reports that the final fix shipped in August, before public disclosure. ## Scoring Rationale Direct researcher answers clarify the actual trigger, tested scope and incomplete first patch, giving developers a practical way to distinguish model behavior from preview-renderer security. ## Sources Original reporting, with the public references used alongside it. LDS Exclusive Reporting based on written answers given directly to Let's Data Science by **Eli Ainhorn, Senior AI Vulnerability Researcher, Noma Security**. Practice interview problems based on real data 1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with. [Try 250 free problems](https://letsdatascience.com/problems)