Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
IBM Langflow Desktop versions 1.0.0 through 1.8.4 have a security flaw where an unauthenticated user (someone without a login) can view other users' images by manipulating a user-controlled key (a piece of data that identifies which resource to access). This happens because the application doesn't properly check permissions when accessing images, which is a type of vulnerability called authorization bypass through user-controlled key (CWE-639).
IBM Langflow Desktop versions 1.2.0 through 1.8.4 has a path traversal vulnerability (CVE-2026-4502) that allows an authenticated attacker to write arbitrary files on a system by sending specially crafted URL requests with "dot dot" sequences (/../, which move up directory levels). This affects users who are already logged into the application.
IBM Langflow Desktop versions 1.6.0 through 1.8.4 has a stored cross-site scripting vulnerability (XSS, a flaw where an attacker can inject malicious code that gets saved and executed in a web interface). An authenticated user can embed JavaScript code in the Web UI, which could alter how the application works and potentially expose user credentials to attackers who access the same session.
IBM Langflow Desktop versions 1.0.0 through 1.8.4 have a vulnerability called SSRF (server-side request forgery, where an attacker tricks the server into making requests it shouldn't). An authenticated attacker (someone with login access) could exploit this to send unauthorized requests from the system, potentially discovering network information or launching additional attacks.
OpenTelemetry's disk retry feature for OTLP (OpenTelemetry Protocol, a standard format for sending telemetry data) had a security flaw where it stored temporary blob files (serialized data chunks) in a shared system temp directory accessible to other user accounts on multi-user systems. This allowed attackers to inject fake telemetry data, read sensitive telemetry information, or cause performance problems by filling the directory with large files.
A security flaw in n8n-mcp's URL validation allowed attackers to bypass SSRF (server-side request forgery, where an attacker tricks a server into making unwanted requests) protections using IPv4-mapped IPv6 addresses like `http://[::ffff:169.254.169.254]`. This could let an attacker who controls the `n8nApiUrl` input force the server to request sensitive data from cloud metadata endpoints, private networks, or localhost services, and the responses would be returned to the attacker along with API credentials.
Jupyter Notebook has a stored XSS (cross-site scripting, a type of attack where malicious code runs in a user's browser when they view a webpage or file) vulnerability that lets attackers steal authentication tokens (credentials that prove who you are) by tricking users into clicking fake controls in malicious notebook files. An attacker who steals these tokens can take over a user's account, read files, run code, and access the system.
The Claude SDK for TypeScript had a security flaw where a tool called `BetaLocalFilesystemMemoryTool` created files and folders with overly permissive access settings (using Node.js defaults like `0o666` for files and `0o777` for directories, which control who can read or modify them). This meant that on shared computers or in containerized environments (like Docker), other users could read sensitive agent data or modify it to change how the AI behaves.
A critical vulnerability in marked@18.0.0 allows an unauthenticated attacker to crash any Node.js application using this library by sending just 3 special characters (a tab, vertical tab, and newline). These characters trick the parser into infinite recursion (a function calling itself endlessly), which allocates memory indefinitely until the application runs out of memory (OOM, or out-of-memory error) and crashes.
OpenClaw versions before 2026.4.15 had a security flaw where the webchat audio embedding feature could read local files from the host system without proper security checks. An attacker who could control the output of an agent or tool could trick the system into embedding audio files from the host into chat responses, bypassing the containment restrictions that protect other file-serving paths.
A vulnerability in n8n (a workflow automation tool) allows authenticated users to exploit the XML Node through prototype pollution (a technique where an attacker modifies object properties that affect all instances of that object type) to achieve RCE (remote code execution, where attackers can run arbitrary commands on the system). This is particularly dangerous because it affects users with permission to create or edit workflows.
n8n had a vulnerability in its XML webhook parser caused by the `xml2js` library that allowed prototype pollution (a type of attack where an attacker modifies a JavaScript object's base properties to affect all objects). An authenticated user with workflow creation permissions could exploit this flaw and combine it with the Git node's SSH operations to achieve RCE (remote code execution, where an attacker runs commands on a system they don't own).
n8n (a workflow automation tool) has a vulnerability where an attacker could inject malicious code through a fake OAuth client name, causing it to run in a victim's browser when they revoke access. This XSS (cross-site scripting, injecting malicious code into a webpage) attack could let attackers steal login credentials, take over sessions, or modify workflows.
n8n (a workflow automation tool) had a security flaw where authenticated users could steal API keys belonging to other users by exploiting the `dynamic-node-parameters` endpoints (parts of the system that handle credential references). An attacker with access to a shared workflow could submit another user's credential ID and trick the backend into sending that credential to a server the attacker controls, allowing them to capture and reuse the stolen API key.
n8n (a workflow automation tool) has a vulnerability where authenticated users who can create or modify workflows can escape the sandbox (an isolated environment meant to restrict code execution) and run arbitrary code on the task runner container, but only if the Python Task Runner feature is enabled.
n8n, a workflow automation tool, had a security flaw where authenticated users with an API key could read variables (data storage containers) from projects they shouldn't have access to by manipulating a query parameter, potentially exposing secrets like passwords or tokens. This vulnerability only affected enterprise or team deployments with multiple projects enabled.
n8n has a vulnerability where an unauthenticated attacker can crash an n8n instance (a workflow automation tool) by sending large amounts of data to the MCP OAuth client registration endpoint (the system that lets external applications connect to n8n). The endpoint doesn't properly limit how much data it accepts or how many clients can register, allowing attackers to use up all the server's memory and make it unavailable.
n8n's Chat Trigger feature had a security flaw where the `/chat` WebSocket endpoint (a communication channel) didn't check if users were authorized to access workflow executions. An attacker who could guess a valid execution ID (a unique identifier for a running workflow instance) could connect to an unprotected chat workflow, intercept prompts meant for legitimate users, and inject their own commands to change how the workflow behaves.
A SQL injection (inserting malicious code into database queries) flaw in n8n's SeaTable node allowed attackers to manipulate search and row retrieval operations when user-controlled input was passed into the node without proper safeguards, potentially exposing unintended database rows. The vulnerability required a specific workflow setup where external input from sources like forms or webhooks was directly used in search parameters.
n8n has a vulnerability where its OAuth consent flow allows attackers to register fake redirect URLs (destinations where users are sent after denying permission) without authentication. An attacker can trick a user into clicking a malicious link, and when the user clicks "Deny" on the consent dialog, they get redirected to the attacker's website instead of staying safe. This could be used for phishing (tricking users into giving up sensitive information).
Fix: If an immediate upgrade to a patched version is not possible: 1. Avoid enabling disk retry in shared environments. 2. Configure a dedicated directory with strict ACL/ownership and least privilege (access control lists that restrict who can read or write). 3. Ensure the directory is not shared across tenants/users. 4. Monitor for unexpected `*.blob` files or abnormal retry backlog growth.
GitHub Advisory DatabaseFix: Upgrade to **v2.47.14 or later** (via `npx n8n-mcp@latest` for npm or `docker pull ghcr.io/czlonkowski/n8n-mcp:latest` for Docker). If immediate upgrade is not possible, the source mentions three workarounds: (1) validate URLs before passing them to the SDK by rejecting IP literal hostnames and accepting only DNS-resolvable hostnames; (2) restrict outbound network traffic from the n8n-mcp process to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local addresses (169.254.0.0/16), and cloud metadata endpoints; and (3) do not accept user-controlled `n8nApiUrl` values and derive the URL from internal configuration only.
GitHub Advisory DatabaseFix: Update to Jupyter Notebook 7.5.6 or JupyterLab 4.5.7, which include patches. As a temporary workaround, disable the help extension by running: `jupyter labextension disable @jupyter-notebook/help-extension` and `jupyter labextension disable @jupyterlab/help-extension`. For additional hardening, disable command linker functionality by adding this to `overrides.json`: `{"@jupyterlab/apputils-extension:sanitizer": {"allowCommandLinker": false}}`.
GitHub Advisory DatabaseFix: Users on the affected versions are advised to update to the latest version.
GitHub Advisory DatabaseFix: Upgrade to OpenClaw version 2026.4.15 or later (the latest public release 2026.4.21 also contains the fix). The fix works by adding the local media root containment check to the webchat audio path and calling `assertLocalMediaAllowed` before reading local audio content. An additional `trustedLocalMedia` gate was added to prevent untrusted model or tool outputs from accessing local audio embedding.
GitHub Advisory DatabaseFix: The vulnerability has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1 or later. If immediate upgrade is not possible, administrators can temporarily: (1) Limit workflow creation and editing permissions to fully trusted users only, or (2) Disable the XML node by adding `n8n-nodes-base.xml` to the `NODES_EXCLUDE` environment variable. The source notes these workarounds do not fully remediate the risk and are only short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators should limit workflow creation and editing permissions to fully trusted users only, though this is only a temporary mitigation and does not fully remediate the risk.
GitHub Advisory DatabaseFix: This issue has been fixed in n8n version 2.14.2. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict access to the n8n instance and the MCP OAuth registration endpoint to trusted users only, or disable MCP server functionality if not actively required. However, 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 2.18.0. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict n8n access to fully trusted users only and avoid sharing workflows with users who should not have access to the credentials those workflows reference. 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 versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. As temporary workarounds if upgrading is not immediately possible, administrators can limit workflow creation and editing permissions to fully trusted users only, or disable the Python Code node by adding `n8n-nodes-base.code` to the `NODES_EXCLUDE` environment variable, or disable the Python Task Runner entirely. However, 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 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict n8n access and API key issuance to fully trusted users only, and audit existing project variables for sensitive values and rotate any secrets that may have been exposed (though 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.32, 2.17.4, 2.18.1, or later. If immediate upgrade is not possible, administrators can temporarily: (1) restrict network access to the n8n instance to prevent requests from untrusted sources, or (2) reduce the maximum accepted payload size by lowering the `N8N_PAYLOAD_SIZE_MAX` environment variable from its default value. The source notes these workarounds do not fully fix the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. As a temporary workaround, administrators can enable authentication on all Chat Trigger nodes by setting the Authentication field to `n8n User Auth` rather than `None`, though this does not fully eliminate the risk.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, temporary mitigations include: restricting workflow creation and editing permissions to trusted users only; disabling the SeaTable node by adding `n8n-nodes-base.seaTable` to the `NODES_EXCLUDE` environment variable; and avoiding unvalidated external user input in SeaTable node parameters.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators can restrict network access to the n8n instance to prevent untrusted users from reaching the MCP OAuth endpoints, or limit access to the n8n instance to fully trusted users only. However, the source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory Database