Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-08-28T16:18:28.890Z",
  "pubdate": "2026-08-28T16:18:28.890Z",
  "executiveSummary": "The vulnerability involves an improper cryptographic implementation within wolfEngine versions prior to 1.4.1, specifically affecting TLS 1.2 and DTLS 1.2 sessions using AES-GCM cipher suites.\nThe flaw manifests as the failure to increment the 8-byte explicit nonce for successive records within a single connection, resulting in key and nonce reuse.\nThis cryptographic failure allows an attacker capable of intercepting network traffic to recover the keystream through XOR analysis of captured ciphertexts.\nThe reuse of the GCM nonce/key pair leads to the leakage of the GHASH authentication key, which fundamentally breaks the integrity and confidentiality guarantees of the affected TLS/DTLS sessions.\nAn attacker can perform authentication tag forgery, enabling the injection of arbitrary malicious data into the communication stream.\nThis vulnerability poses a critical risk to data privacy and session integrity, as it permits plaintext recovery from captured traffic and successful manipulation of encrypted records without prior authentication or elevated privileges.",
  "technicalDetails": "The root cause of this vulnerability lies in the incorrect state management of the AES-GCM nonce generation logic in wolfEngine. According to the NIST SP 800-38D specification for Galois/Counter Mode (GCM), a unique nonce must be used for every invocation of the encryption function under the same key to ensure security.\nIn the affected wolfEngine versions, the 8-byte explicit nonce is initialized when the TLS write key is established but fails to increment for subsequent records. Consequently, every record transmitted within a single TLS 1.2 or DTLS 1.2 session utilizes an identical (key, nonce) tuple.\nThe primary security consequence of this reuse is the disclosure of the keystream. AES-GCM acts as a stream cipher where the ciphertext C is generated by C = P ⊕ E(K, IV, counter). If two plaintexts (P1, P2) are encrypted with the same key and nonce (IV), the resulting ciphertexts (C1, C2) satisfy the relationship C1 ⊕ C2 = P1 ⊕ P2. By XORing two intercepted ciphertexts, an attacker cancels out the keystream, leaving the XOR of the underlying plaintexts. If the content of one record is known or predictable, the plaintext of the other record can be recovered immediately.\nFurthermore, the reuse of the nonce leads to the catastrophic failure of the GHASH authentication component. The security of the GHASH function relies on the GHASH authentication key, which is derived from the master secret. When a nonce is reused, the structure of the authentication tag allows an attacker to solve for the subkey used in the GHASH computation. Once the GHASH key is recovered, the attacker can generate valid authentication tags for arbitrary payloads, effectively bypassing the integrity protections of the AES-GCM construction.\nThe exploitation flow involves a passive listener capturing two or more encrypted records from a target connection. No specific privilege is required to capture this traffic, as it occurs over the network layer. After the keystream is recovered through XOR analysis, the attacker can decrypt traffic in real-time or perform an active man-in-the-middle (MitM) attack to forge packets. The vulnerability is strictly isolated to AES-GCM within TLS 1.2 and DTLS 1.2; AES-CCM, TLS 1.3, and non-TLS cryptographic operations are not impacted by this implementation error."
}