Vulnerabilities

mysql_mcp_server fails to validate Origin/Host headers when running in SSE/HTTP transport mode: the MCP Python SDK's DNS-rebinding protection is left disabled, no CORS or TrustedHost middleware is configured, all routes are unauthenticated, and the service binds to 0.0.0.0 by default. The flaw is triggered whenever MCP_TRANSPORT=sse is set; the default stdio mode is not affected. An attacker with network access to the service, or a victim browser coerced via DNS rebinding against a locally bound instance, can invoke the execute_sql tool to run fully attacker-controlled SQL without credentials, yielding complete data exfiltration and modification, and, if the MySQL account holds FILE privileges, arbitrary file read/write and potential remote code execution via webshell drop. Any deployment of mysql_mcp_server with SSE transport enabled is affected, including the 25 publicly reachable instances identified by internet-wide scanning. No public proof-of-concept or confirmed in-the-wild exploitation is known, and the issue is not listed in CISA KEV.

Do: Upgrade to mysql_mcp_server v0.4.2, which enables the SDK's DNS-rebinding protection via TransportSecuritySettings and recommends binding to 127.0.0.1. Until upgraded, avoid setting MCP_TRANSPORT=sse, bind the service to localhost only, and firewall the port from untrusted networks; also review the configured MySQL account's privileges, especially FILE, and audit for unexpected queries.

ESPHome Device Builder renamed its dashboard authentication environment variables from USERNAME/PASSWORD to ESPHOME_USERNAME/ESPHOME_PASSWORD with no backward-compatible fallback, so standalone deployments that set only the bare names silently lose authentication after upgrading. Because using_password resolves to false, both the REST auth middleware and the WebSocket login gate are disabled, leaving the dashboard open to any unauthenticated client with network access to its port; the only warning is a startup log banner that detached containers (docker run -d) never surface. An attacker who reaches the port gains full dashboard control — editing device configurations, flashing firmware, and per ESPHome's threat model, running arbitrary code at compile time and reading/writing files in the config and data directories. Only standalone Docker/pip deployments relying on the bare env vars are affected; Home Assistant add-on installs (which use --ha-addon and supervisor ingress) and deployments using --username/--password flags or the new ESPHOM_E* names are not. No public proof of concept is known and the flaw is not in the CISA KEV catalog.

Do: Check whether your deployment still sets only USERNAME/PASSWORD and whether startup logs show the 'WITHOUT AUTHENTICATION' banner (inspect with 'docker logs' on detached containers). Migrate credentials to the ESPHOM_EUSERNAME/ESPHOME_PASSWORD environment variables or the --username/--password CLI flags, and immediately restrict network access to the dashboard port (bind to localhost or place behind a firewall/VPN) since an exposed dashboard grants host-equivalent code execution. Home Assistant add-on installations need no action.

The ingress web site of the ESPHome Device Builder Dashboard Home Assistant add-on was bound to 0.0.0.0; because the add-on runs with host networking (for mDNS), this included the host's LAN interface, and that site is intentionally unauthenticated since it is meant to be reached only through the supervisor's ingress proxy, which authenticates the browser upstream. As a result, any device on the same local network could open http://<ha-ip>:<ingress_port>/ directly and reach the full dashboard with no credentials, bypassing supervisor authentication entirely. An attacker gains what the project's threat model describes as host-equivalent capability: running arbitrary Python at compile time via external_components, running arbitrary shell through compile and validation subprocesses, and reading or writing arbitrary files in the config and data directories, including the mounted Home Assistant config directory and the ESPHome devices the add-on manages. Affected users are those running the host-network Home Assistant add-on, where the exposure was present by default with no misconfiguration; the password-gated public port (6052) and standalone installs are not affected. There is no known public proof-of-concept, it is not in CISA KEV, and no in-the-wild exploitation is known; the flaw is fixed in PR #1565.

Do: Update the ESPHome Device Builder Home Assistant add-on to a release containing the PR #1565 fix, which binds the ingress site to loopback and the supervisor gateway (127.0.0.1 / 172.30.32.1) and adds ingress_peer_guard (403 for non-supervisor peers). As an interim mitigation, block LAN access to the add-on's ingress port with a host or network firewall, or set an explicit --ingress-host override. Verify whether any device on the LAN could reach http://<ha-ip>:<ingress_port>/ unauthenticated, and check for signs of prior access such as unexpected external_components entries, compile-time commands, or file changes in the Home Assistant config directory.

