CVE-2026-94417

Executive Summary

CVE-2026-94417 is a certificate revocation bypass in the wolfSSL embedded TLS library (CWE-299: Improper Check for Certificate Revocation). When an application enables both OCSP and CRL revocation checking on a single WOLFSSL_CTX or certificate manager, wolfSSL skips the CRL check for any peer certificate that carries no Authority Information Access (AIA) OCSP URL, and accepts a certificate the loaded CRL lists as revoked. Any build defining both HAVE_OCSP and HAVE_CRL is affected, including many stock --enable-* configurations; exploitation requires the application to enable both OCSP and CRL with a CRL loaded, and is reachable over TLS 1.0–1.3 and DTLS during client or mutual/post-handshake authentication. The impact is complete revocation-checking failure for such certificates, meaning revoked credentials are accepted as valid.

Technical Analysis

wolfSSL supports two independent certificate revocation mechanisms: OCSP (Online Certificate Status Protocol) and CRL (Certificate Revocation List). When an application enables both mechanisms against the same WOLFSSL_CTX or certificate manager, the expectation is that both checks are performed and that a certificate revoked by either mechanism is rejected. CVE-2026-94417 breaks that expectation.

Two interacting defects are described:

1. Missing-responder soft-fail collapses onto success. wolfSSL applies a soft-fail policy when no OCSP responder is available — a common and defensible deployment posture, since network availability of an OCSP responder should not by itself cause a denial of service. The defect is that this soft-fail result is collapsed onto "success" before the code decides whether the CRL fallback is still needed. Consequently, "no responder exists" becomes indistinguishable from "the responder answered good." The result of the OCSP check is effectively latched to a positive outcome, and the CRL path is never consulted.

2. CRL check skipped for certificates without an AIA OCSP URL. Because the OCSP soft-fail path has already reported success, no fallback to CRL is triggered for peer certificates that carry no Authority Information Access OCSP URL. A certificate that the loaded CRL explicitly lists as revoked is therefore accepted.

The defect is located in ProcessPeerCerts() and is reachable over TLS 1.0 through TLS 1.3 and DTLS, both on a client verifying a server certificate and on a server verifying a client certificate under mutual authentication or post-handshake authentication. When the skipped check falls on a chain certificate rather than the leaf, the failure is subtler: a revoked intermediate or issuing CA can be accepted, which undermines the entire chain of trust built on that CA for the lifetime of the connection and beyond (since the certificate continues to be treated as trusted).

Configuration surface (from NVD description). Affected builds define both HAVE_OCSP and HAVE_CRL. This includes explicit configuration via --enable-ocsp --enable-crl, and implicitly through a broad set of aggregate options: --enable-all, --enable-distro, --enable-curl, --enable-nginx, --enable-haproxy, --enable-stunnel, --enable-lighty, --enable-wpas, --enable-strongswan, --enable-mosquitto, --enable-jni, --enable-openvpn, and --enable-krb. The breadth of this list means the vulnerable build class is not exotic — it appears in common TLS server, VPN, messaging, and JNI/JVM integration configurations.

Application-level precondition. A build being vulnerable does not mean every application using it is exploitable. An application is affected only if it calls both wolfSSL_CTX_EnableOCSP() (or wolfSSL_EnableOCSP() / wolfSSL_CertManagerEnableOCSP()) and wolfSSL_CTX_EnableCRL() (or the equivalents) with a CRL loaded. Applications that use OCSP stapling alone through wolfSSL_CTX_EnableOCSPStapling() are not affected, because that path sets up a separate OCSP instance and does not interact with the CRL fallback logic described here.

Limitations of available data. No CVSS score, EPSS score, CISA KEV entry, public PoC, or Nuclei template is available as of this report. No affected version list or OSV package data has been supplied. The technical mechanism above is derived directly from the NVD description; no function names, endpoints, or parameters beyond those in the description have been inferred.

Exploitation Scenarios

No public proof-of-concept exists for CVE-2026-94417. The attack chain is inferred from the vulnerability class (revocation-check bypass via soft-fail misclassification) and the mechanisms described in the NVD entry.

1. Reconnaissance / target identification. An adversary profiles a target service using a wolfSSL-based stack configured with both OCSP and CRL enforcement — for example a TLS endpoint built with --enable-curl, --enable-nginx, or --enable-haproxy, a VPN concentrator (--enable-openvpn, --enable-strongswan), a messaging broker (--enable-mosquitto), or a JVM integration (--enable-jni). The attacker must establish that the endpoint performs both OCSP and CRL checking with a CRL loaded; this is typically inferable from vendor documentation, build flags disclosed in packages, or observed OCSP stapling behavior. A more decisive confirmation is observing acceptance of a certificate whose chain lacks an AIA OCSP URL while the revocation status is negative.

