Home Assistant is open source home automation software that puts local control and privacy first. Home Assistant apps (formerly add-ons) configured with host network mode expose unauthenticated endpoints bound to the internal Docker bridge interface to the local network. On Linux, this configuration does not restrict access to the app as intended, allowing any device on the same network to reach these endpoints without authentication. Home Assistant Supervisor 2026.03.02 addresses the issue.

Home Assistant Core before 2026.7.0 contains a path traversal vulnerability in the backup-restore function that allows attackers to write files to arbitrary absolute filesystem paths by supplying a crafted tar archive with a SYMTYPE entry containing a benign member name paired with an absolute linkname pointing outside the extraction directory. Because the official Docker image runs the Home Assistant process as root and the subsequent regular-file entry is written through the unvalidated symlink, attackers can achieve remote code execution by overwriting auto-imported Python paths such as site-packages/sitecustomize.py or custom component directories.

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.

Home Assistant Community Store (HACS) prior to 1.10.0 contains a path traversal vulnerability that allows unauthenticated attackers to read sensitive files by traversing directories via the /hacsfiles/ endpoint. Attackers can retrieve the .storage/auth file containing user credentials and refresh tokens, then craft valid JWT tokens to gain administrative access to Home Assistant instances.

Blueprint Studio is a VS Code-like file editor for Home Assistant configuration files. Prior to 2.5.2, Blueprint Studio exposed administrator-intended backend API actions to any authenticated Home Assistant user because the backend did not consistently enforce the panel's admin-only authorization boundary. Affected surfaces included the backend API, upload API, stream routes, terminal WebSocket, Blueprint Studio WebSocket subscriptions, callservice, rendertemplate, globalreplace, file and stream access paths, upload handling, and terminal helpers. A non-admin user could invoke arbitrary Home Assistant services, expose Home Assistant state through templates, modify configuration files, access streamed or downloaded configuration content, upload files, or reach terminal-related helpers. These actions could compromise the confidentiality, integrity, and availability of the Home Assistant installation. This issue is fixed in version 2.5.2.

HomeAssistant-Tapo-Control offers Control for Tapo cameras as a Home Assistant component. Prior to commit 2a3b80f, there is a code injection vulnerability in the GitHub Actions workflow .github/workflows/issues.yml. It does not affect users of the Home Assistant integration itself — it only impacts the GitHub Actions environment for this repository. The vulnerable workflow directly inserted user-controlled content from the issue body (github.event.issue.body) into a Bash conditional without proper sanitization. A malicious GitHub user could craft an issue body that executes arbitrary commands on the GitHub Actions runner in a privileged context whenever an issue is opened. The potential impact is limited to the repository’s CI/CD environment, which could allow access to repository contents or GitHub Actions secrets. This issue has been patched via commit 2a3b80f. Workarounds involve disabling the affected workflow (issues.yml), replacing the unsafe Bash comparison with a safe quoted grep (or a pure GitHub Actions expression check), or ensuring minimal permissions in workflows (permissions: block) to reduce possible impact.

Summary 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 name given by the Energy integration can also be taken directly from their system, and be vulnerable that way. The execution happens within the energy dashboard, when hovering over a data point:

<img width="1547" height="575" alt="image" src="https://github.com/user-attachments/assets/6e5880c2-cde4-4a96-b573-73756c69d0d8" />

Update found after issue was reported: I found that the issue presents itself for any entity with a html-entity in the name, which is included and rendered in the graph view. Following is an example for a speaker: <img width="423" height="96" alt="11cens" src="https://github.com/user-attachments/assets/3b4d43dd-d9e0-466b-85c0-277af3195acf" />

Source code The relevant source code is added in a comment, but copy pasted here as well:

The offending line of code rendering the payload appears to be: https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/panels/lovelace/cards/energy/hui-energy-devices-graph-card.ts#L110 Where the parameter marked with bold and italic is the vulnerable value: return \${title}${params.marker} ${params.seriesName}: ${value}\;

