{"slug": "noma-tells-lds-how-a-claude-code-preview-could-steal-credentials", "title": "Noma tells LDS how a Claude Code preview could steal credentials", "summary": "Noma Security researcher Eli Ainhorn disclosed that asking Claude to inspect a malicious HTML file was enough to trigger credential theft through the Claude Code desktop preview pane, with the vulnerability fixed in Claude Desktop 1.30096.1 via auto-update on August 17, 2026. Ainhorn said files larger than 256 KB bypassed the Content Security Policy applied to smaller data-URL renders, letting embedded JavaScript read SSH keys, cloud credentials and package-publishing tokens within the user account's permissions. The demonstration showed file read and exfiltration rather than arbitrary host code execution, and Anthropic shipped the final fix before the research became public.", "body_md": "# Noma tells LDS how a Claude Code preview could steal credentials\n\nNoma 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.\n\nA 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.\n\nThe 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.\n\nEli 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.\"\n\nNoma 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.\n\n### The preview did more than show a file\n\nAinhorn 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.\n\nThat 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.\n\nThe 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.\n\nFor 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.\n\n### File size changed the security protections\n\nAinhorn 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.\n\nThat 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.\n\nThe 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.\n\nAinhorn 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.\n\n### Why the first fix was not enough\n\nThe 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.\n\nAinhorn 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.\"\n\nThe 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.\n\nLDS 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.\n\nThe 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.\n\n### File theft is not the same finding as host code execution\n\nThe 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.\n\nA 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.\n\nStolen 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.\n\nAinhorn 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.\"\n\nWindows 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.\n\n### What developers can change\n\nAinhorn'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.\n\nShort-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.\n\nFor 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.\n\nThose are complementary controls. Restricting a token does not repair a renderer, and repairing a renderer does not remove the consequences of credentials already stolen.\n\n### What to watch\n\nAt 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.\n\nNoma says it was unaware of exploitation outside its controlled research. That describes the researchers' knowledge; it is not proof that no other exploitation occurred.\n\n### Reporting note\n\nThis 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.\n\n## Key Points\n\n- 1The minimum demonstrated trigger was asking Claude to inspect malicious HTML; an edit and separate approval were not required.\n- 2The researchers confirmed file theft on one macOS desktop configuration. They did not demonstrate arbitrary host code execution.\n- 3The first patch missed a background execution context. Noma reports that the final fix shipped in August, before public disclosure.\n\n## Scoring Rationale\n\nDirect 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.\n\n## Sources\n\nOriginal reporting, with the public references used alongside it.\n\nLDS Exclusive\n\nReporting based on written answers given directly to Let's Data Science by **Eli Ainhorn, Senior AI Vulnerability Researcher, Noma Security**.\n\nPractice interview problems based on real data\n\n1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.\n\n[Try 250 free problems](https://letsdatascience.com/problems)", "url": "https://wpnews.pro/news/noma-tells-lds-how-a-claude-code-preview-could-steal-credentials", "canonical_source": "https://letsdatascience.com/news/noma-tells-lds-how-a-claude-code-preview-could-steal-credent-9cd1c7ab", "published_at": "2026-10-15 14:56:36+00:00", "updated_at": "2026-10-15 15:21:08.103812+00:00", "lang": "en", "topics": ["ai-safety", "ai-tools", "ai-agents", "developer-tools"], "entities": ["Noma Security", "Eli Ainhorn", "Anthropic", "Claude Code", "Claude Desktop", "Let's Data Science"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/noma-tells-lds-how-a-claude-code-preview-could-steal-credentials", "markdown": "https://wpnews.pro/news/noma-tells-lds-how-a-claude-code-preview-could-steal-credentials.md", "text": "https://wpnews.pro/news/noma-tells-lds-how-a-claude-code-preview-could-steal-credentials.txt", "jsonld": "https://wpnews.pro/news/noma-tells-lds-how-a-claude-code-preview-could-steal-credentials.jsonld"}}