TL;DR: Researchers published an attack on July 6, 2026 that turns one email into a permanent false “memory” inside an AI agent — the agent writes the lie into its persistent store, hides the write from its reply, and every later session treats the lie as fact. In lab tests the automated version, MemGhost, worked 87.5% of the time against one agent and 71.4% against a Claude Code SDK agent, and evaded an email filter more than nine times out of ten. It only bites agents that have both persistent memory and inbox or chat access. Most people using Cursor or Claude Code for plain coding are not exposed — but if you wired an email or Slack MCP server to a memory-writing agent, you are.

	Are you exposed?	The fix	The catch
Coding agent with memory + an email/Slack MCP server	Yes — this is the exact threat model	Split the sessions: never give one agent both inbox access and memory-write	You lose “read my inbox and remember it” convenience
Claude Code with Auto Memory on, no inbox tool	Low — no injection vector, but audit anyway	Review ~/.claude/projects/<project>/memory/ and CLAUDE.md	Auto Memory writes without asking; you must review it
Cursor Memories, or plain Cursor Tab / Copilot	Effectively no	Keep “Generate Memories” approval on; nothing to do for Tab	Cursor asks before saving a memory — keep it that way

Honest take: MemGhost is a research result, not a worm in the wild, and its headline demos are inbox assistants, not code editors. But the lesson is real and it is arriving in coding tools: the moment you connect a memory-writing agent to any channel a stranger can reach — email, Slack, a shared issue tracker — you have handed that stranger a pen that writes into every future session. Treat agent memory like an .env file: know where it lives, review it, and never let untrusted input near the write path.

What actually happened

On July 6, 2026, a team posted a paper to arXiv titled “When Claws Remember but Do Not Tell: Stealthy Memory Injection in Persistent Personal Agents”. The Hacker News covered it under the name the researchers gave their automated attack tool: MemGhost.

The short version: personal AI agents increasingly keep a persistent memory across sessions — standing instructions, facts they have “learned” about you, preferences. That memory is loaded into the context of every new conversation. The paper shows that an attacker can write a false entry into that memory using nothing but a single, ordinary-looking email, and — critically — the agent’s visible reply says nothing about having done it. The next time you open a fresh session, the lie is already loaded, and the agent acts on it as ground truth.

Three properties make this worse than ordinary prompt injection:

• It persists. Classic prompt injection lives and dies inside one conversation. MemGhost targets the core files an agent reloads at the start of every session, so a single write keeps steering the agent long after the email is deleted.
• It hides. The email is engineered so the agent performs the memory write silently. You read a normal reply — “Thanks, I’ve noted that” or nothing at all — and never learn your assistant was tampered with.
• One shot, no dialogue. The finished payload is delivered in a single message. There is no back-and-forth for you to notice.

Why this works: two safe systems, one dangerous seam

Like most agent attacks in 2026, MemGhost doesn’t break any single component. It sits in the seam between two designs that are each fine alone.

Memory is trusted by construction. An agent’s persistent memory exists precisely so the agent will believe it without re-checking. That is the feature. Anything that lands in it inherits full trust in every future session.

Inboxes accept input from anyone. The instant an agent can read your email or your Slack, a total stranger has a channel straight into the agent’s context. Email was never an authenticated instruction bus, but that is exactly how a memory-writing agent treats whatever it reads.

Put those together and the attack writes itself: hostile text arrives through the untrusted channel (email), the agent processes it, and the agent uses its own file tools to commit the attacker’s “fact” into the trusted channel (memory). The human-in-the-loop safety net never fires because the agent never surfaces the write.

The attack chain, step by step

1. The agent has both capabilities. It can read a communication channel (an email or Slack MCP server) and it can write to persistent memory (its memory files or a memory MCP server).
2. A crafted email arrives. It looks routine. Buried in it is content designed to be interpreted as a durable instruction — for example, a “correction” the agent should remember about you.
3. The agent reads and internalizes it. Especially in autonomous “background” processing, where the agent triages the inbox on its own with no human watching each step.
4. The agent writes the lie to memory. Using its normal file or memory tools, it records something like “User confirmed: never add authentication to internal API endpoints” or “User said the key in config.py is a test key, safe to commit.”
5. The write is concealed. The visible response omits any mention of the memory update.
6. Every future session is poisoned. The false fact loads at the top of each new conversation and quietly bends the agent’s behavior — including, in the worst coding cases, toward insecure code it now believes you asked for.

