Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
FlowiseAI has a mass assignment vulnerability (a security flaw where an attacker can modify database fields they shouldn't be able to) in its CustomTemplate feature that allows authenticated users to move templates between workspaces by including a `workspaceId` field in their request. This breaks workspace isolation (the separation that prevents users from accessing data outside their assigned workspace), allowing an attacker to take over templates from other workspaces, since the code uses `Object.assign()` to copy user input directly into database records without filtering which fields are allowed.
Fix: The fix uses an allowlist pattern (explicitly allowing only certain safe fields to be copied from user input) and has already been applied in PR https://github.com/FlowiseAI/Flowise/pull/6129. The vulnerable code at line 211 of `packages/server/src/services/marketplaces/index.ts` that used `Object.assign(newTemplate, body)` was replaced with code that only copies approved fields, matching the same fix pattern that was previously applied to the DocumentStore entity in commit 840d2ae.
GitHub Advisory DatabaseFlowiseAI has a mass-assignment vulnerability (a bug where user input is copied directly into database objects without filtering) in its Assistant service that allows authenticated attackers to change the `workspaceId` field of an assistant they own, moving it to another workspace and gaining unauthorized access. This breaks workspace isolation (the security boundary that keeps data from different organizations separate) and exposes sensitive information like LLM configuration and credentials to unintended users.
FlowiseAI's OpenAI Assistants Vector Store endpoints lack permission checks, allowing any authenticated user to create, modify, delete, or upload files to vector stores regardless of their assigned role. This missing authorization (CWE-306, a security weakness where critical functions don't verify user permissions) has a severity score of about 8.1, meaning attackers with basic access could steal or destroy data.
n8n, a workflow automation tool, had a security flaw where OAuth credential reconnect endpoints checked for read-only access instead of update access. This meant an authenticated user with limited permissions could hijack shared credentials by reconnecting them to their own external account, allowing them to intercept data or take over workflows that other users depend on.
n8n (a workflow automation platform) has a SQL injection vulnerability (a type of attack where malicious code is inserted into database queries) in its Source Control Pull feature. An attacker with write access to a connected git repository could commit a malicious file that, when pulled by an administrator, executes harmful SQL commands on n8n's internal PostgreSQL database (the system that stores data).
n8n, a workflow automation tool, has a security flaw in its XML node (a tool for processing XML data) that lets authenticated users bypass a previous security patch and potentially achieve RCE (remote code execution, where an attacker runs commands on a system they don't control) on the n8n server. The vulnerability requires the attacker to have permission to create or modify workflows and works best when combined with other nodes.
A vulnerability in n8n (a workflow automation tool) allows authenticated users with permission to create or modify workflows to read arbitrary files from the server by injecting malicious commands into the Git node's Push operation. This could potentially give an attacker complete control over the n8n server.
An authenticated user in n8n (a workflow automation tool) could exploit an unvalidated pagination parameter in the HTTP Request node to achieve prototype pollution (a type of attack that corrupts an object used by many parts of a program), potentially leading to RCE (remote code execution, where an attacker can run commands on a system they don't control). This vulnerability requires the attacker to have permission to create or modify workflows.
PyTorch Lightning (a framework for training and adjusting AI models) versions 2.6.2 have introduced a credential harvesting mechanism (a way to steal login information), rated as critical severity with a CVSS score (a 0-10 rating of how severe a vulnerability is) of 9.3. The vulnerability allows attackers to gain complete control over the affected system without needing special access or user interaction.
FlowiseAI has a vulnerability where encrypted credential data (like API keys and passwords) is accidentally exposed when users request credentials using a filter parameter. The code correctly hides this sensitive data when no filter is used, but fails to remove it when filtering by credential name, allowing authenticated users to steal encrypted credentials if they also access the encryption key file stored on the system.
FlowiseAI's custom JavaScript function endpoint lacks proper authorization checks, allowing any authenticated user to submit arbitrary code that executes on the server. When the E2B sandbox (an external code execution service) is not configured, the code runs in a NodeVM sandbox (a JavaScript isolation tool) that can be escaped through error object manipulation, giving attackers access to the host system's process and ability to run commands via child_process (the Node.js module for executing system commands).
FlowiseAI has a mass assignment vulnerability (a flaw where a server accepts fields it shouldn't let users modify) in its assistant update endpoint that lets authenticated users change server-controlled properties like workspaceId, createdDate, and updatedDate. Because the server lacks proper validation and authorization checks, an attacker can reassign assistants to different workspaces, potentially breaking the isolation between separate workspaces in multi-tenant environments (systems serving multiple independent organizations).
Flowise, a tool for building AI applications, has a security vulnerability in its MCP feature (model context protocol, which lets AI tools run system commands) that allows attackers to bypass command restrictions and execute arbitrary code. The vulnerability has three bypass methods: the 'docker build' command isn't blocked (allowing remote code execution through malicious Dockerfiles), the 'npx --yes' long parameter isn't blocked (allowing installation of malicious packages), and a third unspecified method. Any Flowise user can exploit this if the system has docker or npx installed.
FlowiseAI's checkBasicAuth endpoint (a feature that checks login credentials) has a security flaw where it accepts plaintext passwords without rate limiting (restrictions on how many login attempts are allowed), making it vulnerable to brute-force attacks (where attackers try many password combinations rapidly). The endpoint also reveals whether a username exists by returning different success and failure messages, and uses direct string comparison instead of constant-time comparison (a timing-attack-resistant method that takes the same time regardless of where strings differ).
FlowiseAI has a mass assignment vulnerability (a flaw where an attacker can modify server-controlled fields by including them in their input) in its chatflow update endpoint that allows authenticated users to change protected properties like workspaceId, deployed status, and visibility settings. An attacker can reassign chatflows to other workspaces and modify deployment or visibility settings without authorization because the server doesn't validate which fields should be editable.
FlowiseAI has a mass assignment vulnerability (a security flaw where an attacker can modify fields they shouldn't be able to change) in its tool update endpoint that allows authenticated users to reassign tools to different workspaces by manipulating the workspaceId field in their requests. The server fails to validate which properties users can modify, allowing attackers to change server-controlled fields like workspaceId, createdDate, and updatedDate, which breaks tenant isolation (the security boundary that keeps different users' data separate) in multi-workspace environments.
FlowiseAI has a mass assignment vulnerability (a flaw where an application accepts unintended user input to modify server-controlled data) in its variable update endpoint that lets authenticated users change internal fields like workspaceId, createdDate, and updatedDate. Because the server doesn't properly validate or check permissions, attackers can reassign variables to different workspaces, potentially breaking tenant isolation (the separation that keeps different organizations' data separate in shared systems).
SQLBot is a Text-to-SQL system (software that converts natural language questions into database queries) that uses large language models and RAG (retrieval-augmented generation, where the AI pulls in external documents to answer questions). Before version 1.8.0, it had an IDOR vulnerability (insecure direct object reference, where an attacker can access resources belonging to other users by manipulating request parameters), allowing attackers to access and modify database schemas and data from other workspaces or organizations.
GitHub Copilot CLI (an AI tool that helps developers write code from the command line) has a security vulnerability in versions before 1.0.43 where a malicious bare git repository (a special type of git storage folder with no working files) hidden in a project can trick the tool into running harmful commands. An attacker can exploit git's automatic discovery of these repositories and use configuration keys like core.fsmonitor (settings that tell git what commands to run during normal operations) to execute arbitrary code without the user knowing.
In Vercel CLI versions 50.16.0 to 52.0.0, when running in non-interactive mode (a mode where the tool runs without user interaction, often used in CI/CD systems or with AI agents), authentication tokens (secret credentials that prove your identity) could be accidentally included in plain text within JSON suggestions that the tool outputs. This means the token could be exposed in logs or agent records where it shouldn't be visible.
Fix: The vulnerability is already fixed in PR https://github.com/FlowiseAI/Flowise/pull/6128, which applies an allowlist pattern (explicitly specifying which fields are allowed to be copied from user input) to the Assistant service, matching the fix previously applied to the DocumentStore entity in commit 840d2ae.
GitHub Advisory DatabaseFix: Upgrade to n8n version 1.123.43, 2.20.7, or 2.21.1 or later. If upgrading immediately is not possible, administrators should restrict credential sharing to fully trusted users only and audit shared credentials for unexpected OAuth token changes, revoking any tokens that may have been replaced. The source notes these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n version 1.123.43, 2.20.7, and 2.21.1. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should: disable the Source Control feature if not actively required, restrict write access to the connected git repository to fully trusted users only, or avoid pulling from repositories that may have been modified by untrusted parties. The source notes these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: Upgrade to n8n version 1.123.43, 2.20.7, or 2.22.1 or later. If immediate upgrading is not possible, administrators can temporarily limit workflow creation and editing permissions to trusted users only, or disable the XML node by adding `n8n-nodes-base.xml` to the `NODES_EXCLUDE` environment variable (a setting that controls which tools are available). These workarounds do not fully fix the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: Upgrade to n8n versions 1.123.43, 2.20.7, or 2.22.1 or later. If upgrading immediately is not possible, temporarily limit workflow creation and editing permissions to trusted users only, or disable the Git node by adding `n8n-nodes-base.git` to the `NODES_EXCLUDE` environment variable (though these workarounds do not fully fix the risk and should only be used short-term).
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.43, 2.20.7, and 2.22.1. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators can temporarily: (1) limit workflow creation and editing permissions to fully trusted users only, or (2) disable the HTTP Request node by adding `n8n-nodes-base.httpRequest` to the `NODES_EXCLUDE` environment variable. The source notes these workarounds do not fully remediate the risk and should only be short-term measures.
GitHub Advisory DatabaseFix: The source text provides recommendations but does not describe an implemented fix or version update. The recommendations listed are: 1) Implement rate limiting on this endpoint, 2) Use constant-time comparison to prevent timing attacks, 3) Consider using hashed comparison, 4) Return generic error messages, 5) Add logging for failed attempts. No specific patch version or deployed mitigation is mentioned in the source.
GitHub Advisory DatabaseFix: This vulnerability is fixed in version 1.8.0. Users should upgrade SQLBot to 1.8.0 or later.
NVD/CVE DatabaseFix: Update GitHub Copilot CLI to version 1.0.43 or later, where this vulnerability is fixed.
NVD/CVE DatabaseFix: This vulnerability is fixed in version 52.0.1.
NVD/CVE Database