CVE-2026-94418

Executive Summary

CVE-2026-94418 is a certificate-signature-verification bypass in wolfSSL that occurs only in builds compiled with the WOLFSSL_SMALL_CERT_VERIFY option, a non-default, low-resource certificate parsing mode. In affected builds, ProcessPeerCertParse() runs the certificate signature check separately from the parse and merges the results incorrectly, so a parse error silently suppresses the signature verification result, and ASN_SIG_CONFIRM_E — the signature-confirmation failure code — is never surfaced to the application. An attacker who controls no key material from the real PKI can present a forged certificate with an arbitrary (invalid) signature, the expected subject name, and the trusted CA's subject as issuer, and still have the certificate accepted by an application that installs a WOLFSSL_VERIFY_PEER verify callback returning 1 for ASN_SIG_CONFIRM_E. Because the mode is opt-in and off by default, exposure is limited to embedded/low-resource deployments that deliberately enable it; however, for those deployments the impact is complete loss of trust in chain-of-trust validation: TLS peers, code-signing certificates, and any certificate used for authentication can be impersonated. The CVSS score is not available from FIRST/NVD (N/A), CISA KEV does not list it, no PoC, exploit code, or Nuclei template is known, and there is no patch evidence.

Technical Analysis

The vulnerability resides in the certificate parsing and verification path of wolfSSL when compiled with WOLFSSL_SMALL_CERT_VERIFY. Under this mode, ProcessPeerCertParse() splits the normal certificate verification process into two phases: (1) parsing the peer certificate (ParseCertRelative()), and (2) separately performing the certificate signature check (ConfirmSignature()) so the two do not have to be held in memory at the same time — an optimization intended to keep peak memory low on constrained devices.

The defect is in the merge step. The signature-check result is merged back into the overall verification result only when the parse returned 0 (success). Consequently, any parse error masks the separately-computed signature result. Combined with the ordering change, the signature check is effectively run before the parse completes, and ParseCertRelative() reaches its validity-date, name-constraint, and critical-extension checks only after ConfirmSignature() has passed. This inverts the precedence that normally makes an "override date errors" policy sound, because the policy assumes a valid signature gates the later checks. Under WOLFSSL_SMALL_CERT_VERIFY, a certificate whose signature fails confirmation can still be evaluated down the parse path, and ASN_SIG_CONFIRM_E (the specific error reserved for signature-confirmation failure) is never propagated to the caller at all.

The practical consequence is a signature-verification bypass (CWE-347, Improper Verification of Cryptographic Signature): certificate authenticity is no longer enforced by the library in this mode. An attacker does not need any private key belonging to the real PKI and does not need to compromise a CA. The NVD description states that a self-made certificate is sufficient: it must carry the expected subject name, use the trusted CA's subject as its issuer, contain arbitrary bytes where the signature would go, specify a validity window in the past, and be accompanied by the attacker's own key pair. In other words, the attacker manufactures a certificate that looks correctly issued (subject/issuer relationship) but is cryptographically unsigned by the real CA, and the library fails to reject it because the signature failure is swallowed and ASN_SIG_CONFIRM_E is not delivered.

Reachability is constrained by configuration, not by exposure on the public internet per se. WOLFSSL_SMALL_CERT_VERIFY is off by default, is not implicitly enabled by any platform or preset header, and is not reachable from any CMake option. It can only be enabled through the Autotools configure routes --enable-lowresource, --enable-leantls, --enable-tinytls13=cert, and --enable-tinytls13=mutualauth. It can also be reached via examples/configs/user_settings_embedded.h through WC_CFG_SMALL_CERT_VERIFY, which ships as 0. Neither --enable-all nor --enable-distro enables it. Finally, exploitation requires the application to install a verify callback via wolfSSL_CTX_set_verify() or wolfSSL_set_verify() with WOLFSSL_VERIFY_PEER that returns 1 for ASN_SIG_CONFIRM_E (the NVD text is truncated at this point, so the exact callback behavior is only partially described).

