All tracked items across vulnerabilities, news, research, incidents, and regulatory updates.
IBM Langflow OSS versions 1.0.0 through 1.11.5 have a vulnerability that lets remote attackers run arbitrary OS commands (unauthorized instructions on the underlying operating system) because the software doesn't properly filter dangerous characters in user input before using it in system commands.
IBM Langflow OSS (an open-source AI tool) versions 1.0.0 through 1.11.5 has a security flaw where a logged-in attacker could access sensitive information because the software doesn't properly check if API endpoints (connection points for requesting data) that users provide are safe to use.
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.11.5 has a security flaw where someone with login credentials could run harmful commands on the system. The problem is that the MCP stdio server (a component that handles communication through text input/output) doesn't properly check command-line arguments (instructions given when starting a program) before using them.
IBM Langflow OSS versions 1.0.0 through 1.11.5 have a vulnerability where an unguarded eval() call (a function that executes code from text input) on attacker-controlled input allows a logged-in attacker to run arbitrary code (any commands they want) on the system.
IBM Langflow OSS (an open-source AI tool) versions 1.0.0 through 1.11.5 has a security flaw where someone with login credentials can run malicious code on the system because the security scanner has an incomplete denylist (a list of blocked or dangerous items that isn't thorough enough).
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.11.5 has a vulnerability where an attacker can upload malicious custom component code that tricks the static security scanner (a tool that checks code before it runs) by using alias tracking (following variable names to their actual values). Because of a logic error, the dangerous code is never checked against a blocklist of forbidden operations, allowing the attacker to execute arbitrary operating system commands on the server with the privileges of the running service.
mistral.rs has a vulnerability where the chat completions endpoint downloads media files (images, audio, videos) from URLs without limiting how much data it stores in memory, and extracts every frame from videos when no frame limit is set. An attacker can crash the server by sending it links to infinitely-streaming files or very long high-framerate videos, exhausting the server's memory, disk space, and CPU without needing any authentication.
mistral.rs has a critical security flaw where it fetches any image or audio URL provided by users without checking what hosts or IP addresses are being accessed, and it also opens arbitrary files from the server's storage. An unauthenticated attacker can exploit this to make the server request internal or cloud-metadata services (SSRF, or server-side request forgery, where a server is tricked into making unwanted requests) and read any local files on the system.
n8n had an OAuth security flaw where refresh tokens (credentials that let apps get new access tokens without re-authorization) could be used on different resources than originally approved. An attacker could trick a user into approving their app for one workflow, then use the refresh token to access a different workflow without permission. The fix binds refresh tokens to their original resource and rejects mismatched requests.
A vulnerability in n8n's Instance AI credential setup allowed attackers to redirect credential verification requests to uncontrolled URLs, potentially stealing credentials if a user injected a malicious URL into the setup process. The flaw happened because the system didn't check that verification URLs matched the workflow node's origin (the source server where the code is running).
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.
n8n had a security flaw where certain API endpoints didn't check if a user could access a specific project before showing that project's members' names and emails. An attacker with role-management permission could exploit this to view private information from any project on the system. The vulnerability has been patched in n8n versions 2.38.2 and 2.37.7.
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.
Fix: The source suggests restricting media requests to only http(s) and data: URLs, blocking the file:// scheme and bare file paths from user input. Before fetching http(s) URLs, validate that the host resolves to a public IP address and reject private, loopback, link-local, or metadata IPs. Pin connections to the validated IP, re-validate any redirects (or disable them), and limit the amount of data read. Local file access should only be allowed through an explicit option that is disabled by default.
GitHub Advisory DatabaseMultiple researchers at Anthropic, an AI company, publicly warned that advanced AI systems could pose extinction-level risks to humanity within the next decade, with some believing current development is moving too fast without adequate safety plans. In response, Elon Musk and others dismissed these concerns as a coordinated effort to manipulate public opinion against AI, while Anthropic defended itself by stating it builds models with strong safeguards.
Fix: The issue has been fixed in n8n versions 2.38.1 and 2.37.7. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should: restrict n8n instance access to fully trusted users only; deactivate MCP Trigger, form, and webhook workflows protected by n8n OAuth if not required; audit connected OAuth clients and revoke unrecognized or unneeded ones; and require re-authorization for all existing OAuth clients after upgrading, as previously issued refresh tokens did not store the original resource binding. 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.38.2 and 2.37.7. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators can: (1) Disable the Instance AI module by removing `instance-ai` from the `N8N_ENABLED_MODULES` environment variable if not required; (2) Restrict n8n instance access to fully trusted users only; (3) Rotate any third-party API credentials that were 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 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, 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: Upgrade to n8n version 2.38.2 or 2.37.7 or later. If upgrading is not immediately possible, administrators can temporarily: (1) restrict n8n instance access to fully trusted users only, and (2) audit and revoke any custom global roles that carry the `role:manageProject` scope, limiting that scope to fully trusted users only. Note: 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.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 Database