Vulnerabilities

GitHacker is a tool that restores Git repositories from exposed .git directories. In 1.1.7 and earlier, add_head_file_tasks parses an attacker-controlled ref path from .git/HEAD and joins unvalidated path segments onto temp_dst/.git/logs/, allowing a malicious server to make GitHacker read an arbitrary local file when a victim runs the tool against the server's URL. add_hashes_parsed then scans the file for 40-character hexadecimal substrings and requests each match through .git/objects using the first two characters and remaining characters as path components, creating an attacker-observable existence oracle and disclosing matching hexadecimal fragments. Complete file contents are not returned, and the add_folder and add_task write path in shipped version 1.1.7 does not permit an escape. This issue is fixed in repository version 1.1.9.

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.

WeasyPrint helps web developers to create PDF documents. Prior to 70.0, server-side applications that configure a restrictive url_fetcher and pass attacker-influenced values to HTML.write_pdf() can have the restriction bypassed through the xmp_metadata or stylesheets options. In weasyprint/pdf/init.py, xmp_metadata calls select_source() without the document url_fetcher, allowing an accessible local file to be read and embedded verbatim in the output PDF. In weasyprint/document.py, stylesheets constructs CSS() without the document url_fetcher, allowing local or internal resource loading and propagating the permissive fetcher through nested CSS imports and url() references. The stylesheets channel applies fetched resources but does not by itself disclose stylesheet comments verbatim. This issue is fixed in version 70.0.

SQLAdmin is a flexible Admin interface for SQLAlchemy models. Prior to 0.27.1, ModelView.sort_query in sqladmin/models.py accepts the attacker-controlled sortBy list-view query parameter without enforcing the configured column_sortable_list server-side allow-list in self._sort_fields. The value is resolved with getattr and passed to relationship joins and order_by, allowing requests to sort by columns hidden from column_list and by related-model columns through dotted paths. The resulting row order forms an information-exposure oracle for unexposed values, and reversing ascending and descending order confirms their relative ordering. Pairing sortBy with searchable or filterable columns and pagination can narrow the oracle toward specific values, but exact recovery depends on the application's available fields and data. This issue is fixed in version 0.27.1.

psd-tools is a Python package for working with Adobe Photoshop PSD files. Prior to version 1.17.1, `SmartObject.save()` writes an embedded smart object to a path taken verbatim from the PSD file. Because that name is attacker-controlled and unsanitised, a tool that extracts embedded objects from an untrusted `.psd` can be made to write attacker-chosen bytes to an attacker-chosen path (absolute or `../`-traversing), outside its intended output directory. A secondary issue in `SmartObject.open()` for external-kind smart objects allows the attacker-controlled `fullPath` descriptor to be used as an arbitrary file read path, enabling exfiltration of the read content to the controlled write destination. Both issues are fixed in v1.17.1.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.8.0 until 0.11.1, Open WebUI's OAuth token exchange endpoint issues a session for a provider access token without running the OAuth role management that the normal OAuth login callback runs. A user whose provider roles the login callback would refuse, or would demote, could still obtain a working session at their existing role through this endpoint. This issue is fixed in version 0.11.1.

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.

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.

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 is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.10.0 until 0.11.1, POST /api/chat/completions and POST /api/v1/chat/completions in backend/open_webui/main.py copied a client-supplied folder_id into a new chat without applying the folder write-access check used by the dedicated chat routes. An authenticated user who knew a shared folder identifier could inject an attacker-controlled chat into a folder where the user had read-only or no write access, causing the entry to appear to authorized folder readers. This issue is fixed in version 0.11.1.

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 is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.5 until 0.11.1, the channel branch of chat_completion in backend/open_webui/main.py checked channel write access and channel membership for a supplied message_id but did not verify that the calling user authored the targeted message. A channel member could use the chat completions endpoint to replace another member's message while preserving the victim as the stored author, altering the conversation record without gaining access to other channels. This issue is fixed in version 0.11.1.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.7.0 until 0.11.1, the built-in knowledge search tool passed the caller's readable knowledge identifiers through a metadata filter, but the search methods in eleven shipped vector backends ignored that filter. An authenticated user on an affected backend could enumerate the identifiers, names, and descriptions of inaccessible knowledge bases from the shared collection, although the associated document text remained in separate collections. This issue is fixed in version 0.11.1.

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.

HTTPX2 is a next generation HTTP client for Python. Prior to 2.11.0, Request._prepare() in src/httpx2/httpx2/_models.py can add a body-derived Content-Length header to a request that already contains a caller-supplied Transfer-Encoding header because its setdefault() processing checks each default header independently rather than treating the two framing headers as mutually exclusive. Fixed-size byte, JSON, form, and known-length multipart bodies can therefore be serialized over HTTP/1.1 with both headers, allowing request smuggling or connection desynchronization when downstream intermediaries disagree about which framing header takes precedence. This issue is fixed in version 2.11.0.

HTTPX2 is a next generation HTTP client for Python. Prior to 2.11.0, FileField.render_headers() in src/httpx2/httpx2/_multipart.py directly interpolates attacker-controlled content_type values and custom headers from the files= three-element (filename, content, content_type) tuple and the files= four-element (filename, content, content_type, headers) tuple into multipart/form-data part headers without validating header names or values. CR or LF characters can terminate a part header, inject additional part headers, or end the part header block early, allowing a downstream multipart parser to treat attacker-supplied lines as genuine headers and potentially alter part semantics or bypass header-based checks. This issue is fixed in version 2.11.0.

HTTPX2 is a next generation HTTP client for Python. From 2.5.0 until 2.10.0, the HTTPX2 Server-Sent Events parser in src/httpx2/httpx2/_sse.py repeatedly copies and rescans buffered text in _SSELineDecoder.decode() when an attacker-controlled or compromised SSE endpoint splits one unterminated line across many response chunks. The behavior affects httpx2.Client.sse() and httpx2.AsyncClient.sse(), and the total processing work grows quadratically with the line length, allowing a crafted stream to consume excessive CPU and block a synchronous worker or asynchronous event loop. This issue is fixed in version 2.10.0.

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