CVE-2026-87999 is a server-side request forgery flaw (CWE-918) in Open WebUI, an open-source, self-hosted AI platform, affecting all versions before 0.11.1. The endpoints POST /api/v1/retrieval/process/web and POST /api/v1/retrieval/process/web/search in backend/open_webui/retrieval/web/utils.py relied on Python's globally routable address classification to decide whether a destination was external, so reserved ranges that this check did not reject could still be requested. An authenticated user could therefore make the server fetch and return content from 168.63.129.16, the Azure platform channel, and other reserved ranges, gaining high-impact access to response data (confidentiality: high) with limited integrity impact across a security-scope boundary, which matters most for instances hosted on Microsoft Azure. Any self-hosted Open WebUI deployment prior to 0.11.1 that exposes the retrieval API to authenticated users is affected, with Azure-hosted instances facing the greatest risk. There is no evidence of exploitation: the flaw is not in CISA KEV, no public proof-of-concept is known, and the advisory was assigned by GitHub's CNA.

Do: Upgrade to Open WebUI 0.11.1 or later, which corrects the address classification used by the web retrieval utilities. Prioritize patching Azure-hosted deployments, restrict which authenticated users can call /api/v1/retrieval/process/web and /api/v1/retrieval/process/web/search, and review server logs for fetches to 168.63.129.16 or other reserved ranges.

Open WebUI versions 0.10.0 through versions before 0.11.1 mishandle authorization on the knowledge-base deletion endpoint (DELETE /api/v1/knowledge/{id}/delete in backend/open_webui/routers/knowledge.py): after authorizing the deletion of a knowledge base, the handler also removes the administrator-owned external connection behind it without performing a separate administrator check or checking whether other knowledge bases depend on that connection. A non-administrator user who has write access to a single external knowledge base can trigger this by issuing a deletion request to the API route. The attacker gains the ability to delete shared instance configuration, making every other knowledge base that uses the same connection unavailable, an integrity and availability impact reflected in the CVSS 7.1 score (C:N/I:H/A:L) with no confidentiality loss. Affected users are operators of self-hosted Open WebUI instances running the affected range, especially multi-user deployments that share administrator-managed external connections. The issue is fixed in version 0.11.1; there is no public proof-of-concept, no known in-the-wild exploitation, and the flaw is not in CISA's KEV catalog.

Do: Upgrade Open WebUI to version 0.11.1 or later. As interim mitigation, limit write access on knowledge bases backed by administrator-managed external connections to administrators only, and review access logs for DELETE requests to /api/v1/knowledge/{id}/delete issued by non-admin accounts; if such requests occurred, verify that shared external connections and dependent knowledge bases are intact.

Open WebUI versions 0.9.6 through versions before 0.11.1 contain a time-of-check-to-time-of-use (TOCTOU) flaw in SafePlaywrightURLLoader (backend/open_webui/retrieval/web/utils.py): the backend validates a user-supplied hostname in Python, but the Playwright browser then resolves the same hostname again in its sync and async request interceptors, so the two lookups can return different addresses. An authenticated user who controls the authoritative DNS for a submitted hostname — via the web search or URL ingestion features — can answer the validation lookup with a public address while steering the browser to an internal address. This lets the attacker read responses from internal services or the instance's cloud metadata endpoint through the web UI, producing a high-confidentiality impact with no integrity or availability impact per the CVSS score. Any self-hosted Open WebUI deployment running an affected version is exposed where the attacker can obtain an account, since the flaw requires only low privileges and no user interaction. The issue is fixed in version 0.11.1; there is no public proof of concept, it is not in CISA KEV, and no exploitation is currently known.

Do: Upgrade to Open WebUI 0.11.1 or later. Until upgraded, restrict web search and URL ingestion to trusted accounts, disable open self-registration where not needed, and apply egress controls from the Playwright/browser environment (block internal address ranges and the cloud metadata endpoint, e.g. 169.254.169.254). Because exploitation depends on attacker-controlled DNS, instances that do not ingest untrusted URLs face little risk.