2. Triggering the flaw class. The attacker obtains a certificate that has been revoked — for example, a credential for a compromised host, a key whose private half leaked, or an intermediate that the victim's CRL explicitly lists as revoked — and that carries no Authority Information Access OCSP URL. When this certificate is presented during the TLS or DTLS handshake, wolfSSL evaluates the OCSP path first. Because no responder is reachable (no AIA URL is present, or the responder is absent), the soft-fail policy returns success. That success is recorded before the code evaluates whether CRL fallback is required, so the subsequent CRL check is skipped. The revoked certificate is accepted.

3. Payload / execution method at the vulnerability-class level. No payload is required in the classic memory-corruption sense. The "payload" is the revoked X.509 certificate itself, presented during any handshake that invokes ProcessPeerCerts() — client verifying a server, or server verifying a client under mutual or post-handshake authentication. The attacker simply completes a handshake with the revoked credential; the bypass is silent and leaves no malformed network traffic to inspect. Relevant to chain-level abuse: if the skipped check lands on a revoked intermediate or CA certificate rather than the leaf, every certificate issued under that CA is implicitly trusted by the affected peer for as long as the connection (and any cached trust decision) persists.

4. Post-exploitation impact. With a revoked credential accepted as valid, the attacker gains authenticated access equivalent to a legitimate holder of that certificate. On the client side, this means a client can be induced to trust a revoked server — enabling man-in-the-middle or impersonation of a service the client believes is authenticated. On the server side, a revoked client certificate is accepted, granting unauthorized access to mutual-TLS-protected APIs, VPN sessions, message-broker topics, or other resources gated by client certificates. Because the CRL the operator loaded specifically lists these certificates as revoked, the security control the operator believes is enforced is in fact absent. Chain-level bypass extends the blast radius from a single identity to an entire PKI subtree.

Impact Assessment

The vulnerability is a complete failure of revocation enforcement for a well-defined class of certificates (no AIA OCSP URL, listed in the loaded CRL) on affected configurations. CVSS base score and vector are not available from the data supplied. The subscores used in the metadata vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) are not authoritative — no score has been published; the vector is provided only as a structural placeholder for downstream tooling and must not be treated as an official severity rating.

Business impact:

• Authentication integrity loss. Any system relying on mutual TLS with both OCSP and CRL enabled on wolfSSL may accept revoked client or server certificates. This undermines the central premise of certificate-based authentication: that revocation is honored.
• Blast radius. The affected build class spans common server, VPN, messaging, and JVM-integration profiles. The impact is bounded only by (a) whether the application calls both revocation APIs with a CRL loaded, and (b) whether exploitable certificates without an AIA OCSP URL exist in the deployment's PKI. In environments where CRL is the primary revocation signal and OCSP responders are absent — a common air-gapped or internal-PKI posture — every revoked certificate in that PKI is potentially usable.
• Chain-level amplification. Where the skipped check lands on a revoked CA or intermediate, the impact is not a single identity but the entire subtree issued under that CA, until that CA is removed from trust anchors or a patch is applied.
• Detection difficulty. The bypass produces a normal handshake with a valid-looking certificate; there is no protocol anomaly, malformed packet, or crash to alert on. This places a high burden on log correlation and inventory.

Affected systems: any product or application embedding wolfSSL and built with HAVE_OCSP and HAVE_CRL simultaneously, where the application enables both revocation mechanisms with a CRL loaded. No affected product version list was supplied; operators must audit their own build flags against the list in the NVD description.

Detection Guidance

Detection for this vulnerability is inherently indirect: the flaw produces a successful handshake using a revoked certificate, with no malformed traffic or crash signature. The rules below focus on (a) observable build/library indicators, (b) certificate-level anomalies (revoked certificate presenting without AIA OCSP URL), and (c) correlation of TLS handshakes with assets whose certificates appear in the local CRL.

Sigma Rule

Detects indicator-level conditions (presence of a wolfSSL library built with both OCSP and CRL support) useful for asset exposure assessment. Adjust paths to match distribution packaging.

title: Potential wolfSSL OCSP/CRL Revocation Bypass Build Indicator (CVE-2026-94417)
id: 7f1c9b2e-9441-7cve-9441-7cve9441cve1
status: experimental
description: >
  Detects filesystem indicators of a wolfSSL library configured with both OCSP and CRL
  revocation support, the vulnerable build class for CVE-2026-94417. Presence of this
  indicator does not confirm application-level exploitability (the app must also call
  both wolfSSL_CTX_EnableOCSP and wolfSSL_CTX_EnableCRL with a CRL loaded).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-94417
