CVE-2026-81019High· 7.4▾ TwilightwolfProvider 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 …
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 40.7 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.4%
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.
wolfprovider < 1.2.2Upgrade past the affected range:
wolfprovider 1.2.2Connected by shared product, vendor, weakness, or advisory.
CVE-2026-81341Medium· 6.5wolfEngine 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
CVE-2026-81020High· 7.4wolfEngine 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
CVE-2026-93304Medium· 6.3A (D)TLS 1.2 client can accept a ChangeCipherSpec message before it has sent its ClientKeyExchange
CVE-2026-93302High· 8.3MatchTrustedPeer ignores the public key used, leading to forged CA clones passing verification
CVE-2026-89134Medium· 6.3A certificate with no dNSName SAN but another SAN type present (e.g
CVE-2026-89136High· 8.3When using RPK (Raw Public Key), the client side of a TLS 1.2, 1.3 and DTLS 1.2 connection could accept an unsolicited server_cert_type=RawPublicKey which allowed a malicious or misbehaving server to bypass authentication