Open WebUI rendered terminal port content in an iframe sandbox that combined both allow-scripts and allow-same-origin, which provides no effective isolation because the terminal proxy serves that content from the Open WebUI origin itself. An authenticated user with access to a shared terminal server can host malicious script on a previewed port, and when another user opens that preview the script executes in the Open WebUI origin. The attacker's script can then hijack the victim's session and act on their behalf, yielding account takeover with high impact to confidentiality and integrity. All Open WebUI deployments running version 0.8.11 up to (but not including) 0.11.1 are affected, primarily multi-user instances where a terminal server is shared among users. No public proof of concept is known and the issue is not in CISA KEV, so there is no confirmed exploitation in the wild to date.

Do: Upgrade to Open WebUI 0.11.1 or later, which removes the sandbox misconfiguration in the port preview. Until patched, restrict access to the shared terminal server to trusted users, discourage or disable the terminal port-preview feature for untrusted users, or serve terminal proxy content from a separate origin. Verify your currently deployed version and audit which accounts have access to the shared terminal server.

Open WebUI versions 0.6.41 until 0.11.1 contain an authentication flaw in the user-lookup functions get_user_by_oauth_sub and get_user_by_scim_external_id (backend/open_webui/models/users.py): on SQLite, their JSON 'contains' matching compiles to SQL LIKE substring matching, leaving percent (%) and underscore (_) characters unescaped as LIKE wildcards. An OAuth subject or SCIM external ID containing these wildcard characters can therefore resolve to a different stored identity — potentially an administrator account — and the attacker is issued that account's session, effectively an authentication bypass that grants the privileges of the matched account. Exploitation requires unusual conditions (an attacker-controllable identity value with wildcard characters that collides with another account, e.g. an admin), reflected in the high attack complexity of the 8.1 High CVSS score. Only deployments using the SQLite backend with OAuth or SCIM login are affected; PostgreSQL deployments are not. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation exists as of this analysis.

Do: Upgrade to Open WebUI 0.11.1 or later, which escapes the wildcard matching. If immediate upgrade is not possible, either migrate the backend to PostgreSQL (not affected) or restrict/disable OAuth and SCIM logins, and check whether any user's OAuth sub or SCIM external ID contains '%' or '_' characters that could collide with other accounts — especially administrators. Review active sessions on privileged accounts for logins you cannot attribute.

Microsoft's winml-cli HTTP API component (serve/cli_api.py) exposes every CLI command over unauthenticated HTTP; although the server binds to 127.0.0.1 by default, it sets a wildcard allow_origins value, so any website the victim visits can silently issue cross-origin requests to the local endpoint from the browser. The build and config commands forward an unfiltered trust_remote_code value from the request JSON, causing AutoConfig.from_pretrained() to import and execute Python shipped in an attacker-chosen model repository, with the payload running at import time. An attacker who hosts a malicious model repository and lures the user of a running winml-cli server to an attacker-controlled page gains arbitrary code execution on that machine as the user running the server. Affected users are developers running the pip-distributed winml-cli HTTP API with default CORS settings; no specific affected or patched version ranges have been published in the available data. Exploitation has not been observed publicly: no public PoC is known, the CVE is not in CISA KEV, and EPSS assigns a low ~0.9% probability of exploitation within 30 days (59th percentile).

Do: Until Microsoft publishes a patched release (watch the MSRC advisory for CVE-2026-84452), avoid running the winml-cli HTTP API server while browsing untrusted sites, or restrict the wildcard allow_origins in serve/cli_api.py (duplicated in app.py) to trusted origins while keeping the loopback bind. Do not pass trust_remote_code=true to build/config for model repositories you do not control, since the unfiltered trust_remote_code flag is the RCE trigger; treat any externally referenced model repository as untrusted. Confirm whether your deployment runs the cli_api FastAPI/uvicorn service, as only those hosts are exposed to this attack.

HTTPX2 before 2.12.0 fully inflates each gzip, deflate, brotli, or zstd network chunk inside its content decoders (src/httpx2/httpx2/_decoders.py) before iter_bytes() or aiter_bytes() yields bounded pieces to the application, so a single 64 KiB compressed chunk can expand to roughly 64 MiB in one intermediate allocation. The flaw (CWE-409, improper handling of highly compressed data) is triggered whenever the client receives a crafted compressed response from a server the attacker controls or has compromised, even if the application streams the response. An attacker gains denial of service — severe memory pressure or out-of-memory termination of the Python process — with no confidentiality or integrity impact, consistent with the CVSS 7.5 availability-only score. All HTTPX2 deployments prior to 2.12.0 are affected; absolute exposure is unknown because no install or download counts are provided. No exploitation is known: there is no public proof-of-concept, the issue is not in CISA KEV, and EPSS estimates only a 0.4% chance of exploitation within 30 days.