author: valtersit.com
date: 2026/01/01
tags:
  - attack.defense_evasion
  - attack.t1553
  - cve.2026-94417
logsource:
  category: file_event
  product: linux
detection:
  selection_paths:
    - '/usr/lib/**/libwolfssl.so*'
    - '/usr/local/lib/**/libwolfssl.so*'
    - '/opt/**/libwolfssl.a'
    - '/opt/**/libwolfssl.so*'
  selection_strings:
    - 'HAVE_OCSP'
    - 'HAVE_CRL'
  condition: selection_paths
falsepositives:
  - Any wolfSSL deployment; this rule identifies exposure, not active exploitation.
level: informational

YARA Rule

Detects wolfSSL binaries whose symbol tables or embedded strings indicate both OCSP and CRL configuration, plus references to the affected code path.

rule CVE_2026_94417_wolfSSL_OCSP_CRL_Bypass
{
    meta:
        description = "Detects wolfSSL builds with both OCSP and CRL revocation paths for CVE-2026-94417 exposure assessment"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-94417"
        date = "2026-01-01"
        severity = "informational"

    strings:
        $lib = "wolfSSL" ascii wide
        $ocsp = "wolfSSL_CTX_EnableOCSP" ascii
        $crl  = "wolfSSL_CTX_EnableCRL" ascii
        $proc = "ProcessPeerCerts" ascii
        $cm1  = "wolfSSL_CertManagerEnableOCSP" ascii
        $stapling = "wolfSSL_CTX_EnableOCSPStapling" ascii

    condition:
        $lib and $ocsp and $crl and (uint16(0) == 0x457f or $proc) and filesize > 0
}

Suricata IDS Rule

Because the bypass is protocol-legal, the network rule targets the observable precondition: a revoked certificate identified by serial number appearing as the subject/TLS certificate in a handshake. Operators must maintain a list of revoked serial numbers (from the loaded CRL) in a threshold variable; this rule alerts when such a serial is presented on the wire. This detects the resulting handshake, not the skip itself.

alert tls any any -> any any (msg:"CVE-2026-94417 Possible wolfSSL Revoked-Certificate Acceptance (serial in local CRL)"; flow:established,to_server; tls.store; tls.cert_serial; content:"REVOKED_SERIAL_PLACEHOLDER"; nocase; threshold:type limit, track by_src, count 1, seconds 300; classtype:policy-violation; reference:cve,2026-94417; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-94417; sid:2026944171; rev:1;)

Note: replace REVOKED_SERIAL_PLACEHOLDER with serial numbers extracted from the deployment's CRL. This rule pattern relies on Suricata's TLS certificate (X.509) handling and is intended as a starting point; verify field support against the deployed Suricata version.

Elastic Detection

Detects successful TLS handshakes where the presented certificate's serial number matches an entry in the local CRL, correlated per host — an indirect signal that a revoked credential was accepted.

sequence by host.id with maxspan=5m
  [ process where event.category == "network" and tls.server.certificate_serial != null ]
  [ file where event.category == "file" and file.name in ("*.crl", "*.pem") ]

Because a robust EQL implementation depends on field availability, the above should be adapted: where CRL membership is known out-of-band, replace with a simple condition-based rule:

tls where network.protocol == "tls" and tls.client.server_name in
  ("service-a.example.internal", "vpn.example.internal") and
  tls.server.certificate_serial in ("REVOKED_SERIAL_PLACEHOLDER")

Splunk SPL Query

Correlate successful TLS/SSL handshakes to assets whose client or server certificate appears in the organization's revoked serial list, and surface those with no OCSP AIA extension observed.

index=tls OR index=proxy OR index=zeek sourcetype=bro:ssl OR sourcetype=suricata:tls
| fields _time src_ip dest_ip server_name certificate_serial issuer subject
| lookup revoked_serials.csv certificate_serial OUTPUT revoked status
| where revoked="true"
| stats count min(_time) as first_seen max(_time) as last_seen
        values(server_name) as service values(issuer) as issuer
        by src_ip dest_ip certificate_serial
| sort - count

If OCSP AIA presence is decoded by the sensor, add a filter such as | where isnull(ocsp_aia_url) OR ocsp_aia_url="" to bias toward the exact precondition described by NVD (peer certificate with no AIA OCSP URL).

Wazuh OSSEC Rule

Detects when the wolfSSL library on a host is present in a configuration context indicating both OCSP and CRL enablement, and correlates with an integration log entry from the application indicating dual revocation setup.

<group name="cve_2026_94417,wolfssl,">
  <rule id="100441" level="3">
    <decoded_as>json</decoded_as>
    <field name="cve">CVE-2026-94417</field>
    <description>CVE-2026-94417: wolfSSL OCSP/CRL revocation bypass exposure indicator on $(hostname)</description>
    <options>no_full_log</options>
  </rule>

  <rule id="100442" level="10">
    <decoded_as>json</decoded_as>
    <field name="cve">CVE-2026-94417</field>
    <field name="handshake">success</field>
    <field name="peer_cert_revoked">true</field>
    <description>CVE-2026-94417: successful TLS handshake with a certificate listed as revoked (possible bypass) on $(hostname)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Rule 100442 requires the application or TLS terminator to log both the revocation status of the peer certificate (as determined out-of-band) and the handshake outcome; without that integration, only rule 100441 is operable.

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, workaround, or affected-version list was provided with the intelligence data. The guidance below is based on the mechanism described by NVD and on standard practices for revocation-control failures.

1. Immediate mitigations (do not rely on CRL/OCSP dual enforcement):

   • Audit the application's revocation API calls. Determine whether the application calls both a CRL enablement function (wolfSSL_CTX_EnableCRL() or equivalent) and an OCSP enablement function (wolfSSL_CTX_EnableOCSP() / wolfSSL_EnableOCSP() / wolfSSL_CertManagerEnableOCSP()) against the same context or manager. Applications using OCSP stapling alone via wolfSSL_CTX_EnableOCSPStapling() are not affected; leave those unchanged.
   • Apply revocation enforcement at a layer that honors both mechanisms reliably while the library defect is unresolved — for example a reverse proxy or TLS terminator (nginx, HAProxy, OpenSSL-based front end) that performs its own full chain validation. Strip or reject certificates revoked in the loaded CRL at the front end.
   • If CRL enforcement is the primary control in your deployment, consider temporarily disabling OCSP enablement so that the OCSP soft-fail path cannot collapse the result onto success and mask the CRL check. This restores CRL-only enforcement, which the defect does not affect, at the cost of losing OCSP timeliness. Validate against your revocation policy and change-control requirements before applying.
   • Pin or narrow trust anchors. Where the environment permits, restrict trust anchors to specifically expected issuing CAs so that acceptance of an unexpectedly revoked intermediate cannot extend to a whole subtree.
   • Validate the compensating control. After any workaround, test with a certificate (a) revoked in your CRL and (b) carrying no AIA OCSP URL, and confirm it is rejected.

2. Patch / upgrade steps:

   • No patch currently exists. Monitor the wolfSSL project's security advisories and release notes for CVE-2026-94417 and apply the vendor fix as soon as it is published. Do not assume a version upgrade resolves the issue until the vendor advisory explicitly lists it.
   • Track the CVE via NVD for status changes, CVSS scoring, and the first references to a fixed version.
   • Re-audit build flags after any upgrade: a library upgrade alone does not fix an application that continues to call both revocation APIs with an affected configuration unless the vendor fix addresses the code path in ProcessPeerCerts().

3. Long-term hardening:

   • Inventory every system, product, container image, and dependency that embeds wolfSSL, and record its build flags (HAVE_OCSP, HAVE_CRL, and the --enable-* presets from the NVD list). Exposure assessment requires knowing which deployments enable both.
   • Treat dual-revocation validation as a security test case. Include "present a revoked certificate with no AIA OCSP URL" in the PKI/TLS test suite for all mTLS and server-authentication deployments.
   • Prefer fail-closed revocation for high-value mutual authentication where availability of a responder can be guaranteed, and document the soft-fail posture explicitly rather than inheriting library defaults.
   • Maintain actionable CRLs and, where feasible, OCSP responders reachable to the clients and servers performing validation, so soft-fail paths are the exception rather than the norm.
   • Monitor the wolfSSL project's release stream and feed it into SBOM-driven vulnerability management.

References

• NVD — CVE-2026-94417: https://nvd.nist.gov/vuln/detail/CVE-2026-94417
• CWE-299 — Improper Check for Certificate Revocation: https://cwe.mitre.org/data/definitions/299.html
• wolfSSL project security advisories (vendor advisory pending; no CVE-2026-94417 advisory confirmed as of report date): https://www.wolfssl.com/security/
• CISA Known Exploited Vulnerabilities catalog (CVE-2026-94417 not listed as of report date): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• FIRST EPSS (no score recorded as of report date): https://www.first.org/epss/

No public proof-of-concept, Nuclei template, or exploit code was available. No evidence of exploitation in the wild, no threat-actor attribution, and no CISA KEV entry were provided with the intelligence data.