Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
n8n, a workflow automation tool, had a security flaw where the Public API (a way for external programs to interact with n8n) incorrectly allowed users with read-only permissions to retry workflow executions. This bypassed the intended access control that separates read access (viewing only) from execute access (running workflows), affecting shared workflows across users or projects.
Fix: The issue has been fixed in n8n versions 2.25.7 and 2.26.2. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators can temporarily restrict workflow sharing to fully trusted users only or restrict network access to the n8n Public API to trusted users only, though these workarounds do not fully remediate the risk.
GitHub Advisory DatabaseAn authenticated user in n8n (a workflow automation platform) could bypass the AST validator (a security check that analyzes code structure) in the Python Code node and access restricted modules, potentially exposing environment variables (configuration data stored by the system) on self-hosted instances. This vulnerability only affects instances with the Python Task Runner enabled.
n8n (a workflow automation tool) has a stored XSS vulnerability (cross-site scripting, where malicious code is saved and runs when users visit a page) in its Chat Trigger feature. An authenticated user with edit access could inject harmful JavaScript code that executes with the privileges of anyone who visits the chat URL, potentially compromising their session.
n8n, a workflow automation tool, has a reflected XSS vulnerability (a type of attack where malicious code is injected into a webpage and executed in a user's browser) in its Facebook, WhatsApp, and Microsoft Teams trigger endpoints. When a logged-in user visits a specially crafted URL, an unsanitized query parameter gets reflected back in the response, allowing an attacker to run arbitrary code in the user's browser within n8n's origin.
A vulnerability in n8n (a workflow automation tool) allows authenticated users to perform prototype pollution (a type of attack that modifies the base object all objects inherit from) through the Microsoft SQL node by providing a specially crafted table parameter. This attack can completely break the n8n instance by causing validation failures across the entire application until the server is restarted.
Crawl4AI's Docker API server had two security flaws that let attackers steal secrets. First, attackers could change where the server sent LLM (large language model) requests by controlling a `base_url` parameter, causing the server to send its API keys to an attacker's server. Second, attackers could read any environment variable (including passwords and secret keys) from the server by using the `env:` syntax in configuration, then combine this with the first flaw to steal those secrets. Since the Docker API required no authentication by default, anyone could exploit these flaws.
Crawl4AI's Docker API had a security flaw in its SSRF protection (a filter meant to block requests to internal servers). An attacker could bypass this filter by encoding internal IP addresses using IPv6 transition forms like NAT64, 6to4, or IPv4-mapped addresses, potentially accessing internal services and cloud metadata endpoints without needing credentials.
Crawl4AI, a Docker API server for web crawling, had seven critical security vulnerabilities including arbitrary file writes, SSRF (server-side request forgery, where attackers trick the server into making requests to internal networks), authentication bypass on monitoring endpoints, stored XSS (cross-site scripting, where malicious code executes in users' browsers), arbitrary JavaScript execution, a hardcoded JWT secret key, and SSRF via direct crawl endpoints. The vulnerabilities ranged from CVSS scores of 6.1 to 9.8, with fixes applied through input validation, blocklists for dangerous IP ranges, authentication requirements, HTML escaping, and environment variable controls.
stable-diffusion.cpp, a C/C++ library for running AI image generation models, has a heap buffer overflow vulnerability (a memory corruption bug where data writes beyond allocated memory) in how it parses PyTorch checkpoint files (.ckpt files). A malicious checkpoint file could crash the application or potentially execute harmful code if loaded by an application using vulnerable versions before master-584-0a7ae07.
stable-diffusion.cpp is a C/C++ library for running image generation models, but versions before master-584-0a7ae07 have an out-of-bounds reads error (a bug where the program accesses memory beyond its allocated space) when parsing .ckpt checkpoint files (model weight files saved in a specific format). A specially crafted or incomplete .ckpt file could crash the program or cause security issues if loaded from an untrusted source like a public model-sharing website.
n8n, a workflow automation tool, has a SQL injection vulnerability (a flaw that lets attackers insert malicious database commands) in its Postgres v1 and TimescaleDB nodes. An authenticated user with permission to create or edit workflows could exploit this to run arbitrary SQL commands against connected databases with the privileges of the configured database account.
A security flaw in n8n (a workflow automation tool) allowed authenticated users to bypass file access restrictions by using the Git node's Clone and Push operations with local filesystem paths, potentially letting them read files they shouldn't have access to. The vulnerability has been patched in specific versions of n8n.
An authenticated user with permission to create or modify workflows in n8n could escape the Python sandbox (a restricted environment meant to safely run untrusted code) and execute arbitrary code on the task runner container. This vulnerability only affects instances where the Python Task Runner feature is enabled.
vLLM has an authentication bypass vulnerability in its OpenAI API protection. An attacker can craft a request with a specially crafted Host header (containing special characters like `/` or `?`) to trick the authentication check into looking at the wrong URL path, allowing them to use the API without providing the required `VLLM_API_KEY`. This only affects vLLM instances exposed directly to attackers; those behind a proper web server like nginx are protected.
Langflow's Shareable Playground feature allows unauthenticated users to execute public workflows through a special endpoint. This endpoint accepts a list of files that can be read from either the local system or S3 storage (cloud file storage), potentially exposing sensitive files if the workflow is configured to read them. An attacker could craft a request specifying arbitrary file paths to extract data without authentication.
Langflow's Shareable Playground feature contains a critical RCE (remote code execution, where an attacker can run commands on a system they don't own) vulnerability that allows unauthenticated users to execute arbitrary Python code. By sharing a flow and then modifying the code field in the API request to the `/api/v1/build_public_tmp` endpoint, an attacker can run malicious commands on the server.
Langflow has a path traversal vulnerability (a security flaw where an attacker can access files outside intended directories) in its Knowledge Bases API that allows authenticated attackers to create files and directories anywhere on the server by supplying malicious names like '../victim_user/evil_kb' or '/tmp/pwned' to the creation endpoint, potentially compromising data across users and corrupting knowledge bases.
vLLM has a security vulnerability where an `assert` statement (a line of code that checks a condition) used to restrict which activation functions can be loaded is removed when Python runs in optimized mode, allowing attackers to publish malicious models on HuggingFace that execute arbitrary code when loaded.
Langflow's monitor API has 7 endpoints that lack ownership checks, allowing any authenticated user to read, modify, or delete another user's data like messages, sessions, and LLM logs through IDOR/BOLA (insecure direct object references/broken object-level authorization, where an attacker can access resources by guessing or knowing their IDs). The source code shows that the correct ownership-checking pattern exists in one endpoint but was not applied consistently across the other vulnerable endpoints.
LangChain has a path traversal vulnerability (a security flaw where attackers can access files outside an intended directory) in its file-search and configuration-loading components. These components don't properly validate that resolved file paths stay within their intended root directory, allowing attackers to use glob patterns (wildcards like *.txt), symlinks (shortcuts to files), or specially crafted path strings to access files they shouldn't. If an untrusted source, including an LLM, influences the paths or search patterns, attackers could read files outside the intended boundary.
Fix: The issue has been fixed in n8n versions 2.25.7 and 2.26.2. Users should upgrade to one of these versions or later to remediate the vulnerability. As temporary workarounds, administrators can limit workflow creation and editing permissions to 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. The source notes these workarounds do not fully remediate the risk and should only be short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.55, 2.25.7, and 2.26.2. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators can: limit workflow creation and editing permissions to fully trusted users only, or disable the Chat Trigger node by adding `@n8n/n8n-nodes-langchain.chatTrigger` to the `NODES_EXCLUDE` environment variable. 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 version 2.24.0. Users should upgrade to this version or later. If upgrading is not immediately possible, administrators can temporarily: (1) limit workflow creation and activation permissions to fully trusted users only, or (2) disable the affected nodes by adding `n8n-nodes-base.facebookTrigger`, `n8n-nodes-base.whatsAppTrigger`, `n8n-nodes-base.facebookLeadAdsTrigger`, and `n8n-nodes-base.microsoftTeamsTrigger` to the `NODES_EXCLUDE` environment variable. 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 version 2.24.0. Users should upgrade to this version or later. If upgrading immediately is not possible, administrators can temporarily: (1) restrict workflow creation and editing permissions to trusted users only, or (2) disable the Microsoft SQL node by adding `n8n-nodes-base.microsoftSql` to the `NODES_EXCLUDE` environment variable. 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 the patched version. The fix prevents request-supplied `base_url` values from being used (the server now only derives the endpoint from its configured provider name), and blocks `env:` resolution of environment variables with names containing SECRET, PASSWORD, PRIVATE, or prefixes like CRAWL4AI* and AWS_SECRET*, or specific names like SECRET_KEY, REDIS_PASSWORD, and TOKEN. As workarounds, enable authentication with `CRAWL4AI_API_TOKEN` or avoid storing sensitive secrets in the server environment alongside provider keys.
GitHub Advisory DatabaseFix: The blocklist is replaced by a single rule: reject any resolved IP where `not ip.is_global`, evaluated on the address AND every embedded IPv4 transition form (v4-mapped, NAT64 `64:ff9b::/96`, 6to4 `2002::/16`, v4-compat `::/96`). Error messages are now opaque and no longer echo the resolved IP. Alternatively, upgrade to the patched version, enable authentication via `CRAWL4AI_API_TOKEN`, or restrict the container's outbound network access through firewall rules.
GitHub Advisory DatabaseFix: Upgrade to the patched version (recommended). Additionally, set `CRAWL4AI_API_TOKEN` to enable authentication, set a strong `SECRET_KEY` with minimum 32 characters if using JWT, and restrict network access to the Docker API. The fixes include: `validate_output_path()` restricting writes to `CRAWL4AI_OUTPUT_DIR`, `validate_webhook_url()` blocklisting RFC 1918/loopback/cloud metadata IPs, adding `dependencies=[Depends(token_dep)]` to the monitor router, server-side `html.escape()` and client-side `escapeHtml()` for XSS protection, disabling `/execute_js` by default via `CRAWL4AI_EXECUTE_JS_ENABLED` env var, removing the default JWT secret and auto-generating an ephemeral key, and normalizing IPv6-mapped IPv4 addresses before blocklist checking on all crawl/md/llm endpoints.
GitHub Advisory DatabaseFix: Update to version master-584-0a7ae07 or later. As a temporary workaround if immediate updates are not possible, avoid loading .ckpt files from untrusted sources and use trusted model sources or safer formats such as .safetensors instead.
NVD/CVE DatabaseFix: Update to version master-584-0a7ae07 or later. If immediate updating is not possible, avoid loading .ckpt files from untrusted sources and use safer formats such as .safetensors instead.
NVD/CVE DatabaseFix: The issue has been fixed in n8n versions 2.25.7 and 2.26.2. Users should upgrade to one of these versions or later to remediate the vulnerability. As temporary workarounds, administrators can limit workflow creation and editing permissions to fully trusted users only, or disable the Postgres and TimescaleDB nodes by adding `n8n-nodes-base.postgres` and `n8n-nodes-base.timescaleDb` to the `NODES_EXCLUDE` environment variable. However, the source notes that 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.48, 2.21.8, or 2.22.4 or later. If immediate upgrading is not possible, administrators can temporarily: (1) restrict workflow creation and editing permissions to fully trusted users only, or (2) disable the Git node by adding `n8n-nodes-base.git` to the `NODES_EXCLUDE` environment variable. 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.48, 2.21.8, and 2.22.4. Users should upgrade to one of these versions or later. As temporary workarounds while upgrading: 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. The source notes these workarounds do not fully remediate the risk and should only be short-term measures.
GitHub Advisory DatabaseFix: The issue was fixed in PR #12337 by introducing a `_validate_kb_path_containment()` helper function that uses `Path.is_relative_to()` (instead of `startswith()`) to enforce strict path boundaries and prevent traversal attacks. This validation is applied before any filesystem operations, and regression tests were added to verify that traversal payloads return a 403 Forbidden response.
GitHub Advisory DatabaseFix: Replace the `assert` with an explicit conditional raise. The source provides this fix: `if not function_name.startswith("torch.nn.modules."): raise ValueError("Loading of activation functions is restricted to torch.nn.modules for security reasons")`
Hugging Face Security AdvisoriesFix: The patches will canonicalize candidate paths (resolve symlinks to their actual targets) and verify the resolved real path stays within the configured root before reading files; normalize search patterns so they cannot escape the root; make configuration loaders confine resolved path fields and reject symlink escapes unless the caller explicitly enables dangerous loading; enforce path-segment boundaries in path-prefix checks; and make path validation work consistently across different operating systems. Callers that intentionally reference external paths can opt in via the existing dangerous-loading flag.
GitHub Advisory Database