CVE-2026-94418
Received Received - Intake

Certificate Validation Bypass in wolfSSL

Publication date: 2026-09-27

Last updated on: 2026-09-27

Assigner: wolfSSL Inc.

Description
Under WOLFSSL_SMALL_CERT_VERIFY, ProcessPeerCertParse() runs the certificate signature check separately from the parse to keep peak memory down, then merges the two results, but it merged the signature result back only when the parse returned 0, so any parse error hid it. ParseCertRelative() reaches its validity-date, name-constraint and critical-extension checks only after ConfirmSignature() has passed, so splitting the signature check out inverts the precedence that makes "override date errors" a sound policy, and ASN_SIG_CONFIRM_E is never surfaced anywhere. The attacker needs no key material from the real PKI and no CA compromise: a self-made certificate carrying the expected subject name, the trusted CA's subject as its issuer, arbitrary bytes where the signature goes, a validity window in the past and the attacker's own key pair is sufficient. Affected builds define WOLFSSL_SMALL_CERT_VERIFY, which is off by default, is not set implicitly by any platform or preset header, and is not reachable from any CMake option; the autotools routes are --enable-lowresource, --enable-leantls, --enable-tinytls13=cert and --enable-tinytls13=mutualauth, and examples/configs/user_settings_embedded.h reaches it through WC_CFG_SMALL_CERT_VERIFY, which ships as 0, while neither --enable-all nor --enable-distro enables it at all. The application must additionally install a verify callback through wolfSSL_CTX_set_verify() or wolfSSL_set_verify() with WOLFSSL_VERIFY_PEER that returns 1 for ASN_BEFORE_DATE_E or ASN_AFTER_DATE_E; wolfSSL ships this exact shape as myVerify() in wolfssl/test.h under VERIFY_OVERRIDE_DATE_ERR, which examples/client -D selects. An application with no callback, or whose callback returns preverify for date errors, still fails the handshake, and wolfSSL_CertManagerVerifyBuffer() and wc_CheckCertSignature() report ASN_SIG_CONFIRM_E correctly in the same binary. TLS 1.2 and TLS 1.3 are affected in both directions, and DTLS reaches the same function; where the forged certificate is a chain certificate the callback's consent causes it to be cached in the WOLFSSL_CTX certificate manager, so an exposed deployment must restart the context or the process rather than merely reconnect.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-09-27
Last Modified
2026-09-27
Generated
2026-09-27
AI Q&A
2026-09-27
EPSS Evaluated
N/A
NVD
CVE-2026-94418
EUVD
EUVD-2026-87907

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
wolfssl wolfssl to 0 (exc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-347 The product does not verify, or incorrectly verifies, the cryptographic signature for data.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability involves a logic flaw in wolfSSL's certificate verification when WOLFSSL_SMALL_CERT_VERIFY is enabled. The function ProcessPeerCertParse() checks the certificate signature separately from parsing but only merges the signature result if parsing succeeds. This means parse errors can hide signature failures. The attacker can exploit this by creating a self-signed certificate with a trusted CA's subject, arbitrary signature bytes, and a past validity window. The application must have a verify callback that overrides date errors for the attack to succeed.

Affected builds require WOLFSSL_SMALL_CERT_VERIFY to be explicitly enabled via specific autotools options or user_settings_embedded.h. TLS 1.2, TLS 1.3, and DTLS are all affected.

Detection Guidance

This vulnerability is specific to wolfSSL builds with WOLFSSL_SMALL_CERT_VERIFY enabled, which is not default. Detection requires checking if your wolfSSL build includes this feature. Examine your wolfSSL configuration and compilation flags for --enable-lowresource, --enable-leantls, --enable-tinytls13=cert, --enable-tinytls13=mutualauth, or WC_CFG_SMALL_CERT_VERIFY set to 1.

Impact Analysis

An attacker could bypass certificate validation, allowing man-in-the-middle attacks or unauthorized access to sensitive data. If your application uses wolfSSL with WOLFSSL_SMALL_CERT_VERIFY enabled and a verify callback that overrides date errors, you are vulnerable. Systems without the callback or with default settings are not affected.

Compliance Impact

The vulnerability allows an attacker to bypass certificate validation checks, including date validity and critical extensions, by crafting a self-signed certificate with a past validity window and arbitrary signature bytes. This could lead to unauthorized access or data exposure, potentially violating compliance requirements for secure communications under standards like GDPR and HIPAA.

Mitigation Strategies

Disable WOLFSSL_SMALL_CERT_VERIFY if enabled. Ensure no applications use the verify callback pattern that overrides date errors (e.g., myVerify() in wolfssl/test.h). Restart affected contexts or processes if a forged certificate was cached. Verify that wolfSSL_CertManagerVerifyBuffer() and wc_CheckCertSignature() report ASN_SIG_CONFIRM_E correctly.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-94418. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart