wolfSSL CVE-2026-6329

Exploitation requires that the target application uses wolfSSL's PKCS#12 MAC verification code path and accepts PKCS#12 input from an attacker-controlled or untrusted source. The attacker must be able to deliver a crafted PKCS#12 file - specifically one where the MAC length field embedded in the parsed structure has been set to zero or a truncated value - to the wolfSSL-based parser. The CVSS 4.0 AT:P metric explicitly confirms a specific attack condition is required. Exploitation is further limited by PR:L, indicating some form of access or delivery mechanism (e.g., an authenticated upload endpoint, a provisioning API, or a network-accessible certificate import function) must be available to the attacker. Deployments that process only internally generated PKCS#12 files from trusted sources, or that do not use wolfSSL's PKCS#12 functionality at all, are not exposed. The vulnerability does not affect the TLS handshake path itself, only the PKCS#12 key-store integrity check.

The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N, score 6.0) reflects a moderate finding with high integrity impact confined to the vulnerable system. AT:P (Attack Requirements: Present) acknowledges that exploitation depends on the attacker controlling the PKCS#12 input - not every wolfSSL deployment exposes PKCS#12 import from external sources. PR:L indicates some level of access or delivery mechanism is required; unauthenticated exploitation cannot be confirmed from available data. No CISA KEV listing and no public PoC have been identified, significantly lowering practical urgency relative to the VI:H signal alone. EPSS data was not provided, so exploitation probability cannot be quantified. The real-world risk is most acute for IoT provisioning pipelines, enterprise PKI import workflows, and VPN gateways that ingest PKCS#12 bundles from external parties; environments processing only internally-generated PKCS#12 files face minimal exposure. There is no confidentiality or availability impact per the CVSS vector, making this a pure integrity bypass.

An attacker with the ability to supply a PKCS#12 file to a wolfSSL-based service - such as a certificate import API or VPN client provisioning endpoint - crafts a structurally valid PKCS#12 bundle with an arbitrary or modified certificate chain, sets the embedded MAC value to an all-zero or empty byte sequence, and sets the MAC length field in the structure to zero. When wolfSSL processes this file, the HMAC comparison operates over zero bytes and trivially succeeds, causing the tampered bundle to be accepted as integrity-verified and its contents trusted by the application. No public PoC has been identified, but the forgery technique is mechanically straightforward given the description and the zero-length tag test case added in PR #10192.