Do: Upgrade to HTTPX2 2.12.0 or later, which bounds decoder allocations. Until upgraded, restrict requests to trusted servers, avoid fetching attacker-controlled or user-influenced URLs, cap response sizes where possible, and monitor client processes for memory spikes or OOM kills. Audit dependency manifests for httpx2 pinned below 2.12.0 and prioritize patching apps that fetch untrusted URLs.

HTTPX2 (via its httpcore2 transport) fails to start TLS for wss:// WebSocket connections tunneled through a SOCKS5 proxy, because the TLS upgrade condition in the SOCKS proxy handling only recognizes https and does not recognize wss. The flaw is reachable through Client.websocket() and AsyncClient.websocket() in HTTPX2/httpcore2 versions 2.6.0 through 2.9.1 when connecting to a wss origin via a SOCKS5 proxy. As a result, the opening handshake, query parameters, Authorization headers, cookies, and subsequent WebSocket frames cross the proxy path in plaintext without certificate verification, allowing an attacker controlling or observing that path to read or modify traffic and impersonate the WebSocket server. Any Python application using HTTPX2 for WebSocket connections over a SOCKS5 proxy is affected, while users who do not combine wss with a SOCKS5 proxy are not exposed. No public proof-of-concept or in-the-wild exploitation is known, EPSS is low (0.1% over 30 days), and the issue is not in CISA's KEV catalog.

Do: Upgrade to httpcore2 2.10.0 and HTTPX2 2.10.0 or later, which restore TLS negotiation for wss through SOCKS5 proxies. Until upgraded, avoid using Client.websocket()/AsyncClient.websocket() for wss:// origins reached via SOCKS5 proxies, or ensure sensitive material (Authorization headers, cookies, query parameters) is not sent over those connections. Audit applications and proxy configurations for WebSocket use over SOCKS5 to determine whether credentials or data traversed the proxy in plaintext.

Scrapy before 2.17.0 converts s3:// (S3-scheme) bucket/key requests into plaintext HTTP requests to the corresponding S3 endpoint unless request.meta["is_secure"] is explicitly enabled, then signs and sends them with the configured AWS credentials. The flaw is triggered whenever a crawl issues S3-scheme requests using AWS credentials over a network path that is not protected, because the request and response travel unencrypted. A passive network observer can read the bucket and key path, the AWS Authorization header, the X-Amz-Security-Token when temporary credentials are used, S3 object contents, and S3 response headers; an active man-in-the-middle can additionally modify the plaintext response body, status code, and headers, enabling scraped-data poisoning, poisoned exports, HTTP cache poisoning where caching is enabled, and influence over later crawl targets via forged redirects or attacker-controlled links. Only Scrapy users who make S3-scheme requests with AWS credentials are affected; ordinary HTTP/HTTPS crawls are not impacted. Exploitation is not currently known: there is no public proof-of-concept, the flaw is not in CISA KEV, and EPSS puts 30-day exploitation probability at about 0.2%.

Do: Upgrade to Scrapy 2.17.0, which fixes the issue. As interim mitigations, explicitly set request.meta["is_secure"] = True on S3-scheme requests, or avoid crawling s3:// URLs with AWS credentials over untrusted networks (e.g., use a VPN or private connectivity to S3). If a network observer or tamperer was plausible, consider flushing Scrapy's HTTP cache and reviewing recently scraped S3 data and exports for signs of modification.

BerriAI LiteLLM versions up to and including 1.82.4 contain a server-side template injection (SSTI) flaw in the /prompts/test endpoint of the LiteLLM proxy, caused by rendering user-supplied input with an unsandboxed jinja2.Environment. An unauthenticated remote attacker can trigger it by sending a crafted dotprompt_content parameter to that endpoint, which is evaluated as a Jinja2 template. Because the template environment is unsandboxed, evaluation escapes into the underlying system and lets the attacker execute arbitrary OS commands on the host running the proxy. Any deployment running LiteLLM 1.82.4 or earlier is affected, with highest risk on proxy instances reachable over the network without authentication; CVSS 9.8 reflects full server compromise with high confidentiality, integrity, and availability impact. Exploitation has not been observed: there is no public proof-of-concept, the flaw is not in CISA KEV, and EPSS assigns a 0.5% probability of exploitation within 30 days.

