CVE-2026-81019

wolfProvider before 1.2.2 generates the 8-byte explicit AES-GCM nonce only once when the TLS write key is set and never increments it per record, so every TLS 1.2 and DTLS 1.2 AES-GCM record in a connection is encrypted under the same key and nonce pair. The flaw is triggered in any application that uses wolfProvider as its OpenSSL 3.x cryptographic provider while negotiating AES-GCM cipher suites in TLS 1.2 or DTLS 1.2; AES-CCM, TLS 1.3, and non-TLS uses of the cipher are not affected. Because GCM with a repeated key/nonce pair reuses the keystream, a network observer can XOR two ciphertext records to get the XOR of their plaintexts, so one known or predictable record exposes the others, and the reuse also leaks the GHASH authentication key, enabling forged authentication tags. An attacker gains decryption of AES-GCM TLS 1.2/DTLS 1.2 record traffic and the ability to forge authenticated records, with the high attack-complexity rating reflecting the need for suitable known plaintext and per-connection conditions. No public proof-of-concept or in-the-wild exploitation is known, and EPSS estimates only about a 0.2% probability of exploitation within 30 days.

What to do: Upgrade to wolfProvider 1.2.2 or later. If upgrading is not immediately possible, disable AES-GCM cipher suites for TLS 1.2/DTLS 1.2 in configurations that use wolfProvider and prefer TLS 1.3 or AES-CCM suites instead. Audit your builds to confirm whether OpenSSL 3.x is configured with the wolfProvider provider, since stock OpenSSL deployments are not affected.