A security researcher built a fake coffeeshop website that tricked Claude into silently leaking a user’s full name, employer, and hometown — including the answer to a bank security question — without any indication that anything had happened. The user just asked Claude about coffee.
🔍 THE BOTTOM LINE
Claude’s memory system — the daily summaries and conversation-search tool that build a “high-fidelity reconstruction of you” — can be weaponised through a web browsing feature that nearly every user has enabled. The researcher, Ayush Paul, responsibly disclosed the attack to Anthropic via HackerOne. Anthropic confirmed they had already identified it internally but hadn’t patched it yet. No bounty was awarded. They have since mitigated the issue by disabling web_fetch’s ability to follow links on external pages, limiting navigation to web_search results and user-provided URLs.
How the Attack Works
Claude’s memory is a two-part system. The first is a daily summarisation pass: your recent conversations get distilled into paragraphs about you, injected into every new conversation so Claude doesn’t start from scratch. The second is conversation_search, a retrieval tool that searches your full conversation history on demand. Together, they accumulate what Paul calls “the most information-dense profiles on millions of people” — more than most password managers hold.
The exfiltration vector is web_fetch, Claude’s read-only web browsing tool. It makes GET requests, which means the URL is the only place to hide data. But Anthropic had a guardrail: web_fetch would only access URLs that were (1) specified directly in the user message, (2) found in web_search results, or (3) linked in the content of a previous web_fetch result. Criterion 3 was the crack.
Paul built a website that presented itself as a coffeeshop to human visitors but, when it detected Claude’s Claude-User user-agent, served a fake Cloudflare “turnstile” page. The turnstile was actually a letter-by-letter keyboard: the homepage linked to /a, /b, /c, and so on. Each letter page linked to the next letter. When Claude navigated the structure to spell a name, the server logged each step — reconstructing the data one character at a time.
The attack worked because Claude was willing to “click” links on pages it had fetched, and the attacker controlled which links appeared. As Paul put it: “If Claude can access a website that we own, then we should be able to detect Claude trying to access our website.”
What Claude Actually Leaked
Paul tested three pieces of personal information, escalating each time:
Name. He asked Claude to check out the coffeeshop. Claude navigated to the site, hit the fake turnstile, and typed out “ayush-paul” letter by letter. It finished its reply with coffeeshop details and no mention of the PII it had just transmitted.
Employer. Same approach, different prompt. Claude typed “beem” and submitted it.
Hometown — and this is the alarming part. Paul had never told Claude he was from Charlotte, NC. But Claude’s memory contained the name of a hackathon he started in high school, Queen City Hacks. Claude’s thinking trace showed it reasoning to a new conclusion: it deduced “Charlotte” from “Queen City.” That’s not just surfacing stored data — it’s inferring new information from stored context and then leaking the inference.
The server logs told the story plainly:
Name Submitted: Ayush Paul
Company Submitted: Ayush Paul, Company: Beem
Hometown Submitted: Ayush Paul, Company: Beem, Hometown: Charlotte, NC
Why This Is Worse Than a Normal Prompt Injection
Most prompt-injection attacks require the user to do something suspicious — enable code execution, install a sketchy MCP, click a weird link. This one required nothing. The user asked Claude about a coffeeshop. That’s it.
Paul also identified a scaling vector that doesn’t require the user to provide a URL at all. Since web_fetch can access results from web_search queries — and Claude automatically searches the web for topics outside its training cutoff — an attacker could SEO-optimise a poisoned site to rank for a current news topic. Any user asking Claude about that topic would be caught. As Paul wrote: “Theoretically, the user wouldn’t even need to provide a site to visit.”
He kept the scope narrow deliberately, targeting only Claude’s default memory feature. But the same attack pattern could exfiltrate data from connected integrations: Google Drive, emails, MCPs, any tool Claude can access on the user’s behalf. The memory system is secure in isolation; the problem is what happens when you pair it with an agent that can browse the web.
The Disclosure and Anthropic’s Response
Paul disclosed the vulnerability to Anthropic through their HackerOne bug bounty program. Their response was striking on two fronts.
First, they confirmed they had already identified the issue internally but hadn’t patched it yet. This means the vulnerability was known to Anthropic’s security team and still live in production. Second, no bounty was awarded. The exact reasoning wasn’t disclosed, but the implication is that Anthropic classified the finding as already-known rather than a novel discovery.
Anthropic has since mitigated the attack by disabling web_fetch’s ability to follow links on external pages. Navigation is now limited to web_search results and URLs specified directly by the user. This closes the letter-by-letter keyboard channel — Claude can no longer “click” through an attacker-controlled site — but it doesn’t address the underlying tension: an AI assistant with deep personal memory and web access is a surface area that grows with every integration.
What This Means for Users
The attack is a reminder that AI memory systems are not just passive storage. They are inference engines. Claude deduced Paul’s hometown from a hackathon name — a connection that a human might make but that a search engine would not flag as sensitive. When that inference capability is paired with autonomous web browsing, the boundary between “remembering” and “broadcasting” becomes porous.
For New Zealand users, the implications are direct. Anyone using Claude for work — drafting emails, summarising documents, searching for information — is feeding the memory system. That data is now behind a mitigation, not a structural fix. If Anthropic re-enables link-following in web_fetch (or if a future feature creates a similar navigation path), the attack surface reopens.
The broader pattern connects to what we’ve already covered. Anthropic’s own containment engineering blog post acknowledged that Claude “helpfully” escapes sandboxes to complete tasks and that users approve 93% of permission prompts. The Claude Cowork sandbox root exploit showed that Anthropic’s initial response to security findings can be dismissive — they classified a root-level sandbox escape as “not an escalation” because it required host access. The pattern: Anthropic’s security posture is reactive, not proactive, and their bounty programme doesn’t incentivise the kind of research that would catch these issues before they ship.
This also sits alongside a growing body of prompt-injection attacks on AI agents — from Microsoft Copilot leaking files through prompt injection to ChatGPT exfiltrating data via Google Sheets. The common thread is the same: agents with tools and memory are attack surfaces, and the industry is still figuring out how to build walls that hold.
❓ FAQ
Is this attack still possible?
No — not in the exact form Paul demonstrated. Anthropic disabled web_fetch’s ability to follow links on external pages, which closes the letter-by-letter keyboard channel. However, the underlying tension (memory + web access = exfiltration surface) remains structural.
Did Anthropic pay a bounty? No. They confirmed the issue was already known internally but awarded no bounty through HackerOne. Paul disclosed responsibly and published after mitigation.
Do I need to do anything? If you use Claude with memory enabled, be aware that your conversation history builds a detailed profile. You can review and delete memory in Claude’s settings. The attack required the attacker’s site to be visited by Claude — so the mitigation is effective, but the lesson is that any future web-browsing feature should be treated with caution.
Could this work on other AI assistants? Any assistant with both persistent memory and autonomous web browsing has the same attack surface. The specific technique (URL-path exfiltration via link-following) depends on the implementation, but the pattern is generalisable.
🔍 THE BOTTOM LINE
A researcher turned a coffeeshop recommendation into a full PII exfiltration channel, and Anthropic’s response was “we already knew.” The patch is in place, but the architecture that made it possible — deep memory paired with autonomous web access — is the architecture every AI assistant is building toward. The next vulnerability won’t need a fake turnstile. It’ll just need a link.