Because the CNA title is empty and the NVD description is the sole source, no source-level line numbers, additional function names, or upstream commit references can be provided. The analysis above is limited to the identifiers present in the NVD description: WOLFSSL_SMALL_CERT_VERIFY, ProcessPeerCertParse(), ParseCertRelative(), ConfirmSignature(), ASN_SIG_CONFIRM_E, wolfSSL_CTX_set_verify(), wolfSSL_set_verify(), and WOLFSSL_VERIFY_PEER.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template exists for CVE-2026-94418; the chain below is inferred strictly from the vulnerability class (improper signature verification) and the NVD description.

1. Reconnaissance and target identification. The attacker must locate a target that (a) runs a wolfSSL build compiled with WOLFSSL_SMALL_CERT_VERIFY (enableable only via --enable-lowresource, --enable-leantls, --enable-tinytls13=cert, --enable-tinytls13=mutualauth, or a build that modified examples/configs/user_settings_embedded.h to set WC_CFG_SMALL_CERT_VERIFY nonzero), and (b) hosts an application that installs a verify callback through wolfSSL_CTX_set_verify() or wolfSSL_set_verify() using WOLFSSL_VERIFY_PEER and returns 1 for ASN_SIG_CONFIRM_E. Targets of interest are embedded, IoT, and resource-constrained network appliances that advertise wolfSSL or that use the low-resource/lean-TLS profiles. Reconnaissance is passive (banner grabbing, TLS fingerprinting, firmware extraction, or embedded-device scanning) since the vulnerability class has no unique network signature.

2. Crafting the forged certificate. The attacker generates their own key pair and builds a certificate that satisfies the checks the library will still perform:

   • the expected subject name of the legitimate service (so name-based checks or hostname binding pass),
   • the trusted CA's subject as the certificate's issuer (so issuer/subject chaining appears valid),
   • arbitrary bytes in the signature field — no valid signature from the real CA is produced,
   • a validity window in the past (the description notes a past validity window; because ParseCertRelative() reaches the validity-date check only after ConfirmSignature() passes, and the signature failure is hidden, the date-error policy is inverted and the stale window is not enforced as intended).

   No CA private key and no key material from the real PKI are required.

3. Triggering the flaw. The attacker presents the forged certificate during a TLS handshake (or any certificate-based authentication exchange) to the vulnerable service. In the affected build, ProcessPeerCertParse() performs the signature check separately, the parse returns a nonzero error, and the merge logic — which only records the signature result when parse returns 0 — discards the ConfirmSignature() failure. ASN_SIG_CONFIRM_E is never surfaced, so the application's verify callback (if it returns 1 for that code) accepts the certificate instead of rejecting it. There is no cryptographic barrier to overcome; the bypass is a logic flaw in result aggregation.

4. Post-exploitation impact. Successful acceptance of the forged certificate enables impersonation of the legitimate peer/server, interception and decryption of protected traffic, and unauthorized access to any interface gated by certificate authentication (including mutual-auth configurations reachable via --enable-tinytls13=mutualauth). Because the attacker controls the key pair associated with the forged certificate, they can also sign subsequent handshakes as that identity, extending the attack beyond a single session. No privilege-escalation code execution is described by the source; the impact is confidentiality and integrity of certificate-protected communications.

Impact Assessment

CVSS score is N/A (not assigned by NVD/FIRST at time of writing), and this report does not substitute a fabricated score. For scoping, the vulnerability's characteristics are: network-reachable where the vulnerable TLS endpoint is exposed (AV:N), high attack complexity because the target must be built with a non-default option and must install a specific verify callback (AC:H), no privileges or user interaction required (PR:N/UI:N), scope unchanged (S:U), and high confidentiality and integrity impact (C:H/I:H) since certificate trust is fully bypassed. Availability impact is not indicated by the description (A:N).

Affected systems. Only wolfSSL builds compiled with WOLFSSL_SMALL_CERT_VERIFY: Autotools builds using --enable-lowresource, --enable-leantls, --enable-tinytls13=cert, or --enable-tinytls13=mutualauth; builds derived from examples/configs/user_settings_embedded.h with WC_CFG_SMALL_CERT_VERIFY changed from its shipped value of 0; and any downstream product that vendors such a configuration. Default builds, --enable-all, --enable-distro builds, and CMake-based builds are not vulnerable because the option is off by default, is not implicitly set by any platform/preset header, and has no CMake route.

