A Researcher Tricked Claude Into Spelling Out a User's Private Data, One Letter at a Time
A researcher's week-old proof-of-concept — tricking Claude's assistant into spelling a user's private data into an attacker's server logs, one letter at a time — went viral this week. It's patched, the researcher reports. The structural problem it illustrates is not.

The takeaway: A security researcher published a working demonstration of tricking Claude's consumer assistant into quietly exfiltrating a user's stored personal details — name, employer, an inferred hometown — to an attacker's server, with no visible sign anything had happened. The write-up is a week old and the specific hole has, by the researcher's account, been closed; it went viral this week when it hit Hacker News' front page. It's worth understanding not as a live emergency but as the clearest recent illustration of a structural problem every memory-plus-browsing AI assistant now shares.
What was demonstrated
In a post titled "The Memory Heist", dated 9 July, Ayush Paul — a Berkeley student who builds AI memory systems — showed how a booby-trapped web page could turn Claude's own tools against its user. He scoped it carefully, in his words, to "the main everyday assistant (claude.ai, not Claude Code)," and he ran it against his own data, not a stranger's.
The pieces fit together like this. Claude's assistant keeps a memory of past conversations. Its web_fetch tool can retrieve web pages — and, critically, can follow links that appeared on a page it already fetched. Anthropic had already anticipated the obvious abuse: Claude cannot invent a URL like evil.com/[your-name] out of thin air. But "follow a link that was on the last page" is a permitted action, and that turned out to be enough.
Paul built a site that served an innocuous coffee-shop page to ordinary browsers, but — detecting Claude by the user-agent its fetcher declares — served it instead a fake Cloudflare bot-check screen carrying hidden instructions: the assistant, it claimed, could authenticate itself by spelling out its user's name, navigating "letter by letter" through a tree of links (/a, then /ay, then /ayu…). Each click was a character, and each character landed in the attacker's server logs. Claude complied without pausing to ask permission; Paul describes watching it "typing out my name letter by letter" while its visible reply mentioned nothing but coffee. Follow-up pages asked for the user's employer and, framed as a security check, the city they grew up in. The server log at the end read: name, company, hometown. The unsettling detail: he had never told Claude his hometown — the assistant deduced "Charlotte, NC" from the name of a high-school hackathon he'd once mentioned.
Why this is a category, not a one-off
The mechanism here has a name. A year ago the developer Simon Willison coined "the lethal trifecta" for the combination that makes AI assistants exploitable: access to private data, exposure to untrusted content, and a way to send data out. "The Memory Heist" is a near-perfect specimen — private data (the memory), untrusted content (the poisoned page), and an exfiltration channel (web_fetch's outbound requests) — and no amount of cleverness in the model resolves it, because each of the three ingredients is a feature someone asked for.
This is also not the first time an assistant's memory has been turned into a leak. In 2024 the researcher Johann Rehberger demonstrated "SpAIware", planting persistent instructions in ChatGPT's long-term memory; the same era produced a wave of "markdown image" exfiltration tricks across ChatGPT, Google's Bard, Microsoft Copilot and others, where stolen data rode out inside an image URL that leaked the moment it rendered. Vendors have steadily closed those channels. What makes Paul's work notable is that it found a fresh channel after the obvious ones were shut — defeating Anthropic's existing URL-construction restriction rather than exploiting an already-patched gap.
What's fixed, and what to be careful claiming
Here the piece needs discipline, because the write-up is a single source on its own remediation. According to Paul, he disclosed the flaw to Anthropic through its HackerOne programme; the company "confirmed they had identified it internally but hadn't yet patched it," and "no bounty was awarded." He then reports: "Anthropic disabled web_fetch's ability to follow links on external pages, limiting navigation to web_search results and user-provided URLs." There is no dated timeline in the post, and — importantly — no on-the-record Anthropic statement; every account of what Anthropic did or said traces back to the researcher.
We can independently confirm the shape of Anthropic's defensive model, if not this specific consumer-app change. Anthropic's public documentation for the web_fetch tool warns, verbatim, that enabling it "in environments where Claude processes untrusted input alongside sensitive data poses data exfiltration risks," and that "to minimize exfiltration risks, Claude is not allowed to dynamically construct URLs." That matches Paul's account of the constraint he had to work around — but the docs describe the developer API, a different surface from the claude.ai assistant he attacked, and Anthropic has published no advisory or changelog for the consumer fix. So: the mitigation is plausible and consistent with how Anthropic says its tools work, but it is the researcher's word, not a vendor confirmation.
Two further claims in the post deserve the same caution. Paul writes that "the same trick reaches anything else Claude can pull for you: your Drive, your inbox, some MCP you wired up months ago and forgot about" — but he demonstrated only the memory case; the reach into connected apps is asserted by extension, not shown. And his suggestion that a victim "wouldn't even need to provide a site to visit" — an attacker could SEO-optimise a trap page to catch anyone asking about a topical event — he himself prefixes with "theoretically." Real risks worth flagging; not demonstrated facts.
The uncomfortable part
The demonstration is patched, narrow, and self-tested — easy to file as a curiosity. The reason it earns coverage is the structural point underneath it. As assistants accumulate detailed memories and gain tools that reach the open web and your connected accounts, the lethal trifecta stops being a lab scenario and becomes the default configuration. The individual holes get closed one at a time — arbitrary URLs, then markdown images, now fetch-link-following — but the shape keeps returning, because the capabilities that make an assistant useful are exactly the capabilities that make it exploitable. The right question for anyone running these tools on real data isn't "has this specific trick been fixed" but "what can my assistant read, and where can it send things." For readers building on agent tooling, that pairs directly with the trust questions raised by this week's coding-CLI data-exfiltration findings.
Ask Relay — he reads every question himself and replies personally by email.
