CVE-2026-32111: 
Python vulnerability analysis and mitigation

CVE-2026-32111 is a Server-Side Request Forgery (SSRF) vulnerability in ha-mcp, the Home Assistant MCP Server, affecting all versions prior to 7.0.0 (≤6.7.2). The flaw exists in the OAuth 2.1 DCR mode (beta feature), where the OAuth consent form accepts a user-supplied ha_url parameter and makes an unvalidated server-side HTTP request to {ha_url}/api/config, enabling unauthenticated internal network reconnaissance via an error oracle. Two additional code paths in OAuth tool calls (REST and WebSocket) are affected by the same primitive. The vulnerability was published on March 11, 2026, and carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Security Advisory).

The root cause is CWE-918 (Server-Side Request Forgery): the _validate_ha_credentials() function in provider.py performs a server-side GET request to {ha_url}/api/config with no scheme, IP, or domain validation on the attacker-controlled ha_url input. Three distinct code paths are affected: (1) the OAuth consent form validation, where different exception types (ConnectError, TimeoutException, HTTP 401/403/4xx) return distinct error messages that leak host/port reachability status; (2) REST tool calls, where OAuth access tokens are stateless, unsigned base64-encoded JSON payloads ({"ha_url": "...", "ha_token": "..."}), allowing token forgery to redirect HTTP requests to arbitrary hosts; and (3) WebSocket tool calls, where the same forged token triggers WebSocket connections to ws://{ha_url}/api/websocket. An attacker can fully automate exploitation by registering a client via open DCR (POST /register), initiating authorization, extracting a txn_id, and submitting arbitrary ha_url values — no user interaction is required (Security Advisory, GitHub Advisory).

An unauthenticated attacker can exploit this vulnerability to perform internal network reconnaissance from the server's network position, mapping reachable hosts and open ports by analyzing the distinct error responses returned by the server (error oracle). The confidentiality impact is limited — no direct data exfiltration is confirmed for non-HA targets, as REST path control is constrained to hardcoded HA API paths and WebSocket exploitation is limited to pivoting to other Home Assistant instances on the internal network. Integrity and availability are not impacted. The primary deployment method using a pre-configured HOMEASSISTANT_TOKEN is not affected; only deployments using the OAuth 2.1 DCR beta feature are at risk (Security Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.042% (13th percentile), indicating a low near-term exploitation probability. No threat actor attribution has been reported. Exploitation requires the target deployment to have the OAuth 2.1 DCR beta feature enabled, which is not the default configuration.

1. Identify target: Locate a publicly accessible ha-mcp instance running version ≤6.7.2 with the OAuth 2.1 DCR beta feature enabled (documented in docs/OAUTH.md).
2. Register OAuth client: Send a POST /register request to the open Dynamic Client Registration (DCR) endpoint to obtain a valid client ID and secret without authentication.
3. Initiate authorization flow: Begin the OAuth authorization flow using the registered client credentials to obtain a txn_id from the consent form endpoint.
4. Submit forged ha_url: Submit the OAuth consent form with an arbitrary ha_url value (e.g., http://192.168.1.1:8080) targeting an internal host/port to probe.
5. Analyze error oracle: Observe the distinct error message returned — "Could not connect..." (host down/port closed), "Connection timed out..." (host up, port filtered), "Invalid access token..." (service alive, HTTP 401), "Access forbidden..." (HTTP 403), or "Failed to connect: HTTP {N}" (service alive with exact status) — to determine host/port reachability.
6. Iterate reconnaissance: Repeat steps 4–5 with different internal IP addresses and ports to map the internal network topology.
7. Forge OAuth token (optional): Craft a base64-encoded JSON token {"ha_url": "<target>", "ha_token": "<any>"} and use it in REST or WebSocket tool calls to probe additional internal endpoints or pivot to other Home Assistant instances (Security Advisory).

• Network: Outbound HTTP/HTTPS requests from the ha-mcp server to unexpected internal IP ranges or non-standard ports; outbound WebSocket connections (ws://) to internal hosts not matching the configured Home Assistant URL.
• Logs: Server-side logs showing repeated OAuth consent form submissions with varying ha_url values, especially targeting RFC 1918 address ranges (10.x.x.x, 172.16.x.x, 192.168.x.x); error messages such as "Could not connect...", "Connection timed out...", or "Failed to connect: HTTP {N}" appearing in rapid succession from a single source IP.
• Application: Multiple POST /register requests to the DCR endpoint from the same IP in a short timeframe; OAuth authorization flows initiated but not completed (abandoned after txn_id extraction); OAuth access tokens with ha_url values pointing to internal infrastructure rather than the configured Home Assistant instance (Security Advisory).

Upgrade ha-mcp to version 7.0.0 or later, which fixes the vulnerability by adding URL validation to the OAuth consent form and related code paths (GitHub Advisory). If immediate patching is not possible, disable or restrict access to the OAuth 2.1 DCR beta feature. Implement network-level egress controls to restrict which URLs the ha-mcp server can reach, and monitor server logs for suspicious ha_url patterns. Deployments using the standard method (private URL with pre-configured HOMEASSISTANT_TOKEN) are not affected and do not require immediate action.

The vulnerability was reported by security researcher yotampe-pluto and remediated by maintainer julienld, who published the advisory on March 11, 2026 (Security Advisory). Coverage has been limited to automated vulnerability tracking platforms and threat intelligence aggregators, with no significant broader community or media discussion identified.