CVE-2026-81341 in wolfEngine
Summary
by MITRE • 08/28/2026
wolfEngine before 1.4.1 sources the explicit AES-CCM nonce for TLS 1.2 and DTLS 1.2 records from the record input buffer instead of the TLS sequence number carried in the additional authenticated data. Because the record layer leaves the explicit-nonce field for the cipher to populate, the value read is constant across records, so every AES-CCM record within a connection is encrypted under an identical key and nonce pair. Reusing a CCM key and nonce weakens confidentiality (identical keystream across records, so a known record recovers the others) and integrity (authentication tag forgery). Only wolfEngine is affected; wolfProvider is not. AES-GCM under wolfEngine is tracked separately. AES-CCM cipher suites are not enabled by default and must be explicitly selected, which limits exposure. TLS 1.3 and non-TLS use of the cipher are not affected.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in wolfEngine versions prior to 1.4.1 represents a critical implementation flaw within the cryptographic handling of Transport Layer Security version 1.2 and Datagram Transport Layer Security version 1.2 records when utilizing AES-CCM cipher suites. This issue stems from an incorrect sourcing mechanism for the explicit nonce required by the Advanced Encryption Standard in Ciphertext-Cipher Block Chaining with CBC-MAC mode, specifically known as Counter with Cipher Block Chaining Message Authentication Code or simply CCM. In a compliant TLS implementation, the encryption process relies on a unique combination of key and nonce to ensure both confidentiality and integrity for each transmitted record. The protocol specification dictates that this nonce is constructed by combining an implicit portion derived from the sequence number carried in the additional authenticated data with an explicit portion provided within the record header itself. However, wolfEngine incorrectly sources the entire explicit AES-CCM nonce directly from the record input buffer rather than deriving it correctly from the TLS sequence number and the explicit field.
This architectural error results in a severe cryptographic failure where every AES-CCM encrypted record sent over a single connection utilizes an identical key and nonce pair. Because the record layer leaves the explicit-nonce field for the cipher to populate, and due to the flawed sourcing logic, the value read remains constant across all records within that session. This scenario constitutes a catastrophic violation of fundamental cryptographic principles regarding nonce uniqueness. In symmetric encryption schemes like AES-CCM, reusing a key with the same nonce effectively nullifies the security guarantees provided by the algorithm. The system behaves as if it is using a stream cipher where the keystream is generated once and reused for all subsequent messages, rather than generating a fresh keystream for each record based on unique input parameters.
The operational impact of this vulnerability is twofold, affecting both confidentiality and integrity with severe consequences. Regarding confidentiality, the reuse of the key and nonce means that identical plaintexts will produce identical ciphertexts, but more critically, if an attacker can determine or guess any portion of a single record's content, they can use that known-plaintext information to recover the entire keystream used for all other records in the connection. This allows for the decryption of subsequent messages without needing the private key, effectively breaking the confidentiality guarantees expected from TLS 1.2 and DTLS 1.2 communications. The attacker does not need to break the AES algorithm itself but merely exploits the deterministic nature of the flawed nonce generation to reverse-engineer the encryption stream.
Furthermore, the integrity protection provided by CCM is also compromised. Since the authentication tag is computed using the same key and nonce for every record, an adversary who can manipulate or observe traffic may be able to forge valid authentication tags for maliciously crafted records. This undermines the authenticity of the data exchange, allowing potential man-in-the-middle attacks where unauthorized messages could be injected into the stream without detection by the receiving party. The vulnerability is classified under CWE-328, Use of Weak Hash, and more specifically aligns with CWE-310, Cryptographic Issues, as it involves a failure in proper cryptographic implementation leading to weakened security properties. In terms of MITRE ATT&CK mapping, this flaw facilitates techniques associated with T1557, Adversary-in-the-Middle, by enabling the interception and potential modification of encrypted traffic that was assumed to be secure.
It is important to note that this vulnerability exclusively affects wolfEngine and does not impact wolfProvider, which handles cryptographic operations differently or implements the standards correctly. Additionally, AES-GCM cipher suites under wolfEngine are tracked separately and remain unaffected by this specific nonce sourcing error. The scope of exposure is further limited because AES-CCM cipher suites are not enabled by default in most configurations; they must be explicitly selected by the application developer or system administrator during the TLS handshake negotiation. This deliberate selection requirement means that many deployments may never encounter this vulnerability unless specifically configured to use these less common cipher suites.
The flaw does not extend to TLS version 1.3, which utilizes different cryptographic constructions and nonce derivation methods that are immune to this specific implementation error. Similarly, non-TLS uses of the cipher within wolfEngine are not affected, indicating that the bug is isolated strictly to the TLS/DTLS record layer integration logic for versions 1.2 and earlier. To mitigate this risk, organizations using wolfEngine must upgrade immediately to version 1.4.1 or later, where the nonce sourcing mechanism has been corrected to properly utilize the sequence number from the additional authenticated data as intended by the protocol specifications. Until such an update is applied, any deployment relying on AES-CCM cipher suites for TLS 1.2 or DTLS 1.2 connections remains vulnerable to passive eavesdropping and active message forgery attacks that exploit the deterministic keystream generation caused by nonce reuse.