AWS IoT SDK EUVD-2026-82378

Requires an active adversary-in-the-middle position on the network path between the device and the AWS IoT Core endpoint, AND a TLS certificate issued for an unrelated hostname by a certificate authority that is already present in the device's trust store. It affects AWS IoT Device SDK for Python (v1 AWSIoTPythonSDK) versions 1.5.3 through 1.6.0 running on Python 3.7 and later. Limiting factors: the attacker must obtain such a trusted-CA certificate and hold an on-path/MITM position, so exploitation is not possible remotely from an arbitrary internet location against a device with an uncompromised network path; upgrading to 1.6.1 fully remediates by enforcing hostname verification.

The vendor's CVSS 4.0 base score of 9.2 (Critical) reflects full compromise of confidentiality and integrity (VC:H/VI:H/VA:H) over a network vector with no privileges or user interaction (AV:N/PR:N/UI:N), but the AT:P flag (attack requirements present) is doing important work: exploitation requires both an adversary-in-the-middle (AiTM) network position AND a certificate issued for an unrelated hostname by a certificate authority already present in the device trust store. This is a genuine TLS trust flaw (CWE-297 improper certificate validation with host mismatch), not a low-real-risk high-CVSS artifact, but the AiTM + trusted-CA-certificate prerequisites make it materially harder than a fully unauthenticated remote flaw. No EPSS score was provided, there is NO CISA KEV listing, and no public exploit code was identified; exploitation therefore appears theoretical/opportunistic rather than widespread. The description and CVSS are consistent (network vector, MITM). One nuance to verify: the vendor scores VA:H (high availability impact), but the described impact is telemetry disclosure and message injection - availability degradation is not clearly established, so VA:H may be aggressive.

An attacker positioned on the network path between an IoT device and AWS IoT Core (e.g., on a compromised Wi-Fi/router or upstream link) presents a TLS certificate that is valid and signed by a CA in the device's trust store but issued for an unrelated hostname. Because the SDK does not verify the endpoint hostname against the certificate, the device accepts the impostor as the genuine AWS IoT Core endpoint, letting the attacker read all device telemetry and inject arbitrary MQTT messages the device treats as authentic. No public exploit code has been identified; the flaw was reported by the vendor (Amazon).