A high-severity vulnerability in the ha-mcp Home Assistant MCP Server (CVE-2026-32112) demonstrates how OAuth consent flows—trusted entry points in AI agent infrastructure—can become delivery mechanisms for arbitrary JavaScript execution in an operator's browser. Prior to version 7.0.0, the ha-mcp OAuth consent form failed to sanitize rendered content, allowing an attacker to inject malicious scripts that execute with the privileges of the authenticated Home Assistant session. For AI agent developers and operators, this is a sharp reminder that the trust boundaries we assume around authentication flows are only as strong as their weakest rendering layer.
How the Attack Works
The vulnerability centers on the OAuth consent form presented when an MCP server requests authorization to access Home Assistant resources. During a standard OAuth flow, the user is redirected to a consent screen that displays the requesting application's name, scope of access, and a confirmation prompt. In ha-mcp versions before 7.0.0, this form rendered user-influenced or attacker-controlled data without sufficient output encoding, creating a stored cross-site scripting (XSS) vector.
An attacker with the ability to influence the OAuth client metadata—such as the application name or description field—could embed a JavaScript payload. When the operator visits the consent form to authorize the MCP server, the payload executes in the context of their authenticated Home Assistant session. This grants the attacker access to session tokens, the ability to issue API requests on behalf of the user, and potentially full control over the Home Assistant instance.
The MCP server pattern compounds this risk. MCP servers like ha-mcp register capabilities via registerTools(server), registerResources(server), and registerPrompts(server) functions, and they rely on transport layers like stdio or Streamable HTTP to communicate with AI agents. When an MCP server is compromised or maliciously configured, the OAuth consent form becomes a bridge between the AI agent's tool ecosystem and the operator's browser—exactly the boundary this vulnerability collapses.
Real-World Implications for AI Agent Deployments
AI agent operators routinely grant OAuth permissions to MCP servers without scrutinizing every consent form field. The architecture of MCP encourages this: servers are modular, often community-maintained, and integrated into agent workflows where tools are invoked automatically based on LLM reasoning. An operator might authorize ha-mcp to control lights, locks, or sensors, never suspecting that the consent screen itself is hostile.
The practical impact extends beyond Home Assistant. Any MCP server that implements OAuth and renders external metadata in a consent form without rigorous sanitization is potentially vulnerable to the same pattern. For operators running multiple MCP servers—common in multi-modal agent setups—this creates a cascading trust problem. A single compromised or malicious server can harvest credentials, pivot to other systems, or manipulate smart home devices in real time.
From a threat modeling perspective, this vulnerability sits at the intersection of supply chain risk and user interface trust. The MCP server's code is part of the supply chain; the consent form is a user-facing trust decision. When both fail simultaneously, the operator has no visible signal that anything is wrong until after exploitation.
Detection and Defensive Measures
Detecting OAuth consent form XSS requires a combination of code review, runtime monitoring, and architectural hardening. Operators should inspect MCP server dependencies for known vulnerabilities using sources like the NVD CVE database. The original research for CVE-2026-32112 is available at https://nvd.nist.gov/vuln/detail/CVE-2026-32112 and should be tracked for patches and indicators of compromise.
At the code level, any OAuth consent form should treat all rendered fields as untrusted input. Here is a defensive pattern for sanitizing OAuth client metadata before rendering:
import html
from markupsafe import Markup
def render_consent_form(client_name, client_description, scopes):
# Strictly escape all user-influenced fields
safe_name = html.escape(client_name)
safe_description = html.escape(client_description)
# Use a allowlist for scope descriptions, never render raw scope strings
scope_descriptions = {
"homeassistant:read": "Read Home Assistant states and entities",
"homeassistant:write": "Control devices and update states",
}
rendered_scopes = []
for scope in scopes:
desc = scope_descriptions.get(scope, "Unknown scope—deny this request")
rendered_scopes.append(html.escape(desc))
return Markup(f"""
<h1>Authorize {safe_name}</h1>
<p>{safe_description}</p>
<ul>{''.join(f'<li>{s}</li>' for s in rendered_scopes)}</ul>
""")
Key defensive principles in this pattern: all external strings are HTML-escaped before rendering, scope descriptions are mapped through an allowlist rather than displayed raw, and the template itself uses safe construction to prevent injection. Operators should verify that their MCP servers apply equivalent rigor.
Immediate Actions for AI Agent Operators
If you operate an AI agent with Home Assistant integration, prioritize the following steps:
- Upgrade ha-mcp to 7.0.0 or later immediately. This is the patched version that resolves CVE-2026-32112.
- Audit all authorized OAuth applications in your Home Assistant instance. Revoke any sessions or tokens associated with ha-mcp versions prior to 7.0.0.
- Review other MCP servers in your stack for similar OAuth flows. Check whether they render external metadata without sanitization.
- Enable Content Security Policy (CSP) headers on any web interface that hosts or proxies MCP server consent forms. A strict CSP can block inline script execution even if an XSS payload is injected.
- Monitor Home Assistant logs for anomalous API calls or device state changes that occur outside expected agent workflows.
For developers building MCP servers, follow the security best practices in the MCP project pull request template: ensure MCP documentation is read, security guidelines are applied, and all changes are tested with an LLM client before release. The readOnlyHint, idempotentHint, and destructiveHint tool annotations exist partly to help operators understand risk—use them, and extend that transparency to OAuth flows as well.
Key Takeaways
CVE-2026-32112 is not an abstract browser vulnerability. It is a concrete example of how AI agent infrastructure—specifically the MCP server ecosystem—can inherit and amplify traditional web security flaws. The OAuth consent form is a critical trust boundary. When it fails, the attacker does not need to compromise the LLM, the agent logic, or the Home Assistant API directly; they only need to trick the operator into authorizing a single malicious request.
Treat every MCP server's OAuth surface as a potential XSS vector. Sanitize all rendered fields, validate client metadata at registration time, and maintain strict version hygiene. The convenience of modular AI agent tools must not come at the cost of operator browser security.
