Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
Gradio, a Python package for building AI demos, had a vulnerability (SSRF, or server-side request forgery, where an attacker tricks a server into making requests it shouldn't) before version 6.6.0 that let attackers access internal services and private networks by hosting a malicious Gradio Space that victims load with the `gr.load()` function.
Fix: Update Gradio to version 6.6.0 or later, which fixes the issue.
NVD/CVE DatabaseGradio, a Python package for building AI interfaces quickly, has a vulnerability in versions before 6.6.0 where the _redirect_to_target() function doesn't validate the _target_url parameter, allowing attackers to redirect users to malicious external websites through the /logout and /login/callback endpoints on apps using OAuth (a login system). This vulnerability only affects Gradio apps running on Hugging Face Spaces with gr.LoginButton enabled.
Gradio (an open-source Python package for building web interfaces quickly) has a vulnerability in versions before 6.7 on Windows with Python 3.13 and newer that allows attackers to read any file from the server by exploiting a flaw in how the software checks if file paths are absolute (starting from the root directory). The vulnerability exists because Python 3.13 changed how it defines absolute paths, breaking Gradio's protections against path traversal (accessing files outside intended directories).
Gradio, a Python package for building web interfaces, has a security flaw in versions 4.16.0 through 6.5.x where it automatically enables fake OAuth routes (authentication shortcuts) that accidentally expose the server owner's Hugging Face access token (a credential used to authenticate with Hugging Face services) to anyone who visits the login page. An attacker can steal this token because the session cookie (a small file storing login information) is signed with a hardcoded secret, making it easy to decode.
A vulnerability in n8n's Zendesk Trigger node (a tool that automatically starts workflows when Zendesk sends data) allows attackers to forge webhook requests, meaning they can trigger workflows with fake data because the node doesn't verify the HMAC-SHA256 signature (a cryptographic check that confirms a message is authentic). This lets anyone who knows the webhook URL send malicious payloads to the connected workflow.
A security flaw in n8n's Guardrail node (a component that enforces safety rules on AI outputs) allows users to craft inputs that bypass its default safety instructions. This means someone could trick the guardrail into allowing outputs it should have blocked.
n8n, a workflow automation tool, has a security flaw in its Chat Trigger node where authentication (the process of verifying a user's identity) can be bypassed when configured with n8n User Auth. This only affects users who have specifically set up this non-default authentication method on their Chat Trigger node.
A security flaw in n8n's GitHub Webhook Trigger node allowed attackers to forge webhook messages without proper authentication. The node failed to verify HMAC-SHA256 signatures (a cryptographic check that confirms a message came from GitHub), so anyone knowing the webhook URL could send fake requests and trigger workflows with whatever data they wanted.
n8n (a workflow automation tool) had a SQL injection vulnerability (a type of attack where specially crafted input tricks a database into running unintended commands) in its MySQL, PostgreSQL, and Microsoft SQL nodes. Attackers who could create or edit workflows could inject malicious SQL code through table or column names because these nodes didn't properly escape identifier values when building database queries.
CVE-2026-3071 is a vulnerability in Flair (a machine learning library) versions 0.4.1 and later that allows arbitrary code execution (running unauthorized commands on a system) when loading a malicious model file. The problem occurs because the LanguageModel class deserializes untrusted data (converts data from an external file without checking if it's safe), which can be exploited by attackers who provide specially crafted model files.
Langflow, a tool for building AI-powered agents and workflows, had a vulnerability in versions before 1.8.0 where the CSV Agent node automatically enabled a dangerous Python execution feature. This allowed attackers to run arbitrary Python and operating system commands on the server through prompt injection (tricking the AI by hiding instructions in its input), resulting in RCE (remote code execution, where an attacker can run commands on a system they don't own).
LangGraph versions before 4.0.0 have a remote code execution vulnerability in their caching layer when applications enable cache backends and opt nodes into caching. The vulnerability occurs because the default serializer uses pickle deserialization (a Python feature that can execute arbitrary code) as a fallback when other serialization methods fail, allowing attackers who can write to the cache to execute malicious code.
The zae-limiter library has a security flaw where all rate limit buckets for a single user share the same DynamoDB partition key (the identifier that determines which storage location holds the data), allowing a high-traffic user to exceed DynamoDB's write limits and cause service slowdowns for that user and potentially others sharing the same partition. This vulnerability affects multi-tenant systems, like shared LLM proxies (AI services shared across multiple customers), where one customer's heavy traffic can degrade service for others.
n8n, a workflow automation tool, has a vulnerability where authenticated users with permission to create or modify workflows can exploit expression evaluation (the process of interpreting code within workflow parameters) to execute arbitrary system commands on the host server. This is a serious security flaw because it allows attackers to run unintended commands on the underlying system.
n8n (a workflow automation tool) has a vulnerability where an authenticated user with workflow editing permissions could combine the Read/Write Files from Disk node (a component that modifies files on the server) with git operations (version control commands) to execute arbitrary shell commands (any commands an attacker chooses) on the n8n server. This requires the attacker to already have valid user access.
n8n, a workflow automation tool, has a vulnerability where authenticated users with workflow editing permissions could use the Merge node's SQL query mode to execute arbitrary code (running any commands they want on the server) and write files to the n8n server. This is a serious security issue because it lets trusted insiders cause significant damage.
n8n, a workflow automation tool, has a sandbox escape vulnerability in its JavaScript Task Runner that lets authenticated users run code outside the sandbox (a restricted environment for running untrusted code). On default setups, this could give attackers full control of the n8n server, while on systems using external task runners, attackers could impact other workflows.
n8n had a vulnerability in its Form nodes where an unauthenticated attacker could inject malicious code by submitting specially crafted form data that starts with an equals sign (=), which the system would then execute as an expression. While this vulnerability alone is limited, it could potentially lead to remote code execution if combined with another type of attack that bypasses n8n's expression sandbox (a security boundary that restricts what code can access).
LangChain's `RecursiveUrlLoader` component had a security flaw where it would validate an initial website address but then automatically follow redirects (automatic jumps to different URLs) without checking them, allowing attackers to redirect from a safe public URL to internal or sensitive endpoints. This vulnerability was fixed in version 1.1.18 of the `@langchain/community` package.
Fickling (a Python library for analyzing pickle files, a Python serialization format) has a safety bypass where dangerous operations like network connections and file access are falsely marked as safe when certain opcodes (REDUCE and BUILD, which are pickle instructions) appear in sequence. Attackers can add a simple BUILD opcode to any malicious pickle to evade all five of fickling's safety detection methods.
Fix: Update to Gradio version 6.6.0 or later. Starting in version 6.6.0, the _target_url parameter is sanitized to only use the path, query, and fragment, stripping any scheme or host.
NVD/CVE DatabaseFix: Update Gradio to version 6.7 or later, which fixes the issue.
NVD/CVE DatabaseFix: Update to Gradio version 6.6.0, which fixes the issue.
NVD/CVE DatabaseFix: The issue has been fixed in n8n versions 2.6.2 and 1.123.18. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should limit workflow creation and editing permissions to fully trusted users only, and restrict network access to the n8n webhook endpoint to known Zendesk IP ranges. 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.10.0. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators can limit access to trusted users and review the practical impact of guardrail bypasses in your workflow, then adjust accordingly (though these workarounds do not fully remediate the risk and should only be used as short-term mitigation).
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators can temporarily: limit workflow creation and editing permissions to fully trusted users only, use a different authentication method for the Chat Trigger node, or restrict network access to the webhook endpoint (the URL that receives Chat Trigger requests) to trusted origins. 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.5.0 and 1.123.15. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider these temporary mitigations: (1) Limit workflow creation and editing permissions to fully trusted users only, and (2) Restrict network access to the n8n webhook endpoint to known GitHub webhook IP ranges. 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.4.0. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should: (1) Limit workflow creation and editing permissions to fully trusted users only, or (2) Disable the MySQL, PostgreSQL, and Microsoft SQL nodes by adding `n8n-nodes-base.mySql`, `n8n-nodes-base.postgres`, and `n8n-nodes-base.microsoftSql` to the `NODES_EXCLUDE` environment variable. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: Version 1.8.0 fixes the issue.
NVD/CVE DatabaseFix: Upgrade to langgraph-checkpoint>=4.0.0, which disables pickle fallback by default (pickle_fallback=False).
GitHub Advisory DatabaseFix: The source explicitly describes a remediation design called 'Pre-Shard Buckets' that includes: moving buckets to a new partition key format with sharding (`PK={ns}/BUCKET#{entity}#{resource}#{shard}, SK=#STATE`), auto-injecting a `wcu:1000` reserved limit on every bucket to track DynamoDB write pressure, implementing shard doubling (1→2→4→8) when capacity is exhausted, storing original limits on the bucket with effective limits derived by dividing by shard count, using random or round-robin shard selection with retry logic (maximum 2 retries), lazy shard creation on first access, discovering shards via GSI3 (a secondary index), and implementing a clean break migration with a schema version bump so old buckets are ignored and new buckets are created on first access.
GitHub Advisory DatabaseFix: Upgrade to n8n version 2.10.1, 2.9.3, or 1.123.22 or later. If immediate upgrade is not possible, limit workflow creation and editing permissions to fully trusted users only, and deploy n8n in a hardened environment with restricted operating system privileges and network access. However, these temporary mitigations do not fully remediate the risk.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 2.2.0 and 1.123.8. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators can temporarily: (1) Limit workflow creation and editing permissions to fully trusted users only, or (2) Disable the Read/Write Files from Disk node by adding `n8n-nodes-base.readWriteFile` to the `NODES_EXCLUDE` environment variable. The source notes these workarounds do not fully remediate the risk and should only be short-term measures.
GitHub Advisory DatabaseFix: The vulnerability is fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22 or later. If upgrading immediately is not possible, administrators can temporarily restrict workflow creation and editing permissions to only fully trusted users, or disable the Merge node by adding `n8n-nodes-base.merge` to the `NODES_EXCLUDE` environment variable (a configuration setting that tells n8n which features to turn off). Note: these workarounds do not fully eliminate the risk and are only short-term measures.
GitHub Advisory DatabaseFix: Upgrade to n8n version 2.10.1, 2.9.3, or 1.123.22 or later. If immediate upgrade is not possible, temporarily limit workflow creation and editing permissions to trusted users only, or use external runner mode by setting N8N_RUNNERS_MODE=external to reduce potential damage.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators can temporarily: (1) manually review form nodes to check if they have the problematic configuration, (2) disable the Form node by adding `n8n-nodes-base.form` to the `NODES_EXCLUDE` environment variable, or (3) disable the Form Trigger node by adding `n8n-nodes-base.formTrigger` to the `NODES_EXCLUDE` environment variable. These workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: Upgrade to `@langchain/community` version 1.1.18. This version disables automatic redirects (`redirect: "manual"`), validates each redirect target with `validateSafeUrl()` before following it, and implements a maximum redirect limit to prevent infinite loops.
NVD/CVE DatabaseFix: Potentially unsafe modules have been added to a blocklist in https://github.com/trailofbits/fickling/commit/0c4558d950daf70e134090573450ddcedaf10400.
GitHub Advisory Database