Vulnerabilities

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.

NLTK before 3.10.3 contains a regular expression denial-of-service (ReDoS) vulnerability in the Pl196xCorpusReader, where lazy regex patterns in the read_block method cause quadratic CPU consumption when parsing malformed TEI blocks containing many unmatched opening tags. An attacker triggers the flaw by supplying attacker-controlled or untrusted corpus content that an application parses through public APIs such as words() or tagged_words(), forcing repeated rescans and near-quadratic runtime growth with input size. The attacker gains degradation of service — CPU exhaustion on the parsing process — with a low availability impact and no confidentiality or integrity impact, consistent with the CVSS 4.0 medium score of 6.3. Any Python application, notebook, or service running NLTK below 3.10.3 that parses untrusted TEI/corpus data through the affected reader is affected. There are no confirmed reports of in-the-wild exploitation: the flaw is not in CISA KEV, EPSS estimates only a 0.2% probability of exploitation within 30 days, and the sole public reference is the NLTK GitHub security advisory (GHSA-8mpw-7fpc-4gqj) with a proof of concept.

Do: Upgrade NLTK to version 3.10.3 or later via pip. If upgrading is not immediately possible, avoid parsing untrusted or user-supplied TEI/corpus files with words(), tagged_words(), or other Pl196xCorpusReader APIs, or restrict and validate the size and structure of inputs. Audit dependency pins and environment lockfiles for nltk versions below 3.10.3, since the library is commonly pulled in transitively by NLP pipelines.

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'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.

ONNX before 1.21.0 contains a symlink-following and time-of-check-to-time-of-use flaw in its save_external_data function, which builds the external-data output 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 a model's external data can pre-plant a symlink at the expected path, causing the victim's write to follow it. As a result, the attacker can append attacker-influenced content to any file the victim can write, such as ~/.ssh/authorized_keys, cron files, or application configs, potentially achieving code execution or persistence in the victim's user context. Any Python environment running a vulnerable onnx version and saving models with external data, particularly on shared or multi-user systems, is affected. No exploitation is known in the wild; one public advisory/PoC reference exists and EPSS is 0.1% (1st percentile).

Do: Upgrade the onnx pip package to 1.21.0 or later. As an interim mitigation, serialize model external data only into directories exclusively writable by the running user, and audit services, cron jobs, and pipelines on shared or multi-user hosts that call save_external_data for vulnerable usage.

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.