Advisories
Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
Security vulnerabilities, privacy incidents, safety concerns, and policy updates affecting LLMs and AI agents.
3,134 items
Agno's PythonTools in libs/agno/agno/tools/python.py has a path traversal flaw in the file_name argument of the read_file, save_to_file and run_python_file actions. Attackers can supply sequences such as '../../../../../../etc/passwd' to escape base_dir, directly or through prompt injection, gaining arbitrary file read, arbitrary file write, or arbitrary Python code execution with the process user's authority.
In Splunk AI Toolkit versions below 6.0.0, a user holding the "power" Splunk role could execute arbitrary code on the Splunk server by loading a model file with crafted sparse matrix data. The flaw is a model codec that deserializes sparse matrix data without guarding against embedded pickle content.
In Splunk AI Toolkit versions below 6.0.0, a low-privileged user who lacks the "admin" or "power" Splunk roles can start, stop, and configure containers and read or modify connection and configuration data through the REST API. The flaw exists because multiple REST API handlers do not enforce authorization checks.
In Splunk AI Toolkit versions below 6.0.0, a user who can upload models can overwrite another user's model during its upload by sending a concurrent upload request with the same model name. The flaw is a race condition: Splunk AI Toolkit does not verify that uploaded content belongs to the request creating the model lookup entry, so the resulting lookup can reference attacker-controlled content.
CVE-2026-76391 affects Splunk AI Toolkit versions below 6.0.0. A user without the "admin" or "power" Splunk roles can run searches with system-level privileges, access relevant data, affect system integrity, and read or delete other users' search jobs through Agent Run History. The flaw exists because the Agent Run History handler swaps the calling user's session key for a system authentication token before performing search operations.
GHSA-wppf-h75h-6pm6 reports that hardened mode in mcp-searxng's web_url_read still permits SSRF to internal addresses despite PR #79, which blocks only the DNS-resolves-to-loopback case. The reporter tested PR commit e55d28e7be6786a71cd7a0eaf13d3ec9d0b734d4 with MCP_HTTP_HARDEN=true and MCP_HTTP_ALLOW_PRIVATE_URLS unset, and found three bypasses: redirects to 127.0.0.1 are followed without re-validation, 0.0.0.0 is not treated as internal, and [::ffff:127.0.0.1] is canonicalized to [::ffff:7f00:1] and missed by the dotted-decimal regex. All three returned a loopback sentinel service.
The web_url_read tool in mcp-searxng 1.1.0 fetches caller-supplied URLs server-side, but its internal-address guard, assertUrlAllowed, runs only when MCP_HTTP_HARDEN=true, which is off by default. With default settings an attacker who can influence the URL can make the server fetch internal HTTP services and cloud metadata endpoints and return their contents, confirmed with a loopback request to 127.0.0.1.
Enable the internal-address filtering by default (fail safe): make assertUrlAllowed run unconditionally and require an explicit opt-out only for trusted environments. Strengthen the check to resolve the host and reject loopback, link-local/metadata (169.254.0.0/16), 0.0.0.0/8, and private ranges, and re-validate on every redirect hop (or pin to the validated IP).
The export_space and import_space tools in @contentful/mcp-tools accept LLM-controlled host and proxy parameters and spread them unfiltered into the options passed to contentful-export and contentful-import. Those options, including the server's CMA Personal Access Token, reach the Contentful Management API client, which sends the token as a Bearer header to the attacker-supplied host. An attacker who can invoke MCP tools, or plant instructions in Contentful content the LLM reads, can redirect CMA requests and the PAT to an attacker-controlled endpoint.
claude-faf-mcp, an MCP server, resolves caller-supplied `path` arguments into filesystem reads and writes without confining them to a trusted project directory. A caller, or an LLM prompt-injected through attacker-controlled content, can read files such as SSH keys, cloud credentials and `.env` files, and `faf_write` can write outside the project.
Fix: Fixed in 5.7.2, which confines every caller-supplied `path` before filesystem access. Upgrade with `npm install -g claude-faf-mcp@5.7.2` or the one-click `.mcpb` install. Workaround if upgrading is not immediate: run the server only against trusted local projects and set `FAF_ALLOWED_ROOTS` (patched versions) to a single project directory.
faf-mcp versions before 2.1.3 accept a caller-controlled `path` argument in the shared `getProjectPath()` chokepoint and the `faf_read` and `faf_write` tools, resolving it without confinement to a project directory. An MCP client, or a prompt-injected LLM issuing a tool call, can read files such as SSH keys, cloud credentials and `.env` files, and `faf_write` can write outside the project (CWE-200).
Fix: Fixed in 2.1.3, which confines every caller-supplied `path` before filesystem access. Upgrade with `npm install -g faf-mcp@2.1.3` or `npx faf-mcp`. If upgrading is not possible immediately, run the server only against trusted local projects and set `FAF_ALLOWED_ROOTS` (patched versions) to a single project directory.
grok-faf-mcp, an MCP server, has several FAF tools (refresh_faf, faf_score, faf_get_orchestration_policy, refresh_blend, faf_read, faf_write) that accept a caller-controlled path argument and read it without confinement to a trusted project directory. An MCP client, or an LLM prompt-injected through attacker-controlled content, can use absolute paths or ../ traversal to read files such as SSH keys, cloud credentials and .env files, with OS file permissions as the only remaining limit.
Fix: Fixed in 1.5.3, which confines every caller-supplied path before filesystem access: reads are restricted to .faf and .fafm context files, general file operations are confined to the project root (override with FAF_ALLOWED_ROOTS), paths are canonicalized through symlinks, and absolute paths and ../ escapes are rejected. Upgrade with `npm install -g grok-faf-mcp@1.5.3` or `bunx grok-faf-mcp`. If upgrading is not possible immediately, run the server only against trusted local projects and set FAF_ALLOWED_ROOTS to a single project directory.
In affected versions of `langgraph-api`, run creation checked assistant authorization with an incomplete `assistants.search` event rather than `assistants.read`. In deployments whose custom handlers register only an `assistants.read` handler, no handler ran on that path and the owner constraint was dropped, so a run could reference another user's private assistant. The response then returned that assistant's `metadata`, `config` and `context`. The source reports no evidence of exploitation in the wild.
Fixed in `langgraph-api` 0.10.0. Run and cron creation now dispatch the `assistants.read` event, and client-supplied metadata is no longer forwarded into it. Deployments with custom handlers should register an `assistants.read` handler (or a global handler) that returns an owner-style filter, confirm parity across the read, search and run/cron creation paths, and move any logic that read or stamped the metadata field on that event into the run/cron create handlers.
In affected versions of langgraph-api (the LangGraph Server runtime), a run or cron created with a relative webhook target was delivered through an in-process loopback transport that the authentication middleware treats as internal and does not authenticate. This let such requests reach thread and run routes without the usual authentication context, so in deployments that scope data by owner, one user could create a run on or modify another user's thread, and limited thread metadata could appear in the created run record.
CVE-2026-19875 affects IBM Langflow OSS 1.0.0 through 1.10.0. A remote attacker can overwrite the administrator email information and abuse the server as an outbound relay, because the registration endpoint lacks authentication (CWE-306, Missing Authentication for Critical Function).
The NumpyReader class in monai/data/image_reader.py calls np.load(name, allow_pickle=True) at line 1276, so loading a crafted .npy or .npz file can execute arbitrary code. The source states this affects all MONAI versions up to and including the latest commit (5b71547), and that users cannot override allow_pickle because it is hardcoded to True. LoadImage selects NumpyReader automatically for .npy and .npz files, so standard MONAI data pipelines are exposed.
MONAI's algo_from_pickle() in monai/auto3dseg/utils.py still calls pickle.loads() on attacker-supplied files in v1.5.2, despite GHSA-89gg-p5r5-q6r4 claiming the issue was patched. The source reports that the file was last changed on 2024-07-12, that all three pickle.loads() calls remain unchanged in v1.5.1 and v1.5.2, and that the advisory's referenced patch is a Zip Slip fix. Any application passing an attacker-controlled path to this function can achieve code execution.
NVIDIA Triton Inference Server for Linux contains an absolute path traversal vulnerability, tracked as CWE-36. A successful exploit might lead to code execution. The NVD assessment has not yet been provided, and NVIDIA published the advisory under its product-security repository.
NVIDIA Triton Inference Server for Linux contains an improper input validation flaw, tracked as CVE-2026-47629 and classified as CWE-20. A successful exploit might lead to denial of service. NVD has not yet provided an assessment, and the source names no affected versions.
NVIDIA Triton Inference Server for Linux contains a vulnerability, tracked as CVE-2026-47628 and classified as CWE-770 (Allocation of Resources Without Limits or Throttling). An attacker could cause an allocation of resources without limits, and a successful exploit might lead to denial of service. NVD had not yet provided an assessment at the time of the record.
CVE-2026-47627 affects NVIDIA Triton Inference Server for Linux and is classified as CWE-22, Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). The source states that an attacker could cause path traversal, and a successful exploit might lead to denial of service. NVD had not yet provided an assessment when the entry was published on 08/18/2026.
Fix: Fixed in langgraph-api 0.10.0, which denies loopback webhook delivery by default via the webhooks.url.disable_loopback policy (defaults to enabled), covering relative targets, localhost-style hostnames, loopback address ranges and hostnames resolving into the loopback range. Deployments needing same-process webhook delivery can set webhooks.url.disable_loopback: false in langgraph.json (or the equivalent LANGGRAPH_WEBHOOKS configuration), only when they control the routes those webhooks reach, since delivery is unauthenticated. Operational guidance: upgrade to a release containing this change, keep loopback delivery disabled unless required, and if enabled, restrict it to routes you control and apply authorization within those routes.