Advisories
Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
3,134 items
IBM Langflow OSS versions 1.0.0 through 1.11.5 contain CVE-2026-79742. The flaw stems from an incomplete environment variable blocklist, and a remote authenticated attacker could exploit it to execute arbitrary code.
IBM Langflow OSS versions 1.0.0 through 1.11.5 contain a flaw that lets a remote authenticated attacker read arbitrary files. The cause is improper access control.
IBM Langflow OSS versions 1.0.0 through 1.11.5 contain a flaw, tracked as CVE-2026-79724, caused by improper neutralization of special elements used in an OS command. A remote attacker could exploit it to execute arbitrary OS commands.
IBM Langflow OSS versions 1.0.0 through 1.11.5 contain CVE-2026-79723. A remote authenticated attacker can obtain sensitive information because user-controlled API endpoints are not properly validated.
IBM Langflow OSS versions 1.0.0 through 1.11.5 contain a flaw in the MCP stdio server configuration, where command-line arguments are improperly validated. A remote authenticated attacker can exploit this to execute arbitrary commands.
IBM Langflow OSS versions 1.0.0 through 1.11.5 contain an unguarded eval() call on attacker-controlled input, tracked as CVE-2026-78571. A remote authenticated attacker can exploit it to execute arbitrary code.
IBM Langflow OSS versions 1.0.0 through 1.11.5 are affected by CVE-2026-78569. An authenticated attacker can execute arbitrary code because the security scanner relies on an incomplete denylist.
IBM Langflow OSS versions 1.0.0 through 1.11.5 contain a flaw in the static security scanner for custom component source code. A crafted annotated class-body assignment resolves to a dangerous callable through alias tracking, and the resolved value is never checked against the blocklist because of a logic error. If the component reaches the runtime execution path, an attacker can run arbitrary operating system commands on the server in-process, with the privileges of the running service.
The POST /v1/chat/completions endpoint in mistral.rs fetches attacker-supplied image, audio and video URLs into server memory with no byte cap, and extracts every frame of a video when num_frames is None. The route is open by default and requires no authentication, so an unauthenticated remote attacker can exhaust memory, disk and CPU, for example by pointing it at an infinite-streaming HTTP server or a long high-framerate video, causing a complete denial of service.
mistral.rs fetches request-supplied image and audio URLs through parse_image_url and parse_audio_url in mistralrs-server-core/src/util.rs without host, IP or allowlist checks, and opens file:// URLs and existing bare paths on the server. Because the server is unauthenticated by default, a remote client sending image_url or audio_url content can trigger server-side requests to internal or cloud-metadata addresses (SSRF) and read arbitrary local files. The error messages differ between existing and nonexistent paths, which lets an attacker probe which files exist.
Fix: Suggested fix: restrict request-supplied media to http(s) and data:, stop resolving bare strings to local files and stop honoring the file scheme from request input (gate local media behind an explicit, default-disabled option). Before fetching http(s), resolve the host, reject non-global IPs, pin the connection to the validated IP and re-validate or disable redirects. Cap the read size.
GHSA-q5wm-mgqx-fv2f affects the Instance AI credential setup in n8n, which accepted a credential test or verification URL without checking that it matched the workflow node's origin. Exfiltration required a user to actively inject an attacker-controlled URL into the setup flow, and the patch derives the credential destination from the node's own URL, confining authenticated requests, redirects and probes to that origin.
Fix: The issue has been fixed in n8n versions 2.38.2 and 2.37.7. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, temporary mitigations are: remove `instance-ai` from the `N8N_ENABLED_MODULES` environment variable if the module is not required; restrict n8n instance access to fully trusted users only; and rotate any third-party API credentials set up using the Instance AI credential-setup flow on affected versions. These workarounds do not fully remediate the risk and should only be used as short-term measures.
IBM Langflow OSS versions 1.0.0 through 1.11.5 contain an improper access control flaw in the File/Read File component, tracked as CVE-2026-9225. An authenticated attacker with low privileges can supply a crafted storage path through the /api/v1/run/advanced/{flow_id} endpoint to read files uploaded by other users, bypassing the file management API's authorization checks.
CVE-2026-85025 affects IBM Langflow OSS versions 1.0.0 through 1.11.5. Improper enforcement of public-flow security restrictions and session isolation controls lets an unauthenticated attacker execute arbitrary code through publicly shared MCP project endpoints. The attacker can also access or modify chat sessions.
A potential command injection vulnerability was reported in the Tianxi AI Agent PC Application, which is distributed exclusively in the Chinese market. A local user who opens a specially crafted link handled by the application could allow operating system commands to be executed.
The public OIDC login and callback endpoints in n8n Enterprise ran the full authentication flow and issued sessions even after OIDC was disabled in Settings, leaving an administrator's disabled provider with a working login route. The issue affects instances where OIDC was configured at least once and later disabled, and the fix requires OIDC to be the enabled, active authentication method before either endpoint starts the flow or issues a session.
Fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2; upgrade to one of these or later. Temporary workarounds, which do not fully remediate the risk: disable or revoke the corresponding application or client at the IdP level, and restrict network-level access to the n8n instance to trusted users only.
The n8n GitHub Trigger node generated a signing secret when registering a webhook but discarded it when GitHub returned a 422 because a hook for the URL already existed. Signature verification on X-Hub-Signature-256 then accepted deliveries to that workflow's webhook URL from anyone. The fix re-fetches the existing hook by its stored id, re-applies the signing secret, and makes verification fail closed when no secret is stored.
Fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2; upgrade to one of these or later. If upgrading is not immediately possible, temporary workarounds are: deactivate and reactivate GitHub Trigger workflows after deleting the remote GitHub hook so a new secret is generated; restrict network access to the n8n webhook endpoint to GitHub's published IP ranges; and audit GitHub Trigger static data for entries with a webhookId but no webhookSecret, treating those workflows as unprotected until reactivated. The source states these workarounds do not fully remediate the risk and are short-term measures only.
The Instance AI workflow summary in n8n built its result using get-or-create-then-nested-write logic keyed by node names and connection keys from stored workflows. Because the editor's restricted-name guard is client-side, an attacker can post a workflow with a reserved key such as `__proto__` directly to the REST API, so the write lands on `Object.prototype` in the main n8n process and affects every later request. The advisory covers this prototype pollution flaw, which can lead to denial of service.
Fixed in n8n versions 2.37.7 and 2.38.2; upgrade to one of these or later. If upgrading is not immediately possible, restrict instance access to fully trusted users, remove or leave unconfigured the `N8N_INSTANCE_AI_MODEL*` environment variables, and restart the n8n process to clear in-memory pollution if an attack is suspected. These workarounds do not fully remediate the risk and are short-term measures only.
The endpoint `/rest/active-workflows` in n8n returned every active workflow ID on the instance to any member, regardless of sharing. Workflow activation, deactivation and publication push events were also broadcast to all connected clients, exposing workflow IDs, version IDs and activation-error detail across users. The patch scopes both the listing and the push events through the sharing service.
Fix: Upgrade to n8n 1.123.76, 2.37.7, 2.38.2 or later. If upgrading is not immediately possible, restrict instance access to fully trusted users only and avoid provisioning `global:member` accounts for untrusted users until the instance is patched. The source states these workarounds do not fully remediate the risk and are short-term measures only.
Two code-generation stages in n8n's legacy expression engine called the global JSON.stringify at generation time. An expression that replaced that global could change the source that was generated and then executed, turning literal data into executable code. The vm expression engine, the default on patched releases, is not affected.
Fix: Fixed in n8n 1.123.76, 2.37.7, and 2.38.2. If upgrading is not immediately possible, set N8N_EXPRESSION_ENGINE=vm, restrict instance access to fully trusted users, and run the n8n process under a dedicated low-privilege OS user account. These workarounds do not fully remediate the risk and are short-term measures only.
n8n's `/chat` WebSocket route resumed paused executions from a resume token without checking that the target node was a chat node. Because n8n gives that token to anonymous form submitters, an unauthenticated party could present it on the chat route and release an execution waiting at an approval gate.
Fix: Fixed in n8n versions 2.37.7 and 2.38.2; upgrade to one of these or later. If upgrading is not immediately possible, the source suggests restricting instance access to fully trusted users, avoiding workflows that combine a Form Trigger with non-chat approval gates on publicly accessible instances, and auditing recent executions of such workflows for completions without a corresponding approval callback. The source states these workarounds do not fully remediate the risk and are only short-term measures.