Do: Upgrade LiteLLM to a release newer than 1.82.4 as soon as a patched version is available, prioritizing any proxy instance reachable by unauthenticated users. As interim mitigation, restrict network access to the /prompts/test endpoint (or the whole proxy) and avoid passing untrusted dotprompt_content input. Check access logs for requests to /prompts/test containing dotprompt_content parameters and review hosts for signs of unexpected command execution.

NLTK (Natural Language Toolkit) contains a regular expression denial-of-service flaw (ReDoS, CWE-1333) in the nltk.text module: Text.findall() and TokenSearcher.findall() pass caller-supplied regular expressions to Python's re engine with no validation or timeout, after preprocessing that does not prevent catastrophic backtracking. When an application feeds an attacker-controlled pattern (for example, a nested-quantifier pattern that fails to match) into these methods against a crafted token string, re.findall can backtrack indefinitely and the call never returns. An unauthenticated attacker who can influence the regex or the searched tokens can saturate the CPU of the Python process with a single request, denying service to all other users of that process; confidentiality and integrity are unaffected. Affected parties are Python applications installed via pip that expose these nltk.text search functions to external input; NLTK is extremely widely installed, but only services that pass untrusted regular expressions to findall() are actually exploitable. The issue was resolved upstream in commit d8e4753 and no in-the-wild exploitation is known: it is not in CISA KEV, no public PoC is known, EPSS estimates roughly a 0.5% probability of exploitation within 30 days (40th percentile), and CVSS 4.0 scores it 8.7 High.

Do: Update NLTK to a release that includes fix commit d8e4753; the advisory does not name a version number, so verify the fix is present in your installed version rather than assuming any current release is safe. Until then, do not pass user-controlled regular expressions to Text.findall()/TokenSearcher.findall(); if unavoidable, validate and length-limit patterns (avoid nested quantifiers) and run matching under a timeout, for example in a worker thread with a deadline. Audit your codebase and dependencies for calls to these methods with external input to determine whether you are exposed at all.

NLTK, a widely used Python natural-language processing library, contains an unsafe deserialization flaw (CWE-502) in TransitionParser.parse(), which loads parser model files via pickle through an unrestricted unpickler. When an application calls parse() with a model file whose contents or location an attacker controls, embedded pickle gadget chains (e.g., os.system or subprocess.Popen) execute arbitrary Python code with the privileges of the process invoking NLTK. Although NLTK ships a RestrictedUnpickler designed for safe loading, no production call site - in transitionparser.py or the chart parser modules - passes restricted=True, so the flaw exists in all versions that include the TransitionParser module and is unpatched as of the available data. Researchers, students, data scientists, and automated ML pipelines that use NLTK transition-based dependency parsing with model files from untrusted sources are most at risk. No public proof of concept, CISA KEV listing, or in-the-wild exploitation is known, and EPSS puts the 30-day exploitation probability at about 0.3%.

Do: Until a patched release is announced, avoid loading TransitionParser (and chart parser) model files from untrusted or user-controlled sources, and audit code for calls to TransitionParser().parse() or the affected chartparser pickle_load call sites. Monitor the NLTK project for a release that enables restricted=True unpickling in production paths and upgrade promptly when available. As interim mitigation, run NLTK-dependent jobs under least-privilege accounts and restrict where model files can be written from.

GitPython before 3.1.59 contains an arbitrary file read vulnerability in TagReference.create() where a positional reference parameter bypasses the unsafe option guard. Attackers can supply a reference value like --file= to read arbitrary files, with contents returned in the annotated tag message.

GitPython's GitConfigParser contains a configuration-injection flaw (CWE-88/CWE-94) in its read-then-write round trip: multi-line values parsed from an on-disk config file using git's standard backslash-continuation syntax are decoded into Python strings with embedded newlines, and when the parser later rewrites the file, write_section() serializes them as a bare, unquoted newline-plus-tab continuation that real git parses as separate top-level config lines. The recently added UNSAFE_CONFIG_CHARS_RE safety guard only applies to values passed directly to set()/set_value()/add_value()/add_section(), never to values loaded from disk via _read(), so any unrelated write can turn a dormant value into a live directive such as core.hooksPath = <attacker-controlled path>. An attacker who can plant such a value in a config file that a GitPython-based application later rewrites gains arbitrary code execution, because git will execute the attacker's hook programs with the privileges of the user running GitPython. Developers, CI/CD systems, and pip-packaged tools that embed GitPython and rewrite git config files are affected, with GitPython 3.1.58 at HEAD confirmed vulnerable. No public PoC exists, it is not in CISA KEV, and EPSS assigns only a 0.4% probability of exploitation within 30 days, so no exploitation is currently known.

