CVE-2026-81020

wolfEngine before 1.4.1 generates its 8-byte explicit AES-GCM nonce 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 within a connection is encrypted under an identical key and nonce pair. Any application that uses the engine to run TLS 1.2 or DTLS 1.2 with AES-GCM cipher suites triggers the flaw automatically on every record sent, with no attacker interaction beyond observing the traffic. An attacker who captures records can XOR two ciphertexts to obtain the XOR of their plaintexts, so knowledge of any one record exposes others, and the leaked GHASH authentication key enables forgery of authentication tags on records under the same key. Users of wolfEngine with TLS 1.2 or DTLS 1.2 AES-GCM sessions are affected, while TLS 1.3, AES-CCM, and non-TLS uses of the cipher are not. There is no public proof of concept, no KEV entry, and no reported exploitation, with EPSS estimating a 0.2% probability of exploitation in the next 30 days.

What to do: Upgrade to wolfEngine 1.4.1 or later and restart affected applications so the patched engine is actually loaded, then re-establish long-lived TLS 1.2/DTLS 1.2 connections, since records already sent under the reused nonce remain exposed to anyone who captured them. As a mitigation until patched, prefer TLS 1.3 or AES-CCM cipher suites and disable TLS 1.2/DTLS 1.2 AES-GCM suites. Audit which services link against wolfEngine and confirm which TLS versions and cipher suites they negotiate.