CVE-2026-115417 in aws-c-mqttinfo

Summary

by MITRE • 10/23/2026

Memory allocation with excessive size value in the MQTT 3.1.1 compatibility adapter in AWS aws-c-mqtt before 0.16.2 might allow a remote actor to cause a denial of service of the client application.



To remediate this issue, users should upgrade to aws-c-mqtt 0.16.2 or later, or to an AWS Common Runtime or AWS IoT Device SDK release that bundles it.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 10/23/2026

The vulnerability identified in the MQTT 3.1.1 compatibility adapter within the AWS aws-c-mqtt library prior to version 0.16.2 represents a critical memory management flaw rooted in insufficient validation of input parameters during resource allocation processes. This specific defect allows for the possibility that an attacker, acting as a remote actor interacting with the MQTT client application, can supply excessively large size values intended for memory allocation operations. In systems programming languages such as C, which underpin this library, failure to rigorously validate and bound user-supplied or network-derived data before passing it to system-level functions like malloc or similar allocators creates a direct pathway for resource exhaustion attacks. The core technical flaw lies in the adapter's inability to enforce reasonable limits on the payload sizes or frame structures defined by the MQTT 3.1.1 protocol specification, thereby permitting requests that exceed available memory resources or trigger allocation failures that are not gracefully handled within the application logic.

From a security architecture perspective, this vulnerability aligns with CWE-789: Memory Allocation with Excessive Size Value and is closely related to CWE-400: Uncontrolled Resource Consumption. The operational impact of exploiting this flaw centers on causing a denial of service against the client application running the affected library. When an attacker sends crafted MQTT packets containing malformed or excessively large size fields, the underlying memory allocator may attempt to reserve more memory than is physically available in the system heap. This can lead to immediate allocation failures, which if not properly caught and managed by the surrounding code, result in crashes, segmentation faults, or unresponsive states within the client application. In IoT environments where devices often operate with constrained resources such as limited RAM on embedded systems, this vulnerability poses an even greater risk of complete system failure rather than just a temporary slowdown.

The attack vector for this issue is classified under MITRE ATT&CK technique T1498: Network Denial of Service, specifically involving the exhaustion of computational or memory resources through network-based interactions. An adversary does not need authentication to exploit this vulnerability if the MQTT broker allows anonymous connections or if the client application processes incoming messages from untrusted sources without adequate sanitization layers. The exploitation requires only that the remote actor can establish a connection and send specific malformed frames, making it an attractive target for automated scanning tools designed to fuzz network protocols and identify resource exhaustion weaknesses in IoT infrastructure components.

To remediate this vulnerability, organizations must upgrade their dependencies to aws-c-mqtt version 0.16.2 or later. This release includes the necessary patches that implement strict bounds checking on memory allocation sizes within the MQTT compatibility adapter. For users relying on higher-level abstractions, it is essential to ensure that any AWS Common Runtime or AWS IoT Device SDK releases being utilized bundle this corrected library version. Additionally, defense-in-depth strategies should be employed by placing rate-limiting and payload size validation at the network perimeter or load balancer level before traffic reaches the MQTT client applications. This ensures that even if a future vulnerability exists in the application layer, the malicious requests are intercepted upstream, thereby preserving system stability and availability for legitimate users.

Responsible

AMZN

Reservation

10/22/2026

Disclosure

10/23/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!