From the trace below, we can see that the only change done to the friendlyname of an entity is replacing underscores with spaces (computeObjectId(entityId).replace(//g, " ")). We can also determine that any power entity will have it's name used if there is one, and fall back to the friendly name if it cannot find one: data.push({ id: ${compare ? "compare-" : ""}${statId}-${type}, type: "bar", cursor: "default", name: type in labels ? labels[type] : getStatisticLabel( this.hass, statId, statisticsMetaData[statId] ), (https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/panels/lovelace/cards/energy/hui-energy-usage-graph-card.ts#L467-L478)

The value comes from:

1. https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/panels/lovelace/cards/energy/hui-energy-usage-graph-card.ts#L467-L478 (This is the relevant call: getStatisticLabel(this.hass, statId, statisticsMetaData[statId];)

2. getStatisticLabel is defined here: https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/data/recorder.ts#L329-L339 (This is the relevant call: computeStateName(entity);)

3. computeStateName is defined here: https://github.com/home-assistant/frontend/blob/c13a80ce5e7ae39f0262444e2b6295a074a96732/src/common/entity/computestatename.ts

-----

PoC 1. Set up a new energy provider with a price sensor. 2. Give the price sensor a malicious name <img width="814" height="100" alt="4cens" src="https://github.com/user-attachments/assets/64bf7a00-47a2-46db-ae0f-b93e328837d2" /> <img width="459" height="325" alt="5cens" src="https://github.com/user-attachments/assets/e43e1c4f-bb4e-45b4-b46a-a6fc32b689ba" />

3. Configure the energy dashboard to get data from the price sensor <img width="582" height="394" alt="image" src="https://github.com/user-attachments/assets/74c99ab8-0842-4c1b-b2e9-994827d89609" />

<img width="1678" height="241" alt="7cens" src="https://github.com/user-attachments/assets/24f4c83a-3c0a-4dea-9e1c-9c6b070fb28f" />

<img width="329" height="497" alt="8cens" src="https://github.com/user-attachments/assets/ccb7f90a-4745-4fb4-9efa-f30b3324cb3a" />

5. Look at the data and hover the data point for code to execute. (You may have to trigger data ingestion or add a false data point to be able to hover a data point when testing, you need at least one datapoint to trigger the vulnerability) <img width="1547" height="575" alt="9cens" src="https://github.com/user-attachments/assets/087cdf78-a503-427d-8e0c-bb5db24de5c8" />

Impact It is possible to exploit this over the internet, by using an energy provider, like Tibber, with a malicious name, and relying on the default naming in Home Assistant being used. This is actually how I found this bug: <img width="453" height="152" alt="10cens" src="https://github.com/user-attachments/assets/45451efb-2688-4589-a988-88d1fc0b4e25" />

This means that a malicious employee or someone with access to your electricity provider can attack your Home Assistant instance from your electricity provider. I am unsure if you consider this a sanitization and escaping issue in the respective integrations or not, but I believe a central fix in the form of fixing the Energy Dashboard is more appropriate, rather than to rely on every integration properly handling user input.

Home Assistant is open source home automation software that puts local control and privacy first. Prior to 2026.4.1 for iOS and 2026.4.4 for Android, he Home Assistant Companion apps for Android and iOS expose a JavaScript bridge to the in-app WebView window.externalApp on Android and webkit.messageHandlers.getExternalAuth (alongside revokeExternalAuth and externalBus) on iOS. Two flaws expose the bridge to all frames (including cross-origin iframes) and unsanitized interpolation of the JavaScript callback identifier allows a cross-origin iframe rendered inside the Companion app to execute arbitrary JavaScript in the Home Assistant frontend's main-frame origin and exfiltrate the signed-in user's access token. This vulnerability is fixed in 2026.4.1 for iOS and 2026.4.4 for Android.

Home Assistant is open source home automation software that puts local control and privacy first. Prior to 2025.5.0, The iOS companion app ignores the SSID allowlist for internal networks. The app uses SSID to detect when to use the internal URL, but whenever the app cannot find any other URL to be used, it fallbacks to the internal URL as well, which can expose user's token when connected to a not secure network. This vulnerability is fixed in 2025.5.0.

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 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.

Home Assistant is open source home automation software focused on local control and privacy. Prior to 2026.5.3, the Companion app treats tag links (NFC or QR) delivered through an OS-level routing mechanism as if they were physically scanned, without validating the calling app or prompting the user. As a result, any untrusted app on the device can forward an arbitrary tag to Home Assistant, causing it to execute the associated automation as though a legitimate user had scanned an authorized tag. This allows silent, unattended automation execution by untrusted local callers. This issue is fixed in version 2026.8.1.

Summary

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: https://github.com/home-assistant/core/blob/c4411914c2e906105b765c00af5740bd0880e946/homeassistant/components/discord/notify.py#L84

When you scan the libraries used by the integrations in Home Assistant, you will find more issues like this.

The general handling in Home Assistant looks good, as homeassistant.helpers.aoihttpclient.asyncgetconnector handles it correctly.

PoC

1. Check that expired.badssl.com:443 gives an SSL error in when connecting with curl or browser. 2. Add the integration adguard with the setting host=expired.badssl.com, port=443, use-ssl=true, verify-ssl=true. 3. Check the logs - you get a HTTP 403 response.

Expected behavior: 1. The integration log shows an ssl.SSLCertVerificationError.

The following code shows the problem with ssl=True. No exception is raised when ssl=True (Python 3.11.6).

import asyncio from ssl import SSLCertVerificationError

import aiohttp

BADURL = "https://expired.badssl.com/"

async def runrequest(verifyssl, resultplaceholder: str): async with aiohttp.ClientSession() as session: exceptionfired: bool = False try: await session.request("OPTIONS", BADURL, ssl=verifyssl) except SSLCertVerificationError: exceptionfired = True except Exception as error: print(error) else: exceptionfired = False print(resultplaceholder.format(exceptionresult=exceptionfired))

Case 1: ssl=False --> expected result: No exception asyncio.run(runrequest(False, "Test case 1: expected result: False - result: {exceptionresult}"))

Case 2: ssl=None --> expected result: Exception asyncio.run(runrequest(None, "Test case 2: expected result: True - result: {exceptionresult}"))

Case 3: ssl=True --> expected result: No Exception asyncio.run(runrequest(True, "Test case 3: expected result: False - result: {exceptionresult}"))

Summary

The ha-mcp OAuth consent form renders user-controlled parameters via Python f-strings with no HTML escaping. An attacker who can reach the OAuth endpoint and convince the server operator to follow a crafted authorization URL could execute JavaScript in the operator's browser. This affects only users running the beta OAuth mode (ha-mcp-oauth), which is not part of the standard setup and requires explicit configuration.

Details

Unescaped f-string rendering

consentform.py builds HTML using Python f-strings. No call to html.escape() exists anywhere in the file. The following values are rendered unescaped:

- clientname / clientid — in HTML element context (lines 299, 303) - clientid, redirecturi, state — in HTML attribute context (lines 310–312), where a " character breaks out of value="" - errormessage, error, errordescription — in error display paths (lines 36–40, 496–497)

An attacker can register a client with a malicious clientname via the /register (DCR) endpoint, which accepts clientname without sanitization. If the server operator then visits a crafted authorization URL for that client, the payload executes in their browser.

Open Dynamic Client Registration

DCR is enabled by default with no initial access token required. This is intentional: Claude.ai and ChatGPT must self-register on first use, which is the standard MCP OAuth flow (RFC 7591). Requiring a pre-shared token would break those integrations. Registration alone grants no access — authorization requires an explicit action by the server operator.

Impact

Affected configuration: OAuth mode only (ha-mcp-oauth, requires MCPBASEURL). This mode is in beta and is not included in the main setup documentation. The vast majority of ha-mcp users run stdio mode, which is not affected.

Attack requirements: 1. The attacker can reach the ha-mcp OAuth endpoint (it binds to 0.0.0.0 in HTTP mode) 2. The attacker registers a malicious client via /register 3. The attacker convinces the server operator — the person who set up ha-mcp — to follow a crafted authorization URL for an unrecognized application

Step 3 is a meaningful social engineering bar: the consent form displays the (unfamiliar) application name, and the operator has no legitimate reason to authorize an OAuth client they didn't initiate through Claude.ai or ChatGPT. Normal usage involves being redirected to the consent form from one of those platforms, not from an external link.

If exploited, a JavaScript payload could exfiltrate data entered into the consent form, including the Home Assistant Long-Lived Access Token.

Fix

Upgrade to 7.0.0

Summary

The ha-mcp OAuth consent form (beta feature) accepts a user-supplied haurl and makes a server-side HTTP request to {haurl}/api/config with no URL validation. An unauthenticated attacker can submit arbitrary URLs to perform internal network reconnaissance via an error oracle. Two additional code paths in OAuth tool calls (REST and WebSocket) are affected by the same primitive.

The primary deployment method (private URL with pre-configured HOMEASSISTANTTOKEN) is not affected.

Details

Code path 1 — Consent form validation (reported)

When a user submits the OAuth consent form, validatehacredentials() (provider.py) makes a server-side GET request to {haurl}/api/config with no scheme, IP, or domain validation. Different exception types produce distinct error messages, creating an error oracle:

| Outcome | Message returned | Information leaked | |---------|------------------|--------------------| | ConnectError | "Could not connect..." | Host down or port closed | | TimeoutException | "Connection timed out..." | Host up, port filtered | | HTTP 401 | "Invalid access token..." | Service alive, requires auth | | HTTP 403 | "Access forbidden..." | Service alive, forbidden | | HTTP ≥ 400 | "Failed to connect: HTTP {N}" | Service alive, exact status |

An attacker can drive the flow programmatically: register a client via open DCR (POST /register), initiate authorization, extract a txnid, and submit arbitrary haurl values. No user interaction required.

Code path 2 — REST tool calls with forged token

OAuth access tokens are stateless base64-encoded JSON payloads ({"haurl": "...", "hatoken": "..."}). Since tokens are not signed, an attacker can forge a token with an arbitrary haurl. REST tool calls then make HTTP requests to hardcoded HA API paths on that host (/config, /states, /services, etc.). JSON responses are returned to the caller.

In practice, path control is limited — most endpoints use absolute paths that ignore the haurl path component. Useful exfiltration requires the target to return JSON at HA API paths, which is unlikely for non-HA services.

Code path 3 — WebSocket tool calls with forged token

The same forged token triggers WebSocket connections to ws://{haurl}/api/websocket. The client follows the HA WebSocket handshake protocol (waits for authrequired, sends auth, expects authok). Non-HA targets fail at the protocol level and return nothing useful. Realistic exploitation is limited to pivoting to another HA instance on the internal network.

Impact

Confirmed: Internal network reconnaissance via error oracle (all 3 code paths). An attacker can map reachable hosts and open ports from the server's network position.

Scope

OAuth mode is a beta feature, documented separately in docs/OAUTH.md and not part of the main setup instructions. The standard deployment method (pre-configured HOMEASSISTANTURL and HOMEASSISTANTTOKEN) is not affected.

Fix

Upgrade to 7.0.0

Home Assistant is open source home automation software focused on local control and privacy. Prior to 2026.6.1, the Android Companion app is vulnerable to an open redirect. The app passes the URL fragment from a homeassistant://invite deep link into the onboarding flow without ever displaying the destination hostname. Because no screen in the invitation or onboarding flow shows the parsed server URL before onboarding commits to it, a victim has no way to distinguish a legitimate invite from a malicious one. An attacker can craft an invite so that a single tap on the legitimate-looking "Connect to my Home Assistant server" button opens their /auth/authorize endpoint in the URL-less onboarding WebView, presenting a look-alike login page that captures the victim's credentials. Since invitations are intended to onboard brand-new users, targets are especially unlikely to notice the substitution. This issue is fixed in version 2026.6.1.

Home Assistant Core before 2026.5.4 contains a cross-site scripting vulnerability in the Shelly integration's asyncgetmediaimage() method that allows attackers controlling a Shelly device's thumb field to serve arbitrary HTML content by supplying a data URI with a text/html content type without validation against an image-only allowlist. Attackers can cause the media player proxy endpoint to serve attacker-controlled bytes with Content-Type text/html in the Home Assistant web origin, enabling theft of session tokens from local storage and authenticated calls to sensitive service endpoints including lock, alarm, and cover controls.

The homeassistant-tapo-control repository was vulnerable to code injection in the issues.yml GitHub Actions workflow.

This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Home Assistant Green. An attacker must first obtain the ability to access the device&#x27;s localhost interface. The ZDI has assigned a CVSS rating of 7.5.

This vulnerability allows network-adjacent attackers to initiate arbitrary server-side requests on affected installations of Home Assistant Green. Authentication is not required to exploit this vulnerability. The ZDI has assigned a CVSS rating of 5.4.