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.