Do: Monitor GitPython for a patched release beyond 3.1.58/commit 9729ed3b (no fixed version is identified in the available data) and upgrade as soon as one is published. In the interim, avoid letting GitConfigParser rewrite config files that may contain multi-line (backslash-continuation) values, audit managed .git/config and related files for values with embedded newlines or unexpected trailing fragments like hooksPath, and restrict write access to those files to trusted principals.

CVE-2026-63312 is a security-control bypass in the NLTK Python library: when operators set nltk.pathsec.ENFORCE = True to sandbox all file access to approved NLTK data directories, StreamBackedCorpusView._open() still calls builtins.open() and os.stat() directly on string paths, skipping pathsec.validate_path() entirely. An attacker who can influence the fileid argument passed to StreamBackedCorpusView — for example via a web app, REST API, or multi-tenant NLP pipeline that accepts user-supplied corpus paths — can read arbitrary local files such as /etc/passwd, /proc/self/environ (potentially leaking secrets like AWS_SECRET_ACCESS_KEY or DATABASE_URL), or application configuration files, despite the sandbox being enabled. XMLCorpusView and any corpus reader subclass that passes a raw string fileid to StreamBackedCorpusView are affected in the same way. The flaw requires no privileges or user interaction over a network path (CVSS 4.0: 8.7 High). No exploitation in the wild has been reported and it is not in CISA KEV; no public PoC is catalogued, and EPSS estimates a 0.6% probability of exploitation within 30 days (45th percentile).

Do: Until a patched NLTK release is available, avoid passing user-controlled fileid strings to StreamBackedCorpusView or XMLCorpusView in ENFORCE-mode deployments, or pre-validate paths yourself (allow-list prefixes, reject absolute paths and traversal sequences) before invoking corpus readers. Treat pathsec.ENFORCE as bypassed: audit web/API handlers that feed user input into NLTK corpus readers and check for reads of /etc/passwd, /proc/self/environ, and config files in logs. When the upstream fix lands — routing StreamBackedCorpusView's builtins.open()/os.stat() calls through nltk.pathsec.open()/validate_path() — upgrade promptly and re-enable strict mode.

NLTK versions before 3.9.3 contain a download-integrity flaw (CWE-494) in its downloader module: files fetched via nltk.download() are extracted without any integrity or authenticity verification. An attacker positioned on the network path — through a man-in-the-middle attack or DNS poisoning — can substitute malicious package contents that NLTK then extracts onto the host unvalidated. Successful injection could place attacker-controlled files into the environment, with CVSS v4.0 scoring high impact to confidentiality, integrity, and availability of the target. Any developer, CI pipeline, or data-processing environment that installs NLTK via pip and uses its downloader to fetch packages over a network an attacker can influence is affected. No exploitation has been reported in the wild (EPSS ~0.1%, not in CISA KEV); the issue is documented in a published GitHub security advisory (GHSA-5wp5-5229-5g6q).

Do: Upgrade NLTK to 3.9.3 or later (pip install --upgrade nltk) and ensure CI images, requirements files, and containers are rebuilt against the fixed version. As interim mitigation, avoid running nltk.download() over untrusted or attacker-influenceable networks; instead pre-fetch packages from a trusted source and verify their integrity before extraction. Audit build and data pipelines for runtime calls to the NLTK downloader, since static installs that never download packages are not practically exposed.

Omnigent (a pip-distributed agent framework) does not validate the 'os_env.cwd' field of uploaded agent bundles, so a bundle author can set the agent's working directory to any host path, such as '/' or '/home/<victim>', with no normalization or boundary check anywhere in the spec pipeline. An authenticated, non-admin user can upload a session-scoped bundle with a malicious cwd; on runners deployed without the 'OMNIGENT_RUNNER_WORKSPACE' environment variable, the runner accepts the attacker-supplied path verbatim, making everything under that path in-bounds for the agent's file and shell tools. The attacker gains arbitrary read and write access to the runner host filesystem plus disclosure of host environment secrets; with 'fork=true' and a cwd set to another user's home directory, the runner copies that tree into the agent-readable workspace. Only Omnigent deployments whose runners realize session-scoped uploaded bundles without 'OMNIGENT_RUNNER_WORKSPACE' set are affected, and any authenticated user can trigger it — no admin scope, user interaction, or shared-agent overwrite is required. No public proof of concept is known, the issue is not in CISA KEV, and EPSS currently estimates a 0.4% probability of exploitation within 30 days; CVSS 3.1 scores it 8.8 (High).

