Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
IBM Langflow OSS versions 1.0.0 through 1.11.5 has a vulnerability where an authenticated attacker (someone with login access) can read files belonging to other users by exploiting improper access control in the File/Read File component. When a user runs workflows through a specific API endpoint, the application doesn't properly verify that the file path belongs to them, allowing attackers to craft requests that access and retrieve files from other users' storage areas.
IBM Langflow OSS versions 1.0.0 through 1.11.5 has a vulnerability that lets unauthenticated attackers (those without login credentials) run arbitrary code (any commands they want) and access or change chat sessions through publicly shared project endpoints, because the software doesn't properly restrict access to public flows (shared AI workflows) or isolate sessions (separate user conversations) from each other.
A command injection vulnerability (a security flaw allowing attackers to run unauthorized operating system commands) was found in the Tianxi AI Agent PC Application used in China. A local user could trigger this vulnerability by opening a specially crafted link that the application processes, potentially allowing an attacker to execute commands on their computer.
The Git node in n8n (a workflow automation tool) had a security flaw where it didn't properly validate configuration settings when setting upstream branches, allowing authenticated users to read files from any local repository that the n8n process could access. An attacker with workflow-edit permission could bypass sandbox path restrictions (security boundaries that limit file access) and steal data from repositories they shouldn't reach.
A flaw in n8n (a workflow automation tool) allowed users with certain permissions to access and decrypt credentials (secret login information) that belonged to other projects without proper authorization checks. An attacker could use this to steal sensitive secrets and send them to a server they controlled.
n8n (a workflow automation platform) had a security flaw where OIDC endpoints (the login pathways that use OIDC, which is a single sign-on system) continued to work and issue valid sessions even after an administrator disabled OIDC in the settings. This affected n8n Enterprise instances where OIDC had been set up previously.
A bug in n8n's GitHub Trigger feature caused it to skip storing a security secret when GitHub rejected webhook registration with a 422 error (webhook already exists). This meant incoming webhook deliveries were accepted without signature verification (checking that messages came from the real GitHub), allowing anyone to trigger workflows. The issue has been patched in versions 1.123.76, 2.37.7, and 2.38.2.
The Elasticsearch and ElasticSecurity nodes in n8n (a workflow automation tool) had a path injection vulnerability where user-provided identifiers weren't properly encoded in REST API requests, allowing an attacker to access unintended indexes or administrative endpoints using stored Elasticsearch credentials. An attacker could manipulate identifier values containing path separators to redirect operations meant for one document to a different index or system endpoint.
n8n has a prototype pollution vulnerability (a bug where attackers can modify the base object that all objects inherit from) in its AI workflow summary feature. An attacker can bypass the client-side name restrictions by sending specially crafted requests directly to the API, using reserved names like `__proto__` to corrupt the shared object prototype and cause denial of service (making the service unavailable) for all users. The vulnerability affects how the workflow summary builds its results by using arbitrary strings from the workflow without proper validation.
n8n, a workflow automation tool, had a security flaw where the `/rest/active-workflows` endpoint (an API endpoint that returns information) showed all active workflow IDs to any user on the instance, regardless of permissions. Additionally, events about workflow activation, deactivation, and publishing were broadcast to all connected clients with sensitive details like workflow IDs and error information, leaking data across different users.
n8n, a workflow automation platform, had a vulnerability in its legacy expression engine where attackers could escape the expression sandbox (a restricted environment meant to safely execute code) by tampering with the global JSON.stringify function. This allowed them to turn data into executable code and gain full code execution. The default vm expression engine is not affected by this issue.
A security flaw in n8n (a workflow automation tool) allowed anyone without an account to bypass approval gates (checkpoints that require human approval before executing important actions) by reusing a special token called a resumeToken on the chat route. The issue occurred because the system didn't verify that the token was being used for the correct type of node, allowing unauthorized users to complete workflows that should have required approval.
Traefik has a vulnerability where the `readTimeout` setting (which limits how long a request can take to be fully received, including its body) doesn't work for HTTP/3 connections. This means an attacker can send a request body very slowly and keep the connection open indefinitely, wasting server resources. The bug appeared in version 2.8.2 and affects all versions from 2.8.2 through 3.6.
OmniRoute, an open-source AI gateway (a tool that connects to multiple AI model providers through one interface), has a critical security flaw in version 3.8.49 and earlier. An attacker can send specially crafted requests to the /api/acp/agents endpoint that bypass security checks and execute arbitrary code (run any commands they want) on the server, especially when login is disabled or during initial setup. The vulnerability exists because the system uses weak filters to block dangerous shell commands and fails to properly authenticate or restrict access to sensitive endpoints.
A vulnerability in knowns version 0.33.0 and earlier fails to properly restrict file access in the code.find MCP tool (a tool that helps AI agents find code). This allows attackers to read source files from anywhere on the computer by using absolute paths or relative path traversal sequences (tricks like "../" to go up directories), rather than limiting access to just the intended project folder.
n8n, a workflow automation tool, has a vulnerability in its Git node where a specially crafted file path can cause ReDoS (regular expression denial of service, where a malicious input makes pattern matching take extremely long) in the default file-blocking pattern. An authenticated user could freeze the entire n8n instance for all users by running a workflow with this malicious path, since the pattern matching happens synchronously (blocking other tasks) in the main process.
n8n, a workflow automation platform, had a vulnerability where unauthenticated attackers could submit extremely large values in OAuth (open authorization, a login system) registration fields without proper size limits, causing the database to grow indefinitely without needing an account. The issue affected the `client_name` and `grant_types` fields, which only had basic existence checks rather than strict size validation like the `redirect_uris` field had.
n8n, a workflow automation tool, had a security flaw where users could escape the expression sandbox (a restricted environment meant to safely run user code) by creating a class field named `__sanitize`, which let them access the Function constructor and run arbitrary code. This meant backend users could execute code in the n8n process, and in the editor preview, someone's expression could run as JavaScript in another person's browser session.
In Open WebUI (a chat interface tool), any member with permission to post in a channel could edit and rewrite messages from other members while keeping the original author's name attached. This happened because the chat completions endpoint (the part of the software that handles message edits) only checked if the person had write access to the channel, but never verified they actually wrote the message being edited. A separate message editing route had the correct check, so the two code paths disagreed about who could modify messages.
A vulnerability in Gemini CLI (a command-line tool) and its GitHub Action integration allowed an attacker without special permissions to run arbitrary code (execute any commands they want) by creating a malicious .env file (a configuration file that sets environment variables) that overrides the GEMINI_CLI_HOME setting.
Fix: The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, temporary mitigations include: restricting n8n instance access to fully trusted users only; disabling the Git node by adding `n8n-nodes-base.git` to the `NODES_EXCLUDE` environment variable; and ensuring the n8n process runs under a dedicated low-privilege OS user account to limit filesystem access. These workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should: restrict n8n instance access to fully trusted users only; audit and revoke any custom global roles carrying Log Streaming scopes (eventBusDestination:create, eventBusDestination:test, etc.), limiting those scopes to fully trusted users only; and review existing Log Streaming event destinations for unexpected webhook URLs and remove any that are not recognized, then rotate any credentials that may have been referenced. Note that 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 versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators can temporarily disable or revoke the corresponding application or client at the IdP (identity provider, the system that handles login) level to prevent the OIDC flow from completing, or restrict network-level access to the n8n instance to trusted users only. The source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: Upgrade to n8n versions 1.123.76, 2.37.7, or 2.38.2 or later. If immediate upgrade is not possible, temporary workarounds include: (1) deactivate and reactivate GitHub Trigger workflows after deleting the remote GitHub webhook to force fresh registration with a new secret, (2) restrict network access to the n8n webhook endpoint to GitHub's published IP ranges only, or (3) audit GitHub Trigger workflow data for entries with a `webhookId` but no `webhookSecret` and treat those as unprotected until reactivated. The source notes these workarounds do not fully resolve the risk and should only be temporary measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, temporary workarounds include: restricting n8n instance access to fully trusted users only, disabling the affected nodes by adding `n8n-nodes-base.elasticsearch` and `n8n-nodes-base.elasticSecurity` to the `NODES_EXCLUDE` environment variable if not required, and auditing existing workflows to ensure index and document identifier fields do not accept externally-controlled input. The source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 2.37.7 and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, temporary workarounds include: restricting n8n instance access to fully trusted users only, removing or leaving unconfigured the `N8N_INSTANCE_AI_MODEL*` environment variables to prevent the Instance AI module from reaching the vulnerable code path, and restarting the n8n process to clear any in-memory prototype pollution if an attack is suspected. Note that 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 versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict n8n instance access to fully trusted users only and avoid provisioning 'global:member' accounts for untrusted users until the instance is patched, though 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 versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators can: set the environment variable N8N_EXPRESSION_ENGINE=vm to switch to the vm expression engine (which is not affected), restrict n8n instance access to fully trusted users only, or ensure the n8n process runs under a dedicated low-privilege OS user account to limit the impact of any command execution. The source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 2.37.7 and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should: (1) restrict n8n instance access to fully trusted users only, (2) avoid workflows that combine a Form Trigger with non-chat approval gates (Send-and-Wait, Telegram/Slack/Gmail HITL, or plain Wait nodes) on publicly accessible instances, and (3) audit recent executions of such workflows for unexpected completion without a corresponding approval callback. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: Upgrade to Traefik v2.11.56 or v3.7.12. These versions contain patches that restore the timeout functionality to HTTP/3 entry points.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later. If immediate upgrade is not possible, temporary workarounds include: (1) restrict instance access to fully trusted users only, (2) disable the Git node by adding `n8n-nodes-base.git` to the `NODES_EXCLUDE` environment variable, or (3) set `N8N_BLOCK_FILE_PATTERNS` to a backtracking-safe equivalent pattern. These workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The vulnerability is fixed in n8n versions 2.37.7 and 2.38.2 or later. If immediate upgrade is not possible, administrators can: restrict network access to only trusted clients, place the instance behind a reverse proxy (a server that filters traffic) configured to enforce strict request body size limits below the default 16 MiB, and monitor the database size and `oauth_clients` table for unusual entries. The source notes these workarounds do not fully remediate the risk and should only be temporary measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict n8n instance access to fully trusted users only, avoid granting workflow-create or workflow-edit permissions to untrusted users, audit existing workflows for unexpected or unfamiliar expressions in node parameters, and set `N8N_EXPRESSION_ENGINE=vm`. The source notes these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: Fixed in version 0.11.1 by commit 7d392bedc (#28631). The channel branch of the chat completions handler now compares the targeted message's author against the calling user and refuses the edit when they differ, matching the check that the dedicated channel message update route already had. Upgrading to 0.11.1 fully resolves this, and no configuration change is required.
GitHub Advisory Database