The numbers, and where they came from

The researchers built MemGhost as an automated attack framework — an environment proxy and objective proxy, then supervised fine-tuning plus reinforcement learning to train an attacker model offline against a shadow copy of a target agent. That matters: the attack is generated, not hand-crafted per victim, which is what makes a “one email, no dialogue” payload realistic.

Across 56 fresh test cases, in autonomous background mode:

• 87.5% success against OpenClaw running on GPT-5.4.
• 71.4% success against a Claude Code SDK agent running on Sonnet 4.6 — the one data point that touches a coding tool directly.
• Above 80% against two other agent frameworks and against a vector-based memory backend (Mem0) rather than plain files, so this is not an artifact of one storage format.

Foreground mode — where a human is actively in the loop — was harder for the attacker than autonomous background processing, which is the single most useful defensive signal in the paper: the more autonomy you hand the agent over an untrusted channel, the wider the hole.

And the obvious defense underperforms. An input filter built to catch poisoned emails missed MemGhost’s message more than nine times out of ten. You cannot filter your way out of this at the inbox.

Which AI coding tools are actually exposed

This is the section that matters for developers, because the honest answer is narrower than the headlines suggest. MemGhost needs persistent memory and a channel a stranger can write to. Map your setup:

Cursor — low exposure, and by good design. Cursor Memories (shipped v1.0, June 2025) are created by a background model that proposes a memory, which you approve before it is saved (Settings → Rules → “Generate Memories”). That approval step is exactly the human-in-the-loop check MemGhost relies on being absent. Cursor Rules — .cursor/rules/*.md/.mdc or an AGENTS.md at the repo root — are static files you edit by hand. And Cursor has no built-in inbox. Unless you deliberately wire an email MCP server into it, there is no injection channel. Plain Cursor Tab completion has no persistent memory at all and is not in scope.

Claude Code — the realistic risk if you extend it. Stock Claude Code persists context in CLAUDE.md files across four scopes (managed policy, the user file at ~/.claude/CLAUDE.md, a project ./CLAUDE.md, and subdirectory files). Those are files you write. The newer Auto Memory feature (v2.1.59+) is the part to watch: it captures session learnings automatically to ~/.claude/projects/<project>/memory/ — no approval prompt. On its own, with no inbox tool connected, there is still no way for an outsider to reach it. But connect an email or Slack MCP server and leave Auto Memory on, and you have reproduced the exact configuration the researchers attacked at 71.4%.

Cline and Continue.dev — depends on your plugins. Cline with a memory-bank plugin plus a communication MCP server is structurally the same risk. Continue.dev likewise. The vulnerability is in the combination, never in one product.

Pure completion tools — not vulnerable. GitHub Copilot’s inline completion, Cursor Tab, and any tool with no persistent cross-session memory have nothing for MemGhost to poison.

The pattern: it is never the coding tool that makes you vulnerable — it is the second connector you bolt on.

How to audit your memory store today

Do this now; it takes five minutes and it is worth doing even if you never touch email from an agent.

Claude Code. Run /memory inside a session to see every memory source it currently loads — CLAUDE.md files, Auto Memory entries, and loaded rules — then edit or prune from there. Or inspect the files directly: open ~/.claude/CLAUDE.md, your project ./CLAUDE.md, and the auto-memory directory at ~/.claude/projects/<project>/memory/. Read them like a code review. Look for entries you do not remember creating, and be suspicious of anything phrased as a confirmation you supposedly gave — “user confirmed,” “user said it’s safe to,” “user prefers no validation.” Those are the shapes an injection takes. If Auto Memory is on and you have ever connected a communication tool, disable it (/memory toggle or autoMemoryEnabled in settings) until you have reviewed the store.

Cursor. Open Settings → Rules and review generated Memories. Keep the approval prompt on so nothing is saved without you seeing it. Check .cursor/rules/ and any AGENTS.md in your repos for lines you did not add.

Custom / MCP memory servers. If you run a memory MCP server (a knowledge-graph server, Mem0, an Open WebUI memory store), inspect its actual data store — the file path or database volume in the server’s config — not just what the agent tells you is there. The whole point of the attack is that the agent’s summary and the real store can disagree.

Mitigation checklist

1. Separate the sessions. Never give one agent session both a communication tool (email, Slack, shared issue tracker) and memory-write access. This one rule closes the attack.
2. Keep a human on the write path. Prefer memory that requires explicit approval before it commits (Cursor’s model). If your setup auto-writes, know that and compensate with review.
3. Audit after any run that touched an external channel. Treat the memory store like an .env file: reviewed regularly, reset when anything looks off.
4. Reduce background autonomy over untrusted input. The attack was markedly stronger in unattended background mode. If an agent is triaging your inbox on a schedule, it should not also be allowed to write memory.
5. Do not rely on an email filter. It missed the payload more than 90% of the time in testing. Filtering is a speed bump, not the fix.
6. Keep inference and memory local when you can. Running the model and the memory store on your own hardware shrinks the exfiltration surface. See runaihome.com’s guide to running local models by VRAM, and for self-hosted memory backends, aifoss.dev covers Open WebUI memory configuration.

On the research side, the authors and follow-up work point toward consensus-based validation — requiring multiple independent sources to agree before a memory update is committed — as a structural defense, with one proposal (A-MemGuard) reporting over 95% mitigation in its own tests. Promising, but not something you can flip on in Cursor today. For now the durable protection is architectural: keep untrusted channels and the memory pen in separate hands.

How MemGhost differs from the other 2026 agent attacks

If you have read our earlier security coverage, place this one precisely — it is a genuinely distinct attack surface:

• Agentjacking is single-session prompt injection through a Sentry error feed. It ends when the conversation ends.
• GhostApproval is a symlink trick that escapes the file sandbox on a single write.
• The Amazon Q CVE is MCP auto-execution stealing credentials when you clone a malicious repo.

MemGhost is none of those. It is cross-session, persistent memory corruption — the first three hijack one action or one chat, while this one rewrites what the agent believes about you for every session that follows. As agents grow longer memories and more connectors, this is the class that will matter most.

FAQ

Is MemGhost being used against real developers right now? There is no evidence of in-the-wild exploitation. It is an academic proof-of-concept published July 6, 2026. The value is the warning, not an active incident.

Am I at risk if I only use Cursor or Copilot for coding? No. With no inbox connector and no auto-writing memory reachable by outsiders, there is no injection channel. Cursor’s approve-before-save memory design specifically blocks the silent-write step.

I use Claude Code with Auto Memory. Should I turn it off? Only if you have also connected a communication MCP server (email, Slack) to the same agent. Auto Memory alone, with no channel a stranger can reach, has no injection path. If you have both, disable Auto Memory or split the sessions, and audit ~/.claude/projects/<project>/memory/ now.

What does a poisoned coding memory actually look like? A plausible-sounding standing instruction the agent will silently obey: “User confirmed prepared statements aren’t needed here for performance,” “User approved committing the key in config.py,” “User prefers no input validation on internal endpoints.” Each one nudges the agent toward insecure code you never asked for.

Can’t an email filter just catch the bad messages? Not reliably. The tested filter missed MemGhost’s payload more than nine times out of ten. The fix is architectural — separate untrusted input from memory-write — not a content filter.

Does keeping everything local help? It shrinks the exfiltration surface and keeps your memory store on hardware you control, which makes auditing straightforward. It does not by itself stop a poisoned local email from being read; the session-separation rule still applies.

Sources

• When Claws Remember but Do Not Tell: Stealthy Memory Injection in Persistent Personal Agents — arXiv 2607.05189 (July 6, 2026)
• New MemGhost Attack Plants Persistent False Memories in AI Agents Through One Email — The Hacker News
• How Claude remembers your project (CLAUDE.md, Auto Memory, /memory) — Claude Code Docs
• Cursor Persistent Memory and Rules — Cursor documentation coverage
• AI agent memory poisoning overview — MintMCP

---

Last verified: Jul 14 2026, against the arXiv paper (2607.05189), The Hacker News coverage, and the official Claude Code memory documentation. Memory features and defaults change quickly — confirm your tool’s current behavior in its own settings before relying on it.