Blast radius. For embedded and low-resource deployments that rely on this mode, the blast radius is any trust decision made through the wolfSSL certificate verification path: TLS server authentication, mutual TLS client authentication, and certificate-based device identity. Trust anchors are effectively unenforced for signature validity, meaning impersonation is possible against every peer the vulnerable service accepts. Because enabling the mode is a deliberate, low-resource design choice, the population is narrow but concentrated in constrainted, often long-lived, hard-to-update environments — a combination that raises the operational severity even though there is no evidence of in-the-wild exploitation, no KEV listing, and no public PoC.

Detection Guidance

Because CVE-2026-94418 is a logic/verification flaw rather than a memory-safety bug, network and host detection must focus on certificate anomalies (self-made certificates, invalid signature fields, past validity windows) presented to wolfSSL-backed endpoints, and on the configuration state of the library. The rules below are templates; tune the certificate fields and log sources to your environment. There are no public IoCs, exploit signatures, or vendor detection artifacts for this CVE.

Sigma Rule

title: Suspicious TLS Certificate Verification Bypass Attempt Against wolfSSL (CVE-2026-94418)
id: 3f9c1c2e-7a2b-4d5e-9c1a-2026wolf94418
status: experimental
description: Detects presentation of certificates with invalid/placeholder signatures, mismatched issuer-subject chains, or past validity windows against wolfSSL endpoints possibly affected by CVE-2026-94418.
logsource:
  category: application
  product: wolfssl
detection:
  selection_sig_fail:
    EventID: 0
    Message|contains:
      - 'ASN_SIG_CONFIRM_E'
      - 'ConfirmSignature'
      - 'certificate signature'
  selection_cert_anomaly:
    Message|contains|all:
      - 'ProcessPeerCertParse'
      - 'error'
  condition: selection_sig_fail or selection_cert_anomaly
falsepositives:
  - Legitimate expired certificates presented by misconfigured clients (would normally be rejected)
  - Applications that intentionally log parse errors for non-trusted peers
level: high
tags:
  - attack.t1190
  - cve.2026-94418

YARA Rule

rule CVE_2026_94418_wolfSSL_SMALL_CERT_VERIFY
{
    meta:
        description = "Detects wolfSSL builds/libraries compiled with WOLFSSL_SMALL_CERT_VERIFY, the precondition for CVE-2026-94418"
        cve = "CVE-2026-94418"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-94418"
        author = "valtersit.com threat intelligence"
    strings:
        $cfg1 = "WOLFSSL_SMALL_CERT_VERIFY" ascii
        $cfg2 = "WC_CFG_SMALL_CERT_VERIFY" ascii
        $fn1  = "ProcessPeerCertParse" ascii
        $fn2  = "ParseCertRelative" ascii
        $fn3  = "ConfirmSignature" ascii
        $err  = "ASN_SIG_CONFIRM_E" ascii
    condition:
        ($cfg1 or $cfg2) and 2 of ($fn*)
}

Suricata IDS Rule

alert tls any any -> any any (msg:"CVE-2026-94418 Attempted wolfSSL Certificate Signature Verification Bypass (invalid signature / past validity)"; flow:established,to_server; tls.cert_validity:expired; tls.store; classtype:attempted-recon; reference:cve,2026-94418; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-94418; sid:202694418; rev:1;)

Elastic Detection

// Detect TLS certificate validation failures/anomalies reported by wolfSSL-backed services,
// which may indicate CVE-2026-94418 signature-verification bypass attempts.
sequence by host.id, process.pid with maxspan=30s
  [ any where event.category == "network" and
        tls.server.certificate and
        (tls.server.certificate_not_valid_before > "@timestamp" or
         tls.server.certificate_not_valid_after < "@timestamp") ]
  [ any where event.category == "process" and
        process.name : ("*wolfssl*", "*wolfcrypt*") and
        message : ("ConfirmSignature", "ASN_SIG_CONFIRM_E", "ParseCertRelative", "ProcessPeerCertParse") ]

Splunk SPL Query

