- NIST's record for CVE-2026-103250 describes a flaw in n8n's MongoDB Chat Memory node that could let unauthenticated attackers read, write and delete other users' conversation histories.
- It matters because AI memory stores hold conversations, and one unchecked field is described as enough to reach them.
- Check whether you run n8n, which version, and whether this node is in use.
AI memory is a database, and databases have old flaws
An AI assistant that remembers past conversations needs somewhere to keep them. That place is a database, and a database can be attacked in the old ways. This week's n8n record shows how quickly a convenience feature can become a data exposure.
The record is CVE-2026-103250, published by NIST's National Vulnerability Database on October 1, 2026. It describes a NoSQL injection flaw in the MongoDB Chat Memory node of n8n. This record is an example of risk sitting in the plain plumbing around the model.
What the record says
According to the NVD entry, the node fails to validate a parameter called sessionId. Unauthenticated attackers can put MongoDB query operators into that field. The record says this lets them read conversation histories belonging to other users. It also says they can perform unauthorized write and delete operations.
Three version ranges are affected. Any release older than 1.123.80 is covered. So is every release from 2.0.0 up to, but not including, 2.39.6. The third range starts at 2.40.0 and stops before 2.40.1, so it takes in only that one build. The scores were assigned by VulnCheck. NVD lists an n8n GitHub security advisory and a VulnCheck advisory as references.
The NVD record is the only text we reviewed. We did not read the two linked advisories. The record does not use the word "fixed", so the fixed versions below are our inference from where the affected ranges end. The record does not say whether anyone has exploited the flaw.
How the flaw works
A chat memory node files each conversation under a session ID. Later, it uses that ID to look the conversation up. The ID is meant to be a simple label, like a ticket number.
In an injection flaw, the system does not check that the label is only a label. An attacker can send a query instruction in its place. MongoDB operators are special keywords that change what a query matches. A lookup meant to find one conversation can then match others.
That is why the record names three outcomes: reading other users' histories, writing to them, and deleting them. Reading exposes what people told the assistant. Writing and deleting could alter or erase what the system remembers.
The scoring weighs these outcomes differently. The 3.1 vector rates the confidentiality impact as high and the write and delete impacts as low.
Two scores, one message
Both scores are rated high. The vectors describe the attack as network-based and needing no privileges or user interaction. The 3.1 vector rates attack complexity as high, which suggests exploitation is not trivial. The 4.0 vector lists a precondition on the attack.
The two scores also locate the damage differently. The 3.1 vector marks the scope as changed, meaning impact can reach beyond the vulnerable component. The 4.0 vector rates confidentiality impact as low on the vulnerable system and high on subsequent systems. We read this as a sign that the harm may land in the stored conversations, not only in n8n itself.
What leaders should ask this week
Start with inventory. Ask your team whether n8n runs anywhere in the company, including in side projects and test setups. Ask which version each instance runs, and compare it with the three versions above, which we infer are the fixed releases.
Then ask whether any workflow uses the MongoDB Chat Memory node. If it does, ask who can reach that instance from outside, and what the stored conversations contain. Customer questions, internal notes and pasted documents are common examples of what people type into assistants.
Finally, ask how the memory database is backed up. The record describes deletion as possible. A team that cannot restore chat memory should know that before an incident, not during one.
AI agents give companies a new place to keep people's words. Treat that store like any customer database: patch it, limit who can reach it, and know what is in it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
