CVE-2026-34876

What it actually does

The flaw is an out-of-bounds read in Mbed TLS CCM authentication-tag finalization. In affected Mbed TLS 3.x releases before 3.6.6, applications that use the public multipart CCM API can call mbedtls_ccm_finish() with a tag_len value larger than the internal 16-byte authentication buffer. Because the parameter is not properly bounded, the function may copy or expose bytes adjacent to the CCM context in memory. The primary impact is confidentiality loss: adjacent process memory could be disclosed to a remote attacker if the application exposes attacker-controlled CCM operations and returns or otherwise reveals the oversized tag output. Integrity and availability are not directly affected by the described issue. In Mbed TLS 4.x pre-fix code, the same missing validation exists internally, but the vulnerable function is not exposed as a public API, making practical exploitation more dependent on product-specific implementation paths.

Why it matters to the business

Products embedding affected Mbed TLS versions may accidentally disclose sensitive in-process data such as cryptographic context material, protocol state, session data, or nearby application memory if they expose the multipart CCM API in a way an attacker can influence. This is most relevant for network services, IoT/embedded products, VPNs, gateways, and applications that use CCM-mode authenticated encryption and return authentication tags or error/debug data to untrusted callers. Although current public exploitation signals are low, with EPSS stable at 0.0039 and no known CISA KEV listing or ransomware association, the impact can be serious where Mbed TLS is widely embedded in downstream products and firmware because patch deployment may depend on vendor rebuilds and firmware release cycles.

How an attack unfolds

An attacker first identifies an application or device built with an affected Mbed TLS release that exposes a feature using the multipart CCM API. The attacker then sends crafted input that causes the application to initialize a CCM operation and eventually invoke mbedtls_ccm_finish() with an attacker-controlled tag_len greater than 16 bytes. Because the library does not validate tag_len against the internal authentication buffer size, the finish operation reads beyond the intended 16-byte tag buffer into adjacent CCM context memory. If the application copies the returned bytes into a response, log, protocol field, diagnostic output, or other attacker-observable channel, the attacker can recover nearby memory contents. Repeated requests with oversized lengths and controlled operation state may allow incremental disclosure of sensitive data depending on allocator behavior, compiler layout, and how the embedding application handles the returned tag data.

How to fix it

Upgrade embedded Mbed TLS to a fixed release. For Mbed TLS 3.x, update to Mbed TLS 3.6.6 or later. For Mbed TLS 4.x, use the vendor release that contains the corresponding fix for internal CCM tag-length validation. If consuming Mbed TLS through an operating system package, SDK, firmware BSP, container image, language binding, or third-party appliance vendor, apply the vendor-provided security update and confirm the bundled library version changed. Rebuild statically linked applications and firmware images, because many Mbed TLS deployments do not rely on a dynamically replaceable system library. As a temporary mitigation, audit all calls to mbedtls_ccm_finish() and enforce tag_len <= 16 before invocation; reject oversized tag lengths at API, protocol, and configuration boundaries; avoid returning raw tag buffers on errors; and disable or restrict untrusted access to features that expose multipart CCM operations until patched.

How to confirm the fix worked

Confirm the deployed library is Mbed TLS 3.6.6 or later for 3.x deployments, or a 4.x release containing the fix. For source-based validation, inspect library/ccm.c and verify that mbedtls_ccm_finish() or the internal CCM finish path validates the requested tag length against the 16-byte authentication buffer before copying or returning data. Inventory both dynamically linked and statically linked consumers; for static builds, verify the application or firmware was rebuilt after the library update. Review software bills of materials, package manifests, firmware build metadata, and binary strings for Mbed TLS versions. Where safe in a test environment, add a regression test that invokes the multipart CCM API with tag_len greater than 16 and verify the call fails or truncation is impossible rather than returning adjacent memory.

Typical attack path

1. Identify a reachable product, service, API, firmware component, or protocol implementation that embeds Mbed TLS 3.x before 3.6.6 or an affected pre-fix 4.x implementation path.
2. Confirm that the target uses CCM-mode authenticated encryption and the multipart CCM API rather than only one-shot APIs.
3. Find an input path that influences the requested authentication tag length passed to mbedtls_ccm_finish().
4. Submit crafted requests or messages that cause tag_len to exceed the 16-byte internal CCM authentication buffer.
5. Observe whether the application returns, logs, reflects, or otherwise exposes the oversized tag output or related buffer contents.
6. Repeat and vary request parameters to recover adjacent CCM context data or other nearby process memory where the application behavior permits it.

How to detect it

Historical exploitation is difficult to confirm because successful abuse may look like normal application-level cryptographic API use unless the embedding product logs CCM parameters or returned tag lengths. Review application, API gateway, protocol, and device logs for unusual requests that specify CCM authentication tag lengths greater than 16 bytes, malformed encrypted-message operations, repeated CCM authentication failures, or diagnostic responses containing unexpectedly long authentication tags. If source or debug telemetry is available, look for direct invocations of mbedtls_ccm_finish() where tag_len is derived from untrusted input. For network services, inspect packet captures or protocol logs for fields representing CCM tag length, MAC length, MIC length, or authentication tag size exceeding 16 bytes. In firmware or appliance cases, collect crash/debug logs only as supporting evidence; this issue is primarily an information disclosure and may not crash. There are no public threat actors, campaigns, or ransomware operations reported for this issue in the provided intelligence, and no reliable universal network IOC exists because exploit payloads are application-protocol specific.

What your security team should do

• Prioritize inventory of products and services embedding Mbed TLS, especially embedded, IoT, gateway, VPN, and network-facing components that may use CCM mode.
• Patch or rebuild affected Mbed TLS 3.x deployments to 3.6.6 or later; obtain vendor-fixed firmware or appliances where Mbed TLS is bundled.
• Ask product owners and vendors whether the multipart CCM API is used and whether untrusted input can influence tag_len passed to mbedtls_ccm_finish().
• Add defensive validation in application code to reject CCM authentication tag lengths greater than 16 bytes even after library patching.
• Search codebases and firmware source for direct calls to mbedtls_ccm_finish() and confirm callers bound-check tag_len.
• Treat exposure as higher risk if the affected component returns authentication tags, diagnostic buffers, protocol errors, or debug output to remote users.
• Because there is no KEV listing, no known ransomware association, and no mature public exploit reported, schedule remediation based on exposure and data sensitivity, but do not defer patching for internet-facing or safety-critical embedded products.
• Update SBOMs and dependency tracking so statically linked Mbed TLS copies are not missed in future vulnerability response.