Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
An authenticated party can add a malicious name to any statistics-capable entity, allowing for Cross-Site Scripting attacks against anyone who views a Statistics Graph card containing that entity, when they hover over any data point on the chart. Payload <img width="1529" height="441" alt="image" src="https://github.com/user-attachments/assets/6926ce53-75fb-455a-bd4e-0c5281e8bed8" / Payload triggering <img width="835" height="469" alt="image" src="https://github.com/user-attachments/assets/0bb9d17a-c123-4d44-8471-35097f65ddd2" / An alternative, and more impactful scenario, is that the entity gets a malicious name from the provider of the integration (e.g. Tibber, Shelly, or any HACS integration), and is exploited that way through the default name — without requiring any direct access to the Home Assistant instance. This is the same supply-chain vector as CVE-2025-62172. Details The Statistics Graph card renders entity names in ECharts tooltips as raw HTML. The offending line…
Recommended action: Upgrade to 2026.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Home Assistant Core before 2026.6.0 contains a path traversal vulnerability that allows unauthenticated attackers to write arbitrary files to any directory on the host filesystem by uploading a crafted backup archive during the initial onboarding window. Attackers can manipulate the 'name' field inside the uploaded archive's backup.json to supply an absolute path, causing pathlib.Path.truediv to discard the configured backup directory prefix and write attacker-controlled content to arbitrary locations, with full filesystem access when the process runs as root.
Recommended action: Upgrade to 2026.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2026.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2026.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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"…
Recommended action: Upgrade to 2026.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2025.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authenticated party can add a malicious name to the Energy entity, allowing for Cross-Site Scripting attacks against anyone who can see the Energy dashboard, when they hover over any information point (The blue bar in the picture below) <img width="955" height="568" alt="1cens" src="https://github.com/user-attachments/assets/ed855216-c306-4b50-affc-cda100e72b74" / An alternative, and more impactful scenario, is that the entity gets a malicious name from the provider of the Entity (in this case the energy provider: Tibber), and gets exploited that way, through the default name. Details The incriminating entity in my scenario is from the Tibber integration, as shown in the screenshot below: <img width="822" height="309" alt="2cens" src="https://github.com/user-attachments/assets/d0d5a7aa-8d0c-4dcb-825b-e4cb8ea8885b" / The exploit should be possible regardless of the Energy integration, as the user can name the entity themselves and as such pick a malicious name. The default…
Recommended action: Upgrade to 2025.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Problem: Potential man-in-the-middle attacks due to missing SSL certificate verification in the project codebase and used third-party libraries. Details In the past, aiohttp-session/request had the parameter verifyssl to control SSL certificate verification. This was a boolean value. In aiohttp 3.0, this parameter was deprecated in favor of the ssl parameter. Only when ssl is set to None or provided with a correct configured SSL context the standard SSL certificate verification will happen. When migrating integrations in Home Assistant and libraries used by Home Assistant, in some cases the verifyssl parameter value was just moved to the new ssl parameter. This resulted in these integrations and 3rd party libraries using request.ssl = True, which unintentionally turned off SSL certificate verification and opened up a man-in-the-middle attack vector. Example:…
Recommended action: Upgrade to 2024.1.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2023.12.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2023.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.67.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.