Vulnerabilities

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.

CVE-2026-62384 is a new, distinct symlink-based bypass of the path-security sandbox in NLTK's FramenetCorpusReader, defeating the fix released in PR #3581 for the earlier FrameNet path-traversal issue CVE-2026-54292 (GHSA-xh95-f55m-82fw). The guard added by that fix, _reject_unsafe_path_component(), only blocks literal path separators, '..' and Windows drive prefixes and never resolves symlinks, and the affected call sites (frame_by_name(), _lu_file() and doc() in nltk/corpus/reader/framenet.py) then perform a lexical abspath() join and open the result via PathPointer.open() with no required_root check, so a separator-free symlink planted inside a FrameNet corpus subdirectory (e.g. frame/) is followed to any file outside the corpus root. An attacker who can plant a symlink in a corpus directory that the application then reads gains disclosure of the contents of XML files located outside the corpus root, since the file is parsed through XMLCorpusView and its parsed fields (such as the frame definition) are returned to the caller; CVSS 4.0 rates this 8.7 High with a network vector and confidentiality-only impact. Anyone running an unpatched nltk installation from the pip ecosystem whose code loads FrameNet data from a directory an attacker can influence is affected, while deployments that only load trusted, locally controlled NLTK data face little risk. No in-the-wild exploitation is known, the flaw is not in CISA KEV, EPSS gives roughly 0.6% odds of exploitation within 30 days (45th percentile), and a self-contained runnable proof of concept is included in the advisory.

Do: If your applications use FramenetCorpusReader (frame_by_name(), _lu_file(), or doc()), upgrade nltk to the patched release for CVE-2026-62384 once published, since no fixed version number is stated in the available data. Until then, keep FrameNet corpus directories (frame/ and the LU and fulltext subdirectories) writable only by trusted principals, audit them for symlinks pointing outside the corpus root, and treat user-supplied corpus archives as untrusted.

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.

In ONNX before 1.21.0, the 'save_external_data' function builds the external-data file path from the model's external_data location field and opens it for writing without 'O_NOFOLLOW/O_EXCL', after a non-atomic 'os.path.isfile()' check. A local attacker with write access to the directory where a victim serializes external data can deterministically pre-plant a symlink that is being followed, causing the victim's write to append to any file the victim can write, e.g. ~/.ssh/authorized_keys, cron files, or application configs. Fixed in 1.21.0.

django CMS is an easy-to-use and developer-friendly enterprise content management system powered by Django. Prior to 5.0.9, render_object_structure fails to authorize non-PageContent objects that use PlaceholderRelationField. An active staff user without cms.use_structure or model-level view or change permission can request the //admin/cms/placeholder/object/ /structure/ / endpoint with guessed content_type_id and object_id values. The response discloses placeholder slot names, plugin trees, plugin identifiers, labels, and object existence for frontend-editable objects. The fix applies user_can_view_placeholder_source to the non-PageContent branch while keeping the structure board read-only for view-only users. This issue is fixed in versions 5.0.9.

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.

vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the MiMoV2OmniMultiModalProcessor in vllm/transformers_utils/processors/mimo_v2_omni.py passes attacker-controlled image and audio strings through _fetch_image, requests.get, and Image.open instead of MediaConnector, bypassing allowed_media_domains and allowed_local_media_path protections and allowing server-side requests and reads of arbitrary files accessible to the vLLM process. This issue is fixed in version 0.26.0.

vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the /v1/completions/derender and /v1/chat/completions/derender endpoints accept caller-supplied GenerateResponse objects whose generate_responses, choices, token_ids, prompt_logprobs, logprobs.content, top_logprobs, and routed_experts structures are processed by OnlineDerenderer and tokenizer.decode before max_model_len, max_tokens, max_num_seqs, or response-size limits are enforced, allowing an authenticated API client to consume excessive CPU and memory and produce oversized responses. This issue is fixed in version 0.26.0.