CVE-2026-91937 in Flowise
Summary
by MITRE • 09/15/2026
Flowise before 3.1.4 fails to sanitize the overrideConfig.sessionId parameter before using it in MongoDB queries within the MongoDBMemory node. Unauthenticated attackers can submit MongoDB operator objects through the prediction API to read chat history records belonging to other users from the shared collection.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Flowise versions prior to 3.1.4 represents a critical security flaw rooted in improper input validation and sanitization within the application's interaction with its underlying MongoDB database. Specifically, the issue resides in how the system handles the overrideConfig.sessionId parameter when processing requests through the prediction API. This parameter is intended to identify specific user sessions for retrieving or managing chat history data. However, because the value provided by the client is not adequately sanitized before being incorporated into MongoDB queries executed by the MongoDBMemory node, it creates an opportunity for NoSQL injection attacks. In a standard secure implementation, such parameters should be strictly validated against expected formats, typically ensuring they are valid ObjectIds or simple strings that do not contain special characters used in query operators. The failure to enforce these constraints allows malicious actors to inject structured data directly into the query logic rather than treating it as literal search criteria.
From a technical perspective, this flaw enables unauthenticated attackers to manipulate MongoDB operator objects within their requests. By submitting specially crafted payloads containing JSON structures that mimic database queries, an attacker can bypass intended access controls and alter the scope of the database operation. Instead of retrieving only the chat history associated with the session ID provided by the legitimate user context, the injected operators allow the query to ignore specific filters or expand search criteria across the entire collection. This mechanism effectively neutralizes the isolation boundaries that are supposed to separate different users' data within the shared MongoDB collection used for storing conversation logs. The attacker does not need valid credentials because the vulnerability exists in the API endpoint logic itself, which processes inputs before performing any authentication checks relevant to data ownership verification.
The operational impact of this vulnerability is severe, primarily concerning confidentiality and integrity of user data. Attackers can read chat history records belonging to other users who share the same MongoDB collection instance. Since Flowise applications often handle sensitive conversational data, including potentially personal information or proprietary business logic discussed in chats, unauthorized access constitutes a significant privacy breach. This exposure violates fundamental security principles regarding data isolation and multi-tenancy safety. Furthermore, depending on how the application processes subsequent responses from these manipulated queries, there may be secondary risks involving data integrity if write operations were similarly vulnerable, although the primary reported risk is information disclosure. The ability to exfiltrate historical conversation data undermines trust in the platform and can lead to compliance violations under regulations such as GDPR or HIPAA if protected health information or personally identifiable information is exposed.
To mitigate this vulnerability, immediate action must be taken by upgrading Flowise to version 3.1.4 or later, where these input validation mechanisms have been corrected. For environments that cannot immediately upgrade, defensive coding practices should be implemented at the API gateway or application layer to strictly validate and sanitize all inputs passed as session identifiers. This includes enforcing strict type checking to ensure values are valid MongoDB ObjectIds rather than arbitrary JSON objects, and rejecting any requests containing characters commonly used in NoSQL injection payloads such as dots, dollar signs, or parentheses within identifier fields. Additionally, implementing principle of least privilege for the database user account running the application can limit the damage if an attack succeeds by restricting read permissions to only necessary collections and rows where possible through row-level security features if supported by the deployment architecture.
This vulnerability aligns with CWE-943 Improper Sanitization of Special Elements used in a NoSQL Query, which describes flaws where user input is not properly neutralized before being included in database queries. It also maps to MITRE ATT&CK technique T1059 Command and Scripting Interpreter if the injection leads to broader system compromise, but more directly relates to data exfiltration techniques found under Data from Information Repositories or Unsecured Credentials depending on the specific payload used. The lack of input validation serves as a classic example of why defense-in-depth strategies are essential; relying solely on application logic without robust sanitization layers leaves systems exposed to automated exploitation tools that target common NoSQL injection patterns. Ensuring that all external inputs undergo rigorous schema validation and type coercion before database interaction is critical for maintaining the security posture of applications utilizing document-based storage solutions like MongoDB.