The MongoDB Chat Memory node accepted the sessionId value from the Chat Trigger request body without validating that it was a plain string before passing it to the MongoDB query that loads conversation history. An unauthenticated caller could supply a MongoDB query operator in place of a session identifier, causing the database to match sessions other than their own. This allowed an outside visitor with access only to the public chat URL to read conversation histories belonging to other users. The same query path is used for write and delete operations, so those are exposed by the same defect.
The issue affects workflows that combine a Chat Trigger node configured with no authentication and a MongoDB Chat Memory node.
The issue has been fixed in n8n version 1.123.80, 2.39.6 and 2.40.1. Users should upgrade to this version or later to remediate the vulnerability.
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
Restrict n8n instance access to fully trusted users only.
Enable authentication on any Chat Trigger nodes that are backed by a MongoDB Chat Memory node, so that the public endpoint is no longer unauthenticated.
Replace the MongoDB Chat Memory node with an alternative memory backend until the instance is patched.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