index=* (sourcetype=wolfssl:log OR sourcetype=syslog OR sourcetype=tls_proxy)
( "ProcessPeerCertParse" OR "ParseCertRelative" OR "ConfirmSignature" OR "ASN_SIG_CONFIRM_E" OR "WOLFSSL_SMALL_CERT_VERIFY" )
| eval risk=case(match(_raw,"ASN_SIG_CONFIRM_E"),"high",
                 match(_raw,"ConfirmSignature"),"high",
                 match(_raw,"WOLFSSL_SMALL_CERT_VERIFY"),"medium",true(),"low")
| stats count min(_time) as first_seen max(_time) as last_seen by host, source, risk
| where risk!="low"
| sort - last_seen

Wazuh OSSEC Rule

<group name="wolfssl,cve-2026-94418,">
  <rule id="100018" level="12">
    <decoded_as>syslog</decoded_as>
    <match>ASN_SIG_CONFIRM_E|ConfirmSignature|ProcessPeerCertParse|ParseCertRelative</match>
    <description>CVE-2026-94418: Possible wolfSSL certificate signature verification bypass in WOLFSSL_SMALL_CERT_VERIFY builds</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>certificate_verification,tls,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). There is no vendor fix, workaround, or affected-version list in the supplied intelligence, and no fixed version is available. The following are configuration and hardening measures, not patches.

1) Immediate mitigations

• Disable the vulnerable build option. Rebuild wolfSSL without WOLFSSL_SMALL_CERT_VERIFY. Confirm that none of --enable-lowresource, --enable-leantls, --enable-tinytls13=cert, or --enable-tinytls13=mutualauth is present in the configure invocation, and that examples/configs/user_settings_embedded.h still ships WC_CFG_SMALL_CERT_VERIFY as 0 (do not set it nonzero). Default, --enable-all, --enable-distro, and CMake builds are already unaffected.
• Harden verify callbacks. Review any application verify callback installed via wolfSSL_CTX_set_verify() or wolfSSL_set_verify(). Do not return success for ASN_SIG_CONFIRM_E; treat it and other signature/parse errors as hard failures. Note: the NVD text is truncated at the callback description, so the exact callback semantics must be verified against the code in use.
• Enforce strict validation in the application. Where the application controls certificate policy, independently require signature validity, chain of trust, and a non-expired validity window, so a library-level merge bug cannot silently accept a forged certificate.

2) Patch/upgrade steps

• No patched version is identified. Track wolfSSL upstream advisories and releases, and monitor NVD (CVE-2026-94418) for a fixed release or commit. Once available, upgrade immediately and re-verify that the vulnerable option remains disabled.
• After any upgrade, confirm the merge of parse and signature results in the certificate path correctly surfaces ASN_SIG_CONFIRM_E, since that is the observable behavior this CVE concerns.

3) Long-term hardening

• Remove WOLFSSL_SMALL_CERT_VERIFY from any product firmware build matrix or CI configuration unless a formal risk acceptance exists; treat low-resource profiles as security-relevant configuration.
• Adopt certificate pinning or a secondary trust decision (e.g., mutual TLS with an independent trust anchor, hardware-backed device identity) for high-value embedded endpoints.
• Add continuous monitoring for WOLFSSL_SMALL_CERT_VERIFY / WC_CFG_SMALL_CERT_VERIFY in build manifests and firmware SBOMs, and include wolfSSL build flags in SBOM/vulnerability-management coverage.
• Inventory embedded/IoT and network appliances that vendor wolfSSL with low-resource profiles, since these are the only configurations at risk.

References

• NVD — CVE-2026-94418: https://nvd.nist.gov/vuln/detail/CVE-2026-94418
• CWE-347 — Improper Verification of Cryptographic Signature: https://cwe.mitre.org/data/definitions/347.html
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• wolfSSL project (upstream release/advisory channel to monitor for a fix): https://www.wolfssl.com/
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-94418 not listed at time of writing): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No public PoC, exploit code, Nuclei template, or threat-actor campaign is associated with CVE-2026-94418 in the available data; FIRST EPSS has not yet scored it, and CISA KEV does not list it.