CVE-2026-81341: wolfEngine AES-CCM Nonce Reuse Vulnerability

CVE-2026-81341 Overview

CVE-2026-81341 is a cryptographic vulnerability in wolfEngine versions before 1.4.1. The engine sources the explicit AES-CCM nonce for TLS 1.2 and DTLS 1.2 records from the record input buffer rather than the TLS sequence number in the additional authenticated data. Because the record layer leaves the explicit-nonce field for the cipher to populate, the read value stays constant across records. Every AES-CCM record within a connection is therefore encrypted under an identical key and nonce pair, breaking a fundamental requirement of the CCM mode [CWE-323].

Critical Impact
Nonce reuse under a single AES-CCM key exposes plaintext across records and enables authentication tag forgery, undermining both confidentiality and integrity of affected TLS 1.2 and DTLS 1.2 sessions.

Affected Products

wolfEngine versions prior to 1.4.1
TLS 1.2 connections negotiated with AES-CCM cipher suites
DTLS 1.2 connections negotiated with AES-CCM cipher suites

Discovery Timeline

2026-08-28 - CVE-2026-81341 published to the National Vulnerability Database
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-81341

Vulnerability Analysis

AES-CCM (Counter with CBC-MAC) is an authenticated encryption mode that requires a unique nonce for every message encrypted under a given key. In TLS 1.2 and DTLS 1.2, the explicit nonce portion is derived from the TLS record sequence number carried in the additional authenticated data (AAD). wolfEngine before 1.4.1 instead reads the explicit-nonce bytes from the record input buffer. The record layer never populates that field before invoking the cipher, so the engine consumes uninitialized or static bytes for every record.

The result is that all AES-CCM records within a single connection are encrypted with the same key and the same nonce. This collapses the CCM security model: the counter-mode keystream becomes identical across records, and the CBC-MAC tag construction loses its unpredictability guarantees. Recovery of one plaintext record leaks the keystream that protects every other record on the connection. An adversary who can observe or influence traffic can also forge authenticated ciphertexts, defeating record integrity.

Exposure is limited by configuration. AES-CCM cipher suites are not enabled by default in wolfEngine and must be explicitly selected by an application. TLS 1.3 sessions, non-TLS use of the AES-CCM cipher, and the separate wolfProvider component are not affected. AES-GCM behavior under wolfEngine is tracked under a separate advisory.

Root Cause

The defect is an incorrect source for the explicit-nonce input to the AEAD call. Per RFC 5288 and related RFCs, the per-record nonce for AEAD cipher suites is constructed from the implicit salt plus the record sequence number carried in the AAD. wolfEngine instead pulled explicit-nonce bytes from the ciphertext record buffer, which the TLS record layer leaves for the cipher to fill. Because that region is not initialized with a monotonically changing value, the nonce input never varies across records within a connection.

Attack Vector

An on-path or passive network attacker who can capture ciphertext from a vulnerable TLS 1.2 or DTLS 1.2 session with an AES-CCM cipher suite can exploit the flaw. Confidentiality attacks require either a known-plaintext record or repeated structured plaintext to recover the shared keystream. Integrity attacks leverage the deterministic tag structure to forge records that the peer will accept. The attack complexity is high because it requires the peer to negotiate an AES-CCM cipher suite, which is not the default selection.

No verified proof-of-concept code is published. See the wolfSSL Security Vulnerabilities advisory page for vendor details.

Detection Methods for CVE-2026-81341

Indicators of Compromise

Repeated identical ciphertext blocks across distinct TLS 1.2 or DTLS 1.2 records within a single session, which indicates keystream reuse.
Successful record processing after unexpected retransmissions or replays that a correct implementation would reject on nonce or sequence checks.
Presence of wolfEngine builds earlier than 1.4.1 linked against OpenSSL-based applications.

Detection Strategies

Inventory hosts and applications that load wolfEngine as an OpenSSL engine and compare installed versions to the fixed release.
Inspect TLS handshakes for negotiation of AES-CCM cipher suites such as TLS_ECDHE_ECDSA_WITH_AES_128_CCM or TLS_RSA_WITH_AES_256_CCM.
Use static analysis of application configuration to identify cipher lists that explicitly enable AES-CCM or AES-CCM8 suites.

Monitoring Recommendations

Log the negotiated cipher suite for every TLS and DTLS session and alert on any AES-CCM selection from hosts running wolfEngine.
Monitor package management and software bill of materials feeds for wolfEngine updates and flag versions below 1.4.1.
Capture and periodically audit TLS traffic samples from wolfEngine-backed services to detect repeated ciphertext patterns.

How to Mitigate CVE-2026-81341

Immediate Actions Required

Upgrade wolfEngine to version 1.4.1 or later on all systems where it is loaded as an OpenSSL engine.
Disable AES-CCM cipher suites in application cipher lists until the upgrade is complete.
Prefer TLS 1.3 for any client-server pair that supports it, since TLS 1.3 sessions are not affected.
Rotate long-lived credentials or session tokens transported over affected AES-CCM sessions if exposure is suspected.

Patch Information

wolfSSL addressed the defect in wolfEngine 1.4.1 by sourcing the explicit AES-CCM nonce from the TLS sequence number in the AAD, in line with RFC guidance. Refer to the wolfSSL Security Vulnerabilities page for the official advisory, patched release notes, and download links. wolfProvider users are not affected and require no action for this CVE.

Workarounds

Configure applications to exclude AES-CCM cipher suites from the negotiated cipher list, for example by removing AES128-CCM, AES256-CCM, and CCM8 variants.
Restrict endpoints to TLS 1.3 where feasible, since the defect does not apply to TLS 1.3 record protection.
Migrate to wolfProvider where the deployment supports it, as wolfProvider is not affected.

bash

# Example: restrict an OpenSSL client or server to non-CCM AEAD suites
openssl ciphers -v 'HIGH:!aNULL:!CCM:!CCM8'

# Example: enforce TLS 1.3 only where the application permits
openssl s_client -connect example.com:443 -tls1_3