CVE-2026-81019: wolfProvider AES-GCM Nonce Reuse Vulnerability

CVE-2026-81019 Overview

CVE-2026-81019 is a cryptographic flaw in wolfProvider versions before 1.2.2. The library generates the 8-byte explicit AES-GCM nonce a single time when the TLS write key is set. It never increments the nonce per record. Every TLS 1.2 and DTLS 1.2 AES-GCM record within a connection is therefore encrypted under an identical key and nonce pair. This violates the fundamental AES-GCM security requirement that a (key, nonce) pair must never repeat. The flaw is tracked under [CWE-323] (Reusing a Nonce, Key Pair in Encryption).

Critical Impact
Reusing a GCM key and nonce discloses the keystream and leaks the GHASH authentication key, enabling plaintext recovery and authentication tag forgery against TLS 1.2 and DTLS 1.2 sessions.

Affected Products

wolfProvider versions prior to 1.2.2
TLS 1.2 sessions using AES-GCM cipher suites via wolfProvider
DTLS 1.2 sessions using AES-GCM cipher suites via wolfProvider

Discovery Timeline

2026-08-28 - CVE-2026-81019 published to the National Vulnerability Database
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-81019

Vulnerability Analysis

AES-GCM (Galois/Counter Mode) requires that each record within a session use a unique nonce paired with the encryption key. TLS 1.2 constructs the 12-byte GCM nonce from a 4-byte implicit salt derived during key exchange and an 8-byte explicit portion transmitted per record. The explicit portion must vary for every record, typically implemented as a monotonically increasing counter.

wolfProvider generates the 8-byte explicit nonce only once when the write key is installed. Subsequent records reuse the same explicit value, producing an identical (key, nonce) pair across every AES-GCM record in the connection. AES-CCM cipher suites, TLS 1.3 sessions, and non-TLS uses of the AES-GCM cipher through wolfProvider are not impacted.

Root Cause

The defect lies in the initialization path for the TLS write key inside wolfProvider. The explicit nonce field is populated at key-setup time and is not incremented, randomized, or otherwise updated before each Seal operation. The counter update logic mandated by RFC 5288 for TLS 1.2 AES-GCM is absent.

Attack Vector

A network attacker who can passively capture two or more AES-GCM records from an affected TLS 1.2 or DTLS 1.2 connection can exploit the reuse. Because both ciphertexts share the same keystream, XORing them yields the XOR of the underlying plaintexts. Any known or predictable plaintext (HTTP headers, protocol banners, static content) allows recovery of the other plaintexts.

The reuse also permits recovery of the GHASH authentication subkey H using standard forbidden-attack techniques published against AES-GCM nonce reuse. Once H is recovered, an active attacker can forge authentication tags for injected ciphertext, breaking record integrity in addition to confidentiality. The vulnerability requires the attacker to observe live traffic, so exploitation complexity is rated as high.

No verified public exploit code is available. See the WolfSSL Security Vulnerabilities page for vendor-published technical details.

Detection Methods for CVE-2026-81019

Indicators of Compromise

Repeated 8-byte explicit nonce values observed in the GenericAEAD record layer across successive TLS 1.2 or DTLS 1.2 records within the same connection.
Presence of wolfProvider builds earlier than 1.2.2 linked against OpenSSL-compatible applications terminating TLS 1.2 or DTLS 1.2.
Unexpected TLS 1.2 record forgeries or decryption anomalies logged by peers connected to services backed by wolfProvider.

Detection Strategies

Inventory hosts and container images for wolfProvider shared objects and verify the reported version against 1.2.2 or later.
Capture packet samples from services using wolfProvider and inspect the first 8 bytes of the TLS 1.2 AES-GCM record payload for repetition across records in a single session.
Audit build manifests and software bills of materials (SBOMs) for the wolfProvider component to identify vulnerable dependency versions.

Monitoring Recommendations

Alert on TLS 1.2 or DTLS 1.2 negotiations from wolfProvider-backed services when TLS 1.3 is available and expected.
Enable full packet capture on interfaces terminating wolfProvider TLS to support retrospective cryptographic analysis.
Track process and library load events for wolfProvider modules to detect vulnerable versions in runtime environments.

How to Mitigate CVE-2026-81019

Immediate Actions Required

Upgrade wolfProvider to version 1.2.2 or later on all hosts, containers, and appliances.
Restart services that dynamically load the wolfProvider library so the patched code path takes effect.
Rotate long-lived TLS server keys and session tickets used with vulnerable wolfProvider builds, since captured traffic may have been decrypted.

Patch Information

wolfSSL addresses CVE-2026-81019 in wolfProvider 1.2.2. The fix restores per-record nonce increment semantics for TLS 1.2 and DTLS 1.2 AES-GCM cipher suites, complying with RFC 5288. Refer to the WolfSSL Security Vulnerabilities page for release notes and patch details.

Workarounds

Disable TLS 1.2 and DTLS 1.2 AES-GCM cipher suites and require TLS 1.3 for affected services until the upgrade is deployed.
Prefer AES-CCM cipher suites for TLS 1.2 traffic where TLS 1.3 cannot be enforced, since AES-CCM is not affected.
Terminate TLS at an unaffected proxy or load balancer positioned in front of services that still rely on vulnerable wolfProvider builds.

bash

# Verify installed wolfProvider version and enforce TLS 1.3 as a temporary control
openssl list -providers | grep -i wolf

# Example: restrict an OpenSSL-based service to TLS 1.3 in openssl.cnf
# [system_default_sect]
# MinProtocol = TLSv1.3
# CipherSuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256