Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.10.3 has a security flaw that allows an authenticated attacker (someone with login access) to run harmful code on the system. The problem occurs because the software does not properly restrict file paths (the locations where files are stored), which lets attackers access directories they shouldn't be able to.
IBM Langflow OSS versions 1.0.0 through 1.11.5 have a vulnerability where logged-in non-admin users can run arbitrary operating system commands (OS commands, or instructions executed directly on a computer) on the server by creating a flow that uses an MCP Tools component with local stdio subprocess transport, bypassing security controls meant to prevent this. This could allow attackers to access sensitive information, modify files, or move laterally (gain access to other connected systems) within the network.
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.11.5 has a vulnerability where an authenticated attacker (someone with login access) can execute arbitrary code (run any commands they want) by exploiting improper handling of special characters in flow display names (the text labels users give to workflows).
IBM Langflow OSS (an open-source tool for building AI applications) versions 1.0.0 through 1.11.5 has a security flaw where API keys (credentials that grant access to the system) don't expire when a user account is deactivated, allowing a former user to still run workflows and access sensitive data.
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.11.5 have a vulnerability (CVE-2026-81265), but the provided content does not describe what the vulnerability actually is or how it affects users.
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.11.5 has a vulnerability where an attacker can trick the system into accessing internal network resources by providing malicious URLs that aren't properly checked. This could expose sensitive information that should be kept private inside a company's network.
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.11.5 has a security flaw where a logged-in attacker could run malicious Python code (a programming language) by exploiting weak permission checks on custom components stored in workflows. This happens because the software doesn't properly verify that users are allowed to use certain customizable tools before executing them.
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.11.5 has a vulnerability that allows an attacker to run arbitrary code (any commands they want) on a system by injecting malicious code during graph construction (the process of building the visual workflow/logic structure in Langflow).
IBM Langflow OSS (open-source software) versions 1.0.0 through 1.11.5 has a vulnerability where an authenticated attacker (someone with login credentials) can run arbitrary code (any commands they choose) because the system fails to properly block dangerous environment variables (system settings that control how software behaves).
IBM Langflow OSS (an open-source AI tool) versions 1.0.0 through 1.11.5 have a security flaw where someone who is logged in could read files they shouldn't have access to because the system doesn't properly check permissions (improper access control).
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).
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 DatabaseFix: 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 Database