Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
Open WebUI has a stored cross-site scripting (XSS) vulnerability in its SVG renderer, meaning an attacker can permanently save malicious HTML and JavaScript code that runs when other users view it. An attacker can trick the SVG editor into executing arbitrary code by adding malicious payloads like `<img src=a onerror=alert(document.domain)>`, which could be used to steal sensitive data or take over user accounts when the compromised conversation is shared.
Open WebUI has a security flaw where API key restrictions can be bypassed by using the `x-api-key` header (a custom header for authentication) instead of the standard `Authorization` header. An admin can restrict what endpoints an API key can access, but the same key sent via `x-api-key` bypasses these restrictions entirely and allows full access to protected endpoints like the messages API.
A vulnerability in Amazon SageMaker Python SDK (a tool for building machine learning models on AWS) allows an attacker with write access to S3 (Amazon's cloud storage service) to execute malicious code by replacing model files with a specially crafted pickle file (a Python format for storing objects) that isn't checked for authenticity before being used. This only affects versions before v2.257.2 and v3.8.0, and requires the attacker to already have permission to write to the storage location.
Amazon SageMaker Python SDK has two critical vulnerabilities in its model deployment tools. CVE-2026-8596 exposes an encryption key as plaintext in APIs, allowing attackers to forge signatures and run malicious code, while CVE-2026-8597 skips integrity checks when loading model files, letting attackers replace them with malicious code that executes without verification. Both vulnerabilities require the attacker to have certain AWS permissions and access to model storage.
Hatchet is a platform for managing background tasks (work done separately from main application logic), AI agents, and workflows at scale. Before version 0.83.39, a missing authorization check on one API endpoint (GET /api/v1/stable/dags/tasks) allowed any authenticated user to view task details from other organizations (tenants) on the same Hatchet instance by providing another tenant's identifier.
OpenTelemetry Java's baggage propagation (the mechanism for passing request context data across services) didn't enforce size limits, causing unbounded memory allocation (unlimited memory usage) and CPU consumption when parsing oversized baggage headers. This problem can spread to downstream services that never received the original malicious request because baggage is automatically re-injected into every outgoing request.
FlowiseAI's Evaluator feature has a mass-assignment vulnerability (a bug where client-controlled data is copied directly into server objects without filtering) that allows authenticated users to change an evaluator's `workspaceId` field, moving it to another workspace they don't own. This breaks workspace isolation (the separation that keeps different teams' data apart) and lets attackers in workspace B read, modify, and use evaluators belonging to workspace A.
FlowiseAI has a mass assignment vulnerability (a bug where client input is copied directly into objects without filtering) in its Evaluation feature that allows authenticated users to move evaluations between workspaces by including a `workspaceId` field in their request. This breaks workspace isolation (the separation that keeps data from different teams or organizations separate) and allows attackers to access or modify other workspaces' evaluation data, including sensitive information like model outputs and prompts.
FlowiseAI has a mass assignment vulnerability (a code pattern where user input is directly copied into a database object without filtering) in its DatasetRow feature that allows authenticated attackers to change which workspace owns a data row by including a `workspaceId` field in their request, giving them access to other teams' data. This breaks workspace isolation (the security boundary that keeps different teams' data separate) and lets attackers move training records between workspaces they shouldn't have access to.
FlowiseAI has a mass assignment vulnerability (a flaw where client input is copied directly into database objects without filtering) in its Dataset feature that lets authenticated users move datasets between workspaces by including a fake `workspaceId` field in their request. This breaks workspace isolation (the boundary that keeps each workspace's data separate) and allows attackers to steal or modify datasets belonging to other workspaces.
FlowiseAI has a mass assignment vulnerability (a security flaw where an attacker can modify database fields they shouldn't be able to) in its CustomTemplate feature that allows authenticated users to move templates between workspaces by including a `workspaceId` field in their request. This breaks workspace isolation (the separation that prevents users from accessing data outside their assigned workspace), allowing an attacker to take over templates from other workspaces, since the code uses `Object.assign()` to copy user input directly into database records without filtering which fields are allowed.
FlowiseAI has a mass-assignment vulnerability (a bug where user input is copied directly into database objects without filtering) in its Assistant service that allows authenticated attackers to change the `workspaceId` field of an assistant they own, moving it to another workspace and gaining unauthorized access. This breaks workspace isolation (the security boundary that keeps data from different organizations separate) and exposes sensitive information like LLM configuration and credentials to unintended users.
FlowiseAI's OpenAI Assistants Vector Store endpoints lack permission checks, allowing any authenticated user to create, modify, delete, or upload files to vector stores regardless of their assigned role. This missing authorization (CWE-306, a security weakness where critical functions don't verify user permissions) has a severity score of about 8.1, meaning attackers with basic access could steal or destroy data.
n8n, a workflow automation tool, had a security flaw where OAuth credential reconnect endpoints checked for read-only access instead of update access. This meant an authenticated user with limited permissions could hijack shared credentials by reconnecting them to their own external account, allowing them to intercept data or take over workflows that other users depend on.
n8n (a workflow automation platform) has a SQL injection vulnerability (a type of attack where malicious code is inserted into database queries) in its Source Control Pull feature. An attacker with write access to a connected git repository could commit a malicious file that, when pulled by an administrator, executes harmful SQL commands on n8n's internal PostgreSQL database (the system that stores data).
n8n, a workflow automation tool, has a security flaw in its XML node (a tool for processing XML data) that lets authenticated users bypass a previous security patch and potentially achieve RCE (remote code execution, where an attacker runs commands on a system they don't control) on the n8n server. The vulnerability requires the attacker to have permission to create or modify workflows and works best when combined with other nodes.
A vulnerability in n8n (a workflow automation tool) allows authenticated users with permission to create or modify workflows to read arbitrary files from the server by injecting malicious commands into the Git node's Push operation. This could potentially give an attacker complete control over the n8n server.
An authenticated user in n8n (a workflow automation tool) could exploit an unvalidated pagination parameter in the HTTP Request node to achieve prototype pollution (a type of attack that corrupts an object used by many parts of a program), potentially leading to RCE (remote code execution, where an attacker can run commands on a system they don't control). This vulnerability requires the attacker to have permission to create or modify workflows.
PyTorch Lightning (a framework for training and adjusting AI models) versions 2.6.2 have introduced a credential harvesting mechanism (a way to steal login information), rated as critical severity with a CVSS score (a 0-10 rating of how severe a vulnerability is) of 9.3. The vulnerability allows attackers to gain complete control over the affected system without needing special access or user interaction.
FlowiseAI has a vulnerability where encrypted credential data (like API keys and passwords) is accidentally exposed when users request credentials using a filter parameter. The code correctly hides this sensitive data when no filter is used, but fails to remove it when filtering by credential name, allowing authenticated users to steal encrypted credentials if they also access the encryption key file stored on the system.
Fix: Upgrade to Amazon SageMaker Python SDK v2.257.2 or v3.8.0, and rebuild any Triton models previously created with ModelBuilder using the updated SDK.
NVD/CVE DatabaseFix: Update Hatchet to version 0.83.39 or later, where this vulnerability is fixed.
NVD/CVE DatabaseFix: Update to version 1.62.0 or later. The fix enforces limits consistent with the W3C Baggage specification: maximum total baggage size of 8,192 bytes and maximum 64 entries. Headers exceeding either limit are dropped at the point the limit is reached, while already-extracted valid entries are retained.
GitHub Advisory DatabaseFix: The fix is already applied in PR https://github.com/FlowiseAI/Flowise/pull/6050. The patched code uses an allowlist pattern: instead of copying all fields from the request body via `Object.assign(...)`, the code explicitly checks each allowed field one at a time before copying it (e.g., `if (body.allowed_field_1 !== undefined) updatedEvaluator.allowed_field_1 = body.allowed_field_1`). This ensures only safe fields can be set, and `workspaceId` is no longer accepted from the client.
GitHub Advisory DatabaseFix: The source text states the vulnerability was "already fixed in PR https://github.com/FlowiseAI/Flowise/pull/6050 (allowlist pattern applied)." The fix implements an allowlist pattern (explicitly specifying which fields from the request body are permitted to be copied onto the entity) rather than blindly accepting all fields via `Object.assign()`. This same pattern was previously applied to the DocumentStore entity in commit 840d2ae.
GitHub Advisory DatabaseFix: The source text states the vulnerability is "Already fixed in PR https://github.com/FlowiseAI/Flowise/pull/6051 (allowlist pattern applied)." The fix implements an allowlist pattern that explicitly specifies which fields from the user's request are permitted to be copied into the DatasetRow object, preventing malicious fields like `workspaceId` from being accepted.
GitHub Advisory DatabaseFix: The vulnerability is already fixed in PR https://github.com/FlowiseAI/Flowise/pull/6051, which applies an allowlist pattern (explicitly listing which fields are allowed to be copied from client input) to the Dataset controller, matching the approach used in commit 840d2ae for the DocumentStore entity.
GitHub Advisory DatabaseFix: The fix uses an allowlist pattern (explicitly allowing only certain safe fields to be copied from user input) and has already been applied in PR https://github.com/FlowiseAI/Flowise/pull/6129. The vulnerable code at line 211 of `packages/server/src/services/marketplaces/index.ts` that used `Object.assign(newTemplate, body)` was replaced with code that only copies approved fields, matching the same fix pattern that was previously applied to the DocumentStore entity in commit 840d2ae.
GitHub Advisory DatabaseFix: The vulnerability is already fixed in PR https://github.com/FlowiseAI/Flowise/pull/6128, which applies an allowlist pattern (explicitly specifying which fields are allowed to be copied from user input) to the Assistant service, matching the fix previously applied to the DocumentStore entity in commit 840d2ae.
GitHub Advisory DatabaseFix: Upgrade to n8n version 1.123.43, 2.20.7, or 2.21.1 or later. If upgrading immediately is not possible, administrators should restrict credential sharing to fully trusted users only and audit shared credentials for unexpected OAuth token changes, revoking any tokens that may have been replaced. 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 1.123.43, 2.20.7, and 2.21.1. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should: disable the Source Control feature if not actively required, restrict write access to the connected git repository to fully trusted users only, or avoid pulling from repositories that may have been modified by untrusted parties. The source notes 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.43, 2.20.7, or 2.22.1 or later. If immediate upgrading is not possible, administrators can temporarily limit workflow creation and editing permissions to trusted users only, or disable the XML node by adding `n8n-nodes-base.xml` to the `NODES_EXCLUDE` environment variable (a setting that controls which tools are available). These workarounds do not fully fix the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: Upgrade to n8n versions 1.123.43, 2.20.7, or 2.22.1 or later. If upgrading immediately is not possible, temporarily limit workflow creation and editing permissions to trusted users only, or disable the Git node by adding `n8n-nodes-base.git` to the `NODES_EXCLUDE` environment variable (though these workarounds do not fully fix the risk and should only be used short-term).
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.43, 2.20.7, and 2.22.1. 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 HTTP Request node by adding `n8n-nodes-base.httpRequest` 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 Database