AWS Warns of Certificate Validation Flaw in IoT Python SDK

AWS Warns of Certificate Validation Flaw in IoT Python SDK

Amazon Web Services has disclosed a security vulnerability in the AWS IoT Device SDK for Python that could allow an attacker positioned between an IoT device and AWS IoT Core to impersonate the expected cloud endpoint.

The vulnerability, tracked as CVE-2026-92943, affects the SDK's MQTT client TLS connection layer. AWS says the issue involved improper validation of whether the server certificate matched the hostname of the AWS IoT Core endpoint.

The affected versions are 1.5.3 through 1.6.0 when used with Python 3.7 or later. AWS has addressed the issue in AWSIoTPythonSDK version 1.6.1 and says customers must upgrade because there is no workaround for the affected default connection paths.

What is CVE-2026-92943?

CVE-2026-92943 is a certificate validation vulnerability in the AWS IoT Device SDK for Python, also known as AWSIoTPythonSDK.

The SDK allows Python applications and IoT devices to communicate with AWS IoT using MQTT and MQTT over WebSocket. AWS documentation for the SDK identifies X.509 mutual authentication and WebSocket with AWS Signature Version 4 as supported connection methods.

The security problem occurred during TLS connection establishment.

According to AWS, the affected MQTT client did not properly verify that the server certificate presented during the connection was issued for the expected AWS IoT Core endpoint hostname.

That distinction matters because certificate trust and hostname validation are separate parts of secure TLS communication.

A certificate can be issued by a trusted certificate authority while still belonging to a different hostname.

In the vulnerable situation, AWS says an attacker positioned on the network could present a certificate for an unrelated hostname, provided that certificate was issued by a certificate authority trusted by the device.

If accepted, the attacker could impersonate the AWS IoT Core endpoint to the affected device.

How the vulnerability could affect an IoT device

The potential attack described by AWS involves an adversary-in-the-middle positioned on the network.

At a simplified level, the communication path normally looks like this:

IoT Device → TLS connection → AWS IoT Core

With the vulnerability, AWS describes a scenario where an attacker could position themselves between the device and the expected endpoint:

IoT Device → Attacker → AWS IoT Core

The attacker could present a certificate issued for another hostname that is trusted by the device.

Because the vulnerable SDK did not correctly validate the certificate against the AWS IoT Core hostname, the attacker could potentially impersonate the expected endpoint.

AWS states that this could allow the attacker to:

• Read device telemetry

• Inject arbitrary MQTT messages

• Cause the device to process those messages as authentic

The impact therefore goes beyond simply observing encrypted traffic. According to AWS, the attacker could also influence MQTT messages received by the affected device.

Which AWS IoT connections are affected?

AWS says that both documented default connection paths were affected.

1. X.509 mutual authentication on port 8883

The first affected path uses MQTT with X.509 mutual authentication over port 8883.

AWS IoT applications commonly use device certificates and private keys as part of certificate-based authentication. The AWS IoT Device SDK for Python documentation identifies MQTT over TLS with X.509 certificate-based mutual authentication as one of its connection types.

According to the AWS bulletin, this default connection path was affected by CVE-2026-92943.

2. WebSocket with SigV4 on port 443

The second affected path is MQTT over WebSocket using AWS Signature Version 4 authentication on port 443.

AWS specifically states that this connection path was also affected.

However, there is an important distinction.

The port 443 ALPN path was not affected

AWS says the port 443 ALPN path was not affected by this vulnerability.

This distinction is important when assessing an existing IoT deployment because not every connection method supported by the SDK was impacted in the same way.

Which versions are affected?

AWS identifies the affected range as:

AWSIoTPythonSDK 1.5.3 through 1.6.0

The affected versions apply when running on Python 3.7 or later.

AWS does not identify an additional affected version range beyond the versions listed in the bulletin.

What could an attacker do?

The security consequences described by AWS involve both confidentiality and message integrity.

Read device telemetry

If an attacker successfully impersonated the AWS IoT Core endpoint, AWS says the attacker could read telemetry transmitted by the device.

For IoT deployments, telemetry can represent information generated by sensors, industrial equipment, connected products or other connected systems.

Inject MQTT messages

The attacker could also inject arbitrary MQTT messages.

This is particularly important because MQTT is frequently used for communication between connected devices and cloud services.

AWS says that messages injected through the described attack could be processed by the device as authentic.

