Description

wolfProvider before 1.2.2 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.757Z",
  "pubdate": "2026-08-28T16:18:28.757Z",
  "executiveSummary": "wolfProvider versions prior to 1.2.2 contain a critical cryptographic implementation flaw regarding the management of AES-GCM nonces within TLS 1.2 and DTLS 1.2 sessions.\nThe vulnerability involves the failure to increment the 8-byte explicit nonce after each record, resulting in the repeated use of an identical key and nonce pair for all records within a single connection.\nThis cryptographic failure allows for the recovery of the keystream, enabling plaintext decryption of traffic and the extraction of the GHASH authentication key.\nThe impact is total loss of confidentiality and integrity for affected TLS/DTLS sessions, as attackers can forge authentication tags and manipulate data.\nThis issue is specific to AES-GCM within TLS 1.2 and DTLS 1.2; TLS 1.3, AES-CCM, and non-TLS implementations remain unaffected.\nExploitation is feasible for network-adjacent attackers capable of intercepting and analyzing traffic, requiring no authentication or elevated privileges.",
  "technicalDetails": "The vulnerability resides in the wolfProvider TLS record layer implementation, specifically in the state management of the AES-GCM cryptographic primitive.\nIn standard AES-GCM implementations for TLS 1.2/DTLS 1.2, the 8-byte explicit nonce is intended to be unique for every record to ensure that the initialization vector (IV) is never reused under the same key.\nIn wolfProvider versions before 1.2.2, the implementation initializes the nonce upon the establishment of the TLS write key but fails to implement an incrementing mechanism for subsequent record transmissions.\nBecause the key remains static throughout the lifetime of the TLS session, the reuse of the identical nonce results in a catastrophic cryptographic failure known as 'nonce misuse'.\nThe attack flow proceeds as follows: 1) An attacker intercepts multiple TLS/DTLS records transmitted by a vulnerable wolfProvider instance. 2) Due to the nonce reuse, the XOR of two ciphertexts C1 and C2 results in the XOR of the underlying plaintexts P1 and P2 (C1 ^ C2 = P1 ^ P2).\nIf the content of one record is known or guessed (which is common in structured protocol headers), an attacker can easily recover the keystream, leading to the full decryption of the corresponding session data.\nFurthermore, the reuse of the nonce in GCM mode allows an attacker to derive the internal GHASH authentication key (H). Once the GHASH key is recovered, the attacker can generate valid authentication tags for arbitrary payloads.\nThis capability permits the injection of malicious data into the TLS stream, as the attacker can forge the Message Authentication Code (MAC) required by the protocol to validate record integrity.\nThe vulnerability is restricted to the wolfProvider library itself and only impacts TLS 1.2 and DTLS 1.2 sessions utilizing AES-GCM. AES-CCM and TLS 1.3 are not affected due to the different nonce derivation mechanisms employed by the TLS 1.3 protocol standards, which do not rely on the same explicit nonce management logic.\nSuccessful exploitation requires only the ability to passively or actively observe network traffic, making it a significant risk for any service utilizing wolfProvider for secure communication."
}