Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
DeepSeek TUI's `run_tests` tool runs without user approval (it has `ApprovalRequirement::Auto`), which allows arbitrary code execution through test files and build scripts in a repository. An attacker can create a malicious repository with hidden commands in test code and an `AGENTS.md` file (prompt injection, where hidden instructions are placed in input meant for an AI) that tricks the AI model into running tests automatically on startup, executing the attacker's code with zero user confirmation.
Fix: Change `run_tests` to require approval by modifying the approval requirement function: `fn approval_requirement(&self) -> ApprovalRequirement { ApprovalRequirement::Required }`. This matches the approval gate used by `exec_shell` (a tool for running shell commands), so users will see a prompt before tests run, though they can still approve it quickly.
GitHub Advisory DatabaseDeepSeek's TUI has a security flaw in its `fetch_url` tool where it blocks direct requests to restricted IP addresses (like cloud metadata endpoints and private networks) but fails to re-check redirect targets. An attacker can bypass this SSRF protection (server-side request forgery, where an AI is tricked into accessing internal systems) by providing a public URL that redirects to a restricted IP, allowing potential theft of cloud credentials and sensitive data on cloud-hosted instances.
Open WebUI has a race condition (TOCTOU, or time-of-check-time-of-use, where a system checks a condition and then uses that information, but the condition can change in between) in its LDAP and OAuth login flows that allows multiple users to become administrators on a fresh installation. When the first user logs in via LDAP or OAuth, the system checks if the database is empty and assigns the admin role before creating the user account, but multiple concurrent login requests can all see an empty database and all become admins. The regular signup method was already fixed with a safer approach, but LDAP and OAuth were never updated with the same fix.
Any authenticated user can permanently delete files owned by other users in Open WebUI when those files are referenced in shared chats, because the authorization check (the code that verifies whether a user should be allowed to perform an action) ignores both the user's identity and the type of operation being requested. File IDs can be discovered by users with read access to knowledge bases (repositories of documents), making this vulnerability practical to exploit.
Open WebUI had an unauthenticated endpoint at GET `/api/v1/memories/ef` that triggered embedding generation (the process of converting text into numerical vectors for AI understanding), allowing anyone to make requests without logging in. An attacker could repeatedly call this endpoint to waste computing resources, rack up charges if a paid embedding service like OpenAI was configured, or degrade the service for legitimate users.
Open WebUI has a security flaw where authenticated users can access and modify other users' private files by exploiting two endpoints that don't properly check file ownership. In the first case, attackers can inject victim file IDs into their own folders to make the AI read private documents as context. In the second case, attackers can attach victim files to their own knowledge bases (collections of documents used for RAG, retrieval-augmented generation) to read and overwrite those files entirely.
Open WebUI has a vulnerability where the `_validate_collection_access()` function (a security check) only blocks access to collections with specific name prefixes, but knowledge bases use raw UUIDs (unique identifiers) as collection names, so the check skips them entirely. Any logged-in user who knows a private knowledge base's UUID can read its contents or inject fake data into it through the retrieval API endpoints, even though the knowledge API itself correctly blocks that access.
Open WebUI's `/api/v1/retrieval/` endpoint exposes RAG (retrieval-augmented generation, a technique where an AI pulls in external documents to answer questions) configuration details like embedding models and chunking parameters to anyone on the internet without requiring login credentials. An attacker can make a single HTTP request to discover the AI infrastructure setup and craft attacks that exploit how documents are split and retrieved.
Open WebUI has a security flaw where an internal-only parameter called `bypass_filter` is accidentally exposed through the HTTP query string on chat endpoints. Any authenticated user can append `?bypass_filter=true` to requests, which skips access control checks (the rules that prevent regular users from using admin-restricted models), allowing them to use models they shouldn't have permission to access.
In Open WebUI v0.6.40, a regular user can view the system prompt (the hidden instructions that control how an AI model behaves) that an admin set up, by making a simple web request to /api/models. This exposes confidential information because attackers can learn how the model works internally and potentially manipulate its behavior.
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.
Fix: Fixed in v0.9.0 (April 2026). The LDAP and OAuth code paths were updated to use the same insert-first-check-after pattern as the signup handler: insert the new user with DEFAULT_USER_ROLE first without checking user count, then after the insert commits, atomically check if `Users.get_num_users() == 1`. Only if this user is the sole user in the database are they promoted to admin via `Users.update_user_role_by_id`. This ensures that if two concurrent first-user registrations both insert users, only one will see the count as 1 and receive admin promotion.
GitHub Advisory DatabaseFix: Gate the shared-chat branch on `access_type` so it only authorizes read operations: `if access_type == "read": chats = Chats.get_shared_chats_by_file_id(file_id, db=db) if chats: return True`. This ensures that only read requests pass the authorization check when a file is in a shared chat, while delete and write requests are blocked.
GitHub Advisory DatabaseFix: Fixed in commit e5035ea31, first released in v0.8.0 (Feb 2026). The `/api/v1/memories/ef` route was removed entirely because it was a debug-style endpoint with no legitimate use. Users should upgrade to version 0.8.0 or later.
GitHub Advisory DatabaseFix: Add `get_verified_user` dependency to the `get_status()` function. Change `@router.get('/') async def get_status(request: Request):` to `@router.get('/') async def get_status(request: Request, user=Depends(get_verified_user)):`
GitHub Advisory DatabaseFix: 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 Database