Do: Set 'OMNIGENT_RUNNER_WORKSPACE' on every Omnigent runner — CLI- and host-launched sessions already set it, so audit any other launch paths — because it is the only control that overrides attacker-supplied cwd values. No fixed version is stated in the advisory; until a patched pip release ships, restrict agent-bundle uploads to trusted authenticated users and note that the shared-agent guard proposed for the related GHSA-jrrm-9hc7-2v3h advisory does not address this flaw. Once a fix is released, upgrade and re-verify that runner configurations still set the workspace variable so uploaded bundles no longer control the environment root.

CVE-2026-62676 is a fail-open policy bypass in the shared shell-command parser (policies/builtins/_shell.py) of the Omnigent AI agent harness (omnigent-ai/omnigent v0.1.0), which is supposed to enforce a GitHub repo/branch allowlist and working-directory confinement on agents such as Claude Code, Codex, and Pi. When a gated command contains anything the parser does not recognize — such as interpreter flags (bash -lc), unlisted wrappers (timeout, nice, setsid, stdbuf), command substitution (x=$(...)), or an un-split background operator (true & git push) — the parser emits no operation, the evaluator returns None (abstain), and abstention is treated as ALLOW, letting the command run unconfined. A misaligned or prompt-injected agent can then git push to an attacker-controlled repository or a protected branch (code/secret exfiltration) or escape its workspace via git worktree add or git -C. Only deployments relying on Omnigent's built-in shell, GitHub, and working-directory policies are affected; simple forms like a bare git push or env git push are correctly denied, confirming parser incompleteness rather than allowlist logic errors (CWE-184). No public proof-of-concept or in-the-wild exploitation is known, and EPSS assigns a 0.3% probability of exploitation within 30 days.

Do: Track the omnigent-ai/omnigent repository and upgrade to a patched release when one is published; the suggested fix is to make unrecognized gated commands DENY instead of returning None (fail closed), canonicalize known wrappers, and recurse into sh/bash -c payloads and command substitutions while splitting on shell control operators. Until patched, do not treat the GitHub repo/branch allowlist or working-directory confinement as the sole containment for untrusted or prompt-injected agents, and review agent-initiated git push, worktree add, and workspace-escape activity in logs.

CVE-2026-62675 is an authenticated remote-code-execution flaw (CWE-94) in the Omnigent server/runner: uploaded agent bundles may define server-side Python callable tools, and the bundle validator (validate_agent_bundle) does not reject `tools.<name>.callable` entries even though Python callable tools are intended as a trusted operator-only feature. An authenticated user triggers it by uploading a crafted bundle through the multipart `POST /v1/sessions` endpoint (the same path used by the Web UI's custom-agent flow, or directly via the API/CLI from agent YAML); when the uploaded agent's tool is invoked, the runner imports the attacker-specified dotted Python path (e.g., `subprocess.check_output`) via importlib and calls it, executing an arbitrary local command on the runner machine. A successful attacker gains code execution on the runner host with the runner's privileges, producing high confidentiality, integrity, and availability impact (CVSS 3.1: 8.8 High, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Affected are hosted or self-hosted Omnigent deployments that expose session creation to ordinary authenticated users, especially multi-tenant setups with shared or managed runner hosts. No public PoC, KEV listing, or confirmed in-the-wild exploitation is known; EPSS estimates roughly a 0.4% probability of exploitation within 30 days.

Do: Upgrade Omnigent (pip) to a release containing the bundle-validation fix as soon as one is published — no fixed version is stated in the available data, so track the omnigent-ai advisory/repository. Interim mitigations: restrict which authenticated users may upload custom agent bundles, disallow or allowlist `tools.<name>.callable` entries in uploaded bundles (including enforcing the policy-handler allowlist for callable tools), and run runners with least privilege on hosts where multi-user command execution is high impact. Prioritize deployments that expose `POST /v1/sessions` to ordinary users against shared or managed runner hosts, as these are the highest-risk configurations.

Omnigent's full agent bundle upload endpoint, PUT /sessions/{session_id}/agent, lets an authenticated user with edit access to their own session overwrite a shared/template agent, because the route checks only the session edit permission and omits the guard that blocks edits to shared/template agents (those with a null session_id). An attacker exploits this by uploading a replacement bundle that adds a stdio MCP server to the shared agent, even though such agents are exposed as not MCP-editable through the normal edit path. Because stdio MCP servers are launched as local subprocesses by runners, every future session created from the poisoned shared agent executes the attacker-controlled command, giving authenticated remote code execution on runner hosts (CWE-94, CVSS 3.1 score 9.0 Critical). Any Omnigent server deployment (pip-installable) serving multiple authenticated users that relies on shared/template agents is affected; the advisory does not specify affected version numbers. Exploitation is not currently known: there is no public proof of concept, EPSS is 0.3% (27th percentile), and the flaw is not in the CISA KEV catalog.

Do: Apply the advisory's suggested fix by adding the shared/template-agent guard (agent.session_id is null) to the PUT /sessions/{session_id}/agent route, and upgrade to a patched Omnigent release once the vendor publishes one. Until then, restrict the bundle upload endpoint to trusted users and audit existing shared/template agents for unexpected stdio MCP servers whose configured commands would execute on runner hosts.

CVE-2026-71428 is a server-side request forgery in the open-source `unstructured` Python document-partitioning library, where the `url=` parameter of `partition()`, `partition_html()`, and `partition_md()` is fetched with `requests.get()` without any private-IP, loopback, scheme, or redirect validation. An attacker who can control that URL — directly or through downstream ingestion layers such as LangChain's UnstructuredURLLoader, LlamaIndex's UnstructuredReader, or Chainlit — can point it at loopback admin APIs, internal HTTP services, or cloud metadata endpoints, and because the response body is returned as document Element text the SSRF is fully readable; redirect-following (on by default) and DNS rebinding provide bypass paths, and the markdown path also lacks a timeout, enabling slow-loris denial of service. An attacker gains the ability to read internal network responses, including secrets such as cloud credentials from metadata services (CVSS 3.1 9.3 Critical, scope-changed, C:H/I:L). Any deployment of the library from version 0.4.7 (Feb 2023) through the current release line (verified on 0.22.26 and still unfixed on main at commit 199f255) is affected — roughly 219 releases with no validation ever added — especially RAG and agent pipelines that ingest user-supplied URLs. There is no evidence of in-the-wild exploitation (EPSS ~0.3%, not in CISA KEV), and no public PoC is known beyond the reporter's local demonstration.

Do: No fixed release is identified in the available data; monitor the unstructured project and upgrade as soon as a patched version is published. Until then, avoid passing attacker-controlled URLs to partition()/partition_html()/partition_md(), restrict fetched URLs to an allowlist of public hosts (blocking private, loopback and link-local IP ranges, and re-resolving DNS at connect time to prevent rebinding), and consider allow_redirects=False to close the redirect bypass. Teams using LangChain's UnstructuredURLLoader, LlamaIndex's UnstructuredReader, or Chainlit should audit whether end users can control the fetched URL.

GitPython before 3.1.58 contains a flaw (CWE-88) in its check_unsafe_options guard, which is meant to block unsafe git options while allow_unsafe_options is set to its default value of False. The guard can be bypassed by combining a single-character keyword argument with split_single_char_options=False, causing GitPython to emit a joined token that git itself parses as an --upload-pack option. An attacker who can influence the kwargs passed to guarded methods such as clone_from can therefore inject --upload-pack and achieve arbitrary OS command execution, despite the library's default safe configuration. Any Python application, service, or pipeline built on the pip-installed GitPython library that passes attacker-controlled or remotely influenced arguments into its git wrapper methods is affected. A public proof-of-concept reference exists via the project's GitHub security advisory (GHSA-wvpp-8hx9-p66j); there is no evidence of in-the-wild exploitation yet, and EPSS puts 30-day exploitation probability at roughly 0.6%.

Do: Upgrade to GitPython 3.1.58 or later via pip as soon as possible. Audit application code paths where user or remote input flows into kwargs of guarded GitPython methods (e.g., clone_from), and avoid combining split_single_char_options=False with single-character keyword arguments until patched. No in-the-wild exploitation is confirmed, but given the public advisory, prioritize updates for internet-facing services that wrap git operations.