The actual consequences of an injected message would depend on how an individual application handles MQTT messages. AWS did not provide specific information about what actions individual customer applications might perform after receiving such messages.

Why hostname validation matters in TLS

TLS certificates are used to establish trust in encrypted communications, but certificate validation involves more than simply asking whether a certificate comes from a trusted certificate authority.

The application also needs to determine whether the certificate is valid for the server it intended to reach.

In this case, AWS says the affected SDK failed to validate that the server certificate matched the AWS IoT Core endpoint hostname.

A simplified validation process can be viewed as:

1. Device connects to expected hostname

↓

2. Server presents certificate

↓

3. Certificate chain is validated

↓

4. Certificate identity is checked against expected hostname

↓

5. Secure connection proceeds

CVE-2026-92943 involved the hostname matching portion of this process.

This illustrates why TLS configuration and certificate validation should be treated as multiple security checks rather than a single "certificate is trusted" decision.

AWS recommends upgrading to version 1.6.1

AWS has fixed the vulnerability in AWSIoTPythonSDK version 1.6.1.

The company recommends upgrading to the latest version and specifically advises customers to ensure that any forked or derivative code also incorporates the relevant fixes.

The official AWS IoT Device SDK for Python repository provides the SDK source and installation information.

For projects using the package directly, the repository documents installation through pip:

pip install AWSIoTPythonSDK

After updating, teams should verify the installed package version in the environment used by their IoT application.

For example:

pip show AWSIoTPythonSDK

If a project uses a fork or locally modified copy, simply updating the package may not be sufficient. AWS explicitly recommends ensuring that derivative code incorporates the security fixes.

There is no workaround

AWS states that no workaround is available for this issue.

The reason is that the vulnerable connection methods are the SDK's documented default paths.

AWS therefore directs affected customers to upgrade to version 1.6.1 rather than relying on a configuration-based mitigation.

For organizations managing IoT fleets, this makes version inventory particularly important.

Teams should identify:

1. Devices running the affected SDK

2. The SDK version deployed on those devices

3. The Python runtime version

4. The MQTT connection method being used

5. Any forked or derivative SDK code

6. The deployment process used to distribute the patched version

What security teams should check now

Organizations using the AWS IoT Device SDK for Python should begin with an inventory check.

Check the installed SDK

A Python environment can be inspected with:

pip show AWSIoTPythonSDK

Teams can then compare the installed version with AWS's affected range of 1.5.3 through 1.6.0.

Review IoT connection configurations

AWS identifies the following affected paths:

• X.509 mutual authentication on port 8883

• WebSocket with SigV4 on port 443
  

The port 443 ALPN path was not affected according to AWS.

Update affected deployments

AWS's recommended resolution is to upgrade to version 1.6.1.

Review forked SDK implementations

Organizations that maintain their own fork or derivative implementation should also review whether the security fix has been incorporated.

AWS explicitly includes forked and derivative code in its remediation guidance.

What this means for IoT security

The vulnerability highlights an important security principle for connected devices: authentication must validate not only whether a certificate is trusted, but also whether it represents the expected endpoint.

For enterprises, this could mean that software inventory and dependency management remain important parts of IoT security operations.

IoT devices can remain deployed for long periods, sometimes across large distributed environments. That makes identifying vulnerable libraries and distributing security fixes an important operational task.

The announcement also highlights a broader industry shift toward treating device software dependencies as part of the overall security boundary. A vulnerability inside an SDK can affect how a device establishes trust with cloud infrastructure, even when the underlying cloud service itself is not the vulnerable component.

AWS IoT SDK security update: Key facts

All vulnerability and remediation details in the table are based on AWS's September 17, 2026 security bulletin.

Final thoughts

CVE-2026-92943 is a certificate validation issue affecting specific versions of the AWS IoT Device SDK for Python.

AWS says the vulnerability could allow an adversary-in-the-middle to impersonate an AWS IoT Core endpoint when the affected connection paths are used, potentially exposing telemetry and allowing malicious MQTT messages to be processed as authentic.

The immediate remediation is straightforward: affected customers should upgrade to AWSIoTPythonSDK 1.6.1 and review any forked or derivative SDK implementations.

Because AWS says there is no workaround for the affected default connection paths, organizations using versions 1.5.3 through 1.6.0 should treat version assessment and upgrading as an important IoT security maintenance task.

Acknowledgement: AWS credits George Chen for collaborating through its coordinated vulnerability disclosure process.