CVE-2026-91130: DOM-Based Cross-Site Scripting in Home Assistant Statistics Graph Card

The Home Assistant web-based user interface relies on several custom UI cards to display real-time sensor metrics and state changes. Within this interface, the Statistics Graph card allows users to visualize historical data such as temperature, power consumption, and device metrics using the third-party Apache ECharts visualization library.\n\nBecause the Home Assistant backend utilizes a dynamic state machine, the names and friendly labels of individual entities are passed directly from backend components to the frontend visualization cards. This establishes a communication channel between backend databases, user inputs, external integration components, and the administrative dashboard.\n\nPrior to the release of version 2026.7.0, the Statistics Graph card rendered tooltips using raw string values without sanitizing individual metadata fields. This structural oversight created a DOM-based Cross-Site Scripting vulnerability, where unauthenticated or low-privileged actors can execute malicious client-side code inside the security context of other users.

The technical root cause of CVE-2026-91130 lies in the custom tooltip formatter callback assigned to the Apache ECharts instance within src/components/chart/statistics-chart.ts. The formatter function was programmed to return a raw string containing HTML markup that represented the data point series name and value.\n\nWhen ECharts processes a custom formatter that returns a raw string, it writes the string directly to the DOM using a sink that evaluates HTML markup. Since the formatter used a template literal to interpolate the param.seriesName parameter, any HTML sequence embedded in the entity friendly name is directly executed by the browser rendering engine.\n\nThis behavior bypasses standard frontend input filters because the entity name is retrieved directly from the state history store. The state history data is populated by backend processes, which trust state modifications submitted via local integrations, external API requests, or user customization utilities.

The vulnerable implementation in the frontend codebase relied on string interpolation to build the HTML string structure that was returned to the charting component.\n\ntypescript\n// Vulnerable string-based tooltip formatter\nconst rawTime = formatDateTimeWithSeconds(startTime, this.hass.locale, this.hass.config);\nconst time = index === 0 ? rawTime : \"\";\nreturn `${time}${param.marker} ${param.seriesName}: ${value}`;\n\n\nThe patched version replaces the raw string interpolation logic entirely by transitioning the tooltip formatting pipeline to use Lit templates, ensuring that variables are automatically escaped.\n\ntypescript\n// Secure Lit-based tooltip formatting implementation\nreturn html`${rows.map(\n (row, i) =>\n html`${row.time\n ? html`${row.time}<br />`\n : nothing}<ha-chart-tooltip-marker\n .color=${row.color}\n ></ha-chart-tooltip-marker>\n ${row.seriesName}:\n ${row.value}${i < rows.length - 1 ? html`<br />` : nothing}`\n)}`;\n\n\nBy passing a custom Web Component <ha-chart-tooltip-marker> and evaluating structural variables through Lit templates, the application enforces compile-time sanitization. The row.seriesName variable is handled strictly as text, rendering any embedded HTML entities harmlessly without script evaluation.

To exploit this vulnerability, an attacker requires low-privileged administrative access or control over a connected device integration to update an entity's metadata attributes. This is commonly achieved by submitting a state change to the Home Assistant REST API or modifying the core registry files.\n\nbash\ncurl -X POST \\\n -H \"Authorization: Bearer <Attacker_Token>\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"state\": \"22.5\", \"attributes\": {\"friendly_name\": \"<img src=x onerror=alert(document.domain)>\", \"state_class\": \"measurement\"}}' \\\n http://homeassistant.local:8123/api/states/sensor.vulnerable_sensor\n\n\nmermaid\ngraph LR\n A[\"Attacker Payload\"] --> B[\"API / State Registry\"]\n B --> C[\"ECharts Tooltip Component\"]\n C --> D[\"Victim Browser DOM\"]\n\n\nOnce the payload is successfully injected into the entity registry database, the attacker waits for an administrative viewer to inspect the Lovelace dashboard containing a Statistics Graph card tracking the affected entity. The moment the administrator hovers over a data point, ECharts executes the callback formatter, inserts the payload into the browser DOM, and executes the script context.

A successful exploitation of CVE-2026-91130 leads to a complete compromise of the victim's frontend browser session. Because Home Assistant utilizes active session cookies and local storage tokens to maintain administrative access, the executed payload has complete read and write authority under the administrator's profile.\n\nAn attacker can construct client-side scripts to steal the long-lived access tokens stored in browser LocalStorage. These stolen tokens allow the attacker to issue API commands remotely, control physical smart home locks, disable cameras, modify alarm configurations, or trigger internal automation events.\n\nIn environments where shell commands or command-line integrations are enabled, administrative access can be leveraged to execute shell tools. This elevates the local client-side vulnerability to remote command execution on the host operating system running the Home Assistant Core container.

Remediation requires upgrading the Home Assistant Core installation to version 2026.7.0 or higher. This upgrade replaces the vulnerable frontend component code with the secure Lit-based rendering template library.\n\nIf an immediate upgrade is not feasible, administrators should restrict dashboard configuration permissions to trusted roles and limit the use of custom integrations. Additionally, the existing configuration files and integration state database should be audited regularly to ensure no raw HTML payloads are embedded within entity friendly names.\n\nTo identify potential active payload indicators within the local state database, administrators can run the following SQL command against the SQLite state file.\n\nsql\nSELECT entity_id, attributes FROM states \nWHERE attributes LIKE '%<script%' \n OR attributes LIKE '%onerror%' \n OR attributes LIKE '%onload%';\n