CVE-2026-81020 in wolfEngine
Summary
by MITRE • 08/28/2026
wolfEngine before 1.4.1 generates the 8-byte explicit AES-GCM nonce once when the TLS write key is set and never increments it per record. As a result every TLS 1.2 and DTLS 1.2 AES-GCM record within a connection is encrypted under an identical key and nonce pair. Reusing a GCM key and nonce discloses the keystream (the XOR of two ciphertexts equals the XOR of their plaintexts, so one known record recovers the others) and leaks the GHASH authentication key, enabling authentication tag forgery. AES-CCM, TLS 1.3, and non-TLS use of the cipher are not affected.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in wolfEngine versions prior to 1.4.1 represents a critical cryptographic implementation flaw within the Transport Layer Security protocol handling mechanisms. Specifically, the engine fails to adhere to the fundamental security requirement that each encryption operation using AES-GCM must utilize a unique nonce combined with the same key. In this flawed implementation, when a TLS write key is established for a connection, wolfEngine generates an eight-byte explicit nonce only once at initialization and subsequently reuses this identical nonce-value pair for every subsequent record encrypted within that specific session. This behavior directly violates the one-time pad principle inherent to stream ciphers like GCM, where the security relies entirely on the uniqueness of the input vector for each encryption event. The flaw specifically impacts TLS 1.2 and DTLS 1.2 connections utilizing AES-GCM cipher suites, while correctly implemented modes such as AES-CCM, the newer TLS 1.3 protocol which manages nonces differently, and any non-TLS usage of the cipher remain unaffected by this specific defect.
From a technical perspective, the reuse of an AES-GCM key and nonce pair leads to catastrophic cryptographic failures that compromise both confidentiality and integrity. When two distinct plaintexts are encrypted with the same key and nonce, the resulting ciphertexts allow for a known-plaintext attack vector where XORing the two ciphertexts yields the XOR of their respective plaintexts. If an attacker can predict or obtain even one of these plaintexts through traffic analysis or other means, they can immediately derive the keystream used by GCM. Once the keystream is recovered, all other messages encrypted under that same key and nonce pair are instantly decrypted without requiring any further computational effort to break the underlying AES algorithm. Furthermore, this flaw exposes the GHASH authentication subkey derived during the encryption process. Knowledge of this internal state allows an adversary to forge valid authentication tags for arbitrary malicious data, effectively bypassing message integrity checks entirely. This transforms a confidentiality breach into a complete compromise of secure communication channels, enabling man-in-the-middle attacks where traffic can be both read and modified undetected by standard TLS verification mechanisms.
The operational impact of this vulnerability is severe, particularly in environments relying on wolfEngine for securing network communications over TLS 1.2 or DTLS 1.2. Organizations utilizing affected versions are exposed to the risk of sensitive data exfiltration, including credentials, personal identifiable information, and proprietary business logic transmitted within encrypted sessions. Beyond confidentiality loss, the ability to forge authentication tags means that attackers can inject malicious commands, alter transaction details in financial applications, or redirect traffic without triggering alerts from integrity verification systems. This undermines the core trust model of TLS, rendering encryption useless for protecting data in transit against active adversaries who possess sufficient network access to observe and manipulate packets within a session. The severity is compounded by the fact that this is an implementation error rather than a weakness in the AES-GCM algorithm itself, meaning it may not be immediately apparent through standard vulnerability scanning tools that focus on protocol versioning or weak cipher selection.
To mitigate this risk, immediate action must be taken to upgrade wolfEngine to version 1.4.1 or later, where the nonce generation logic has been corrected to ensure a unique nonce is generated for every individual record encrypted within a connection. For systems unable to patch immediately due to dependency constraints, temporary mitigations should focus on reducing session duration and frequency of key reuse if possible, although this does not fully eliminate the risk given the deterministic nature of the flaw. It is also advisable to review network traffic logs for anomalies that might indicate active exploitation attempts, such as repeated connections with similar patterns or unexpected decryption failures in logging systems that track integrity check results. Long-term resilience requires enforcing TLS 1.3 where feasible, as its design inherently mitigates many nonce management pitfalls found in earlier protocol versions through explicit counter-based nonce construction mechanisms defined by the standard.
This vulnerability aligns closely with CWE-328, which describes the use of a single value for multiple cryptographic operations, and specifically relates to CWE-310 regarding cryptographic weaknesses that lead to information disclosure or integrity loss. In terms of offensive security frameworks, this flaw facilitates techniques associated with MITM: Traffic Decryption under ATT&CK ID T1557, allowing adversaries to intercept and read sensitive data in transit. Additionally, the ability to forge authentication tags corresponds to MITM: Tampering Under Attack (T1558), enabling attackers to modify intercepted communications without detection. Security teams should treat this as a high-severity issue requiring prompt remediation through software updates and configuration reviews to ensure that all TLS 1.2 and DTLS 1.2 connections utilize properly randomized nonces for each encrypted record, thereby restoring the intended security guarantees of AES-GCM encryption.