MemGhost: an email that rewrites an AI agent's memory
arXiv paper: one crafted email talks a memory-enabled AI agent into writing attacker-supplied 'facts' into its memory files. Future sessions load them.
The paper is called When Claws Remember but Do Not Tell, dropped on arXiv on July 6 and picked up by The Hacker News last week. The primitive is small. An agent that reads a user’s inbox and holds persistent memory across sessions gets a mail whose visible body is unremarkable. The hidden portion instructs the agent — not the human recipient — to write attacker-supplied facts into the memory files the agent loads at the start of every session. The reply the user sees says nothing about it. The next session, and the one after that, the poisoned facts are just part of what the agent believes.
That is the whole attack. No shellcode, no CVE, no zero-day in a mail client. It is an instruction reaching a component that was designed to keep information around and was not designed to tell trusted apart from untrusted claims about the user. The layer story here is old — mail body carries user-controlled bytes into a program that acts on them, sendmail wrote the original version of it in the 1980s. The new part is that the program is a language model with tool access, and the mutable state it writes to is a plain text file with a filename like user_facts.md.
The researchers reported success rates against real agent frameworks. The primary target was OpenClaw in background mode: 87.5% against GPT-5.4, 71.4% against Claude Code SDK on Sonnet 4.6. Two other agent frameworks and vector-based memory stores were also tested. All of it in isolated lab environments with fake inboxes; no in-the-wild abuse reported, and disclosure went to the affected model and agent makers before publication.
OpenClaw’s response, quoted in The Hacker News writeup, is worth pausing on. Their argument: the tested configuration is not the one they recommend. They advise running mail through a separate reader agent stripped of memory, file, and shell tools, which then hands the main agent only a summary — a design the paper did not model. They also confirmed they are weighing memory-write controls: provenance tagging on stored facts, audit logs on every memory write, and a confirmation prompt before external content becomes a persistent belief. None of that is shipped yet.
The mitigations are not exotic. Any deployment with an inbox connector should look at what the mail-reading component is allowed to touch. If the same agent reads mail and writes memory, that is the same class of trust boundary an MTA-to-shell pipe was thirty years ago — just in a shape the language-model tooling encourages you to build. Tag the source of every memory write; log them; require user confirmation before an externally-triggered write persists. This is the second time in a week we have covered a prompt-injection primitive slipping past the review layer; it will not be the last. It pairs closely with the earlier OpenClaw disclosure where a chat message reached the host.
The specific action: audit what your agent’s memory directory contains, and who last wrote to it. If the answer to “who” is “any inbound mail,” that is the bug.
Found this useful? Share it.


