CVE-2026-94418 in wolfSSL
Summary
by MITRE • 09/27/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability described involves a critical logic error within the wolfSSL library when compiled with the WOLFSSL_SMALL_CERT_VERIFY flag enabled. This optimization feature is designed to reduce peak memory usage by separating certificate parsing from signature verification, processing them in distinct steps before merging results. However, the implementation contains a flaw where the result of the signature check is only merged into the final status if the initial parse operation returns zero success. Consequently, any error encountered during the parsing phase masks the outcome of the signature validation. This architectural decision inadvertently creates a scenario where invalid signatures can be overlooked under specific conditions, fundamentally undermining the integrity checks that are central to Public Key Infrastructure trust models.
The technical flaw is further exacerbated by the ordering of verification steps within the library's internal functions. Specifically, the function ProcessPeerCertParse() performs signature confirmation before validating date constraints and name restrictions in certain code paths due to the split implementation. This inversion of precedence disrupts the intended policy where overriding date errors might be considered acceptable in some contexts but should never override cryptographic validity failures. As a result, the specific error code ASN_SIG_CONFIRM_E is suppressed when parsing issues occur, preventing applications from correctly identifying that a certificate's signature could not be verified against its public key. This suppression allows forged certificates to pass verification checks if they also contain minor parse anomalies or are processed in a way that triggers this masking behavior.
From an operational security perspective, the impact of this vulnerability is severe as it enables man-in-the-middle attacks without requiring compromise of any Certificate Authority keys. An attacker can construct a self-signed certificate that mimics the expected subject name and uses the trusted CA's subject as its issuer field to bypass identity checks. By placing arbitrary bytes in the signature field and ensuring the validity window falls within acceptable ranges or exploiting the date override logic, an attacker can present this forged certificate during TLS handshakes. Since the library fails to properly reject invalid signatures due to the aforementioned parsing interaction, the connection may be established with a malicious party who possesses only their own private key, not the CA's. This affects both TLS 1.2 and TLS 1.3 connections in client and server roles, as well as DTLS implementations that utilize similar verification logic.
The exploitability of this vulnerability is contingent upon specific build configurations and application-level settings. The WOLFSSL_SMALL_CERT_VERIFY flag must be explicitly defined during compilation, which is not the default behavior nor enabled by standard distribution or all-features presets. It is primarily accessible through low-resource optimization flags such as --enable-lowresource in autotools builds or via user_settings_embedded.h headers setting WC_CFG_SMALL_CERT_VERIFY to 1. Furthermore, many applications install custom verify callbacks using wolfSSL_CTX_set_verify() that explicitly allow connections despite date errors by returning success for ASN_BEFORE_DATE_E or ASN_AFTER_DATE_E error codes. When such a callback is present alongside the vulnerable library build, the masking of signature failures becomes fully exploitable. Applications without these specific callbacks or those that strictly enforce all verification steps remain protected against this particular attack vector.
Mitigation strategies require both infrastructure and application-level changes. The most effective remediation is to disable the WOLFSSL_SMALL_CERT_VERIFY optimization flag during compilation unless memory constraints are absolutely critical, as doing so restores the standard sequential verification order where signature validity is confirmed before other checks. For applications that must retain this optimization for resource reasons, it is imperative to ensure that verify callbacks do not override cryptographic errors and strictly enforce ASN_SIG_CONFIRM_E failures. Additionally, because forged certificates may be cached in the WOLFSSL_CTX certificate manager if accepted by a permissive callback, simply reconnecting after detecting an attack is insufficient; administrators must restart the application process or explicitly clear the context's cache to prevent reuse of the malicious state. Regular updates to wolfSSL should also be prioritized as patches likely address this logic inversion and error masking issue.
This vulnerability aligns with CWE-20 Improper Input Validation, specifically regarding the failure to validate cryptographic signatures correctly due to conditional logic errors in processing pipelines. It also relates to CWE-697 Incorrect Comparison, where the merging of verification results fails to account for all possible return codes from intermediate steps. In terms of MITRE ATT&CK, this flaw facilitates T1078 Valid Accounts or more accurately T1484 Domain Policy Modification if viewed as a bypass of trust policies, but primarily it represents a failure in authentication mechanisms that could be categorized under TA0001 Initial Access via exploitation of software vulnerabilities. The combination of weak input validation and improper error handling creates an environment where attackers can impersonate trusted entities without detection by standard TLS verification routines.