Vulnerabilities

The Python/Django live-view library djust (CVE-2026-61594) fails to enforce standard Django authorization on its WebSocket (live) transport: views are mounted via check_view_auth instead of Django's View.dispatch() chain, so protections such as LoginRequiredMixin, PermissionRequiredMixin, UserPassesTestMixin, login_required decorators, custom dispatch() guards, and the djust admin staff gate apply only to the initial HTTP GET and are silently bypassed over WebSocket. Any anonymous or under-privileged client can open a WebSocket connection and mount such a view, causing its handlers to run. Because all events and state flow over WebSocket, an attacker can reach full read and write handlers — including the djust admin extension's list/create/change/delete operations — yielding high confidentiality and integrity impact (CVSS 3.1: 9.1 critical). All djust deployments that protect WebSocket-mounted views or admin routes with Django mixins, decorators, or overridden dispatch() are affected. No public proof-of-concept is known, the issue is not in CISA KEV, and there are no reports of exploitation in the wild.

Do: Upgrade to djust 1.0.7 or later, where check_view_auth honors the Django AccessMixin family on every transport, system check S004 flags unsafe auth patterns at startup, and the admin mixin enforces login plus active-staff permissions. As an interim workaround, gate WebSocket-mounted views using djust's own login_required, permission_required, or check_permissions attributes instead of HTTP-only Django mixins or decorators. Audit all WebSocket-mounted views (especially admin routes) and review access logs for anonymous WebSocket connections that mounted privileged views.

vLLM is an inference and serving engine for large language models. Prior to 0.24.0, the input_audio handling path for /v1/chat/completions calls AudioMediaIO.load_bytes or AudioMediaIO.load_file without passing VLLM_MAX_AUDIO_DECODE_DURATION_S to the shared audio decoder. An unauthenticated client can therefore submit a small compressed audio input that expands into a very large float32 PCM allocation, bypassing the duration guard already used by /v1/audio/transcriptions and causing an out-of-memory worker crash. Inline data URLs reach this path without being bounded by VLLM_AUDIO_FETCH_TIMEOUT. The issue affects deployments serving an audio-capable model, and authentication changes only the deployment-specific reachability. This issue is fixed in version 0.24.0.

LMdeploy's AsyncRPCServer (zmq_rpc.py) passes incoming RPC messages directly to pickle.loads() without any sanitization (CWE-502), so anyone who can send a request to the server's TCP endpoint can have it deserialize attacker-controlled pickle data. Because pickle deserialization can instantiate arbitrary objects, an attacker reaching the RPC port gains arbitrary code execution on the host; the researcher demonstrated a full reverse shell from a crafted request. The server performs no validation of the connecting IP, and although its port is randomized, an attacker can find it by port scanning, so any network-reachable deployment is at risk. Affected users are operators running lmdeploy's RPC server component (typically in distributed/multi-node LLM inference setups), especially where the service is reachable beyond localhost or from untrusted networks. No exploitation in the wild is known and the flaw is not in CISA KEV, though the advisory includes working reproduction steps, and the flaw carries a CVSS 3.1 score of 9.8 (critical).

Do: No patched version is identified in the advisory, so monitor the lmdeploy repository/PyPI for a fix and upgrade as soon as one is released; the maintainer-suggested mitigations are replacing pickle with a safer serializer (e.g., msgpack or safetensors) or restricting deserialization via an Unpickler.find_class allowlist, plus enabling RPC authentication. In the meantime, bind the RPC server to localhost or a trusted, firewalled cluster network only, and audit hosts for lmdeploy RPC processes listening on non-local ports.

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

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.