CVE-2026-89102

Executive Summary

CVE-2026-89102 is a client-side certificate validation flaw in wolfSSL versions 5.7.2 through 5.9.2 affecting the RFC 6961 multiple OCSP response stapling implementation. When a client enables the HAVE_CERTIFICATE_STATUS_REQUEST_V2 build feature and invokes wolfSSL_UseOCSPStaplingV2 with the WOLFSSL_CSR2_OCSP_MULTI mode, the library fails to verify whether a certificate in the peer's chain is actually authorized to act as a certificate authority. This allows an attacker holding any certificate chaining to a trusted CA—together with its private key—to forge certificates for arbitrary identities that the wolfSSL client will accept as valid, enabling man-in-the-middle interception of ostensibly TLS-protected traffic. The flaw also persists the server's end-entity certificate into the trust store, contaminating subsequent connections that reuse the same context even when OCSP multi-stapling is not in use.

Technical Analysis

CWE-295 (Improper Certificate Validation) is the assigned weakness class. The vulnerability resides in wolfSSL's client-side handling of RFC 6961, which extends OCSP stapling by allowing a server to staple multiple OCSP responses covering the certificates in its chain. The HAVE_CERTIFICATE_STATUS_REQUEST_V2 compile-time feature enables this capability, and the runtime API wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options) activates multi-response validation for a session.

The core defect is a missing authorization check: when processing the chain, the client treats any certificate presented in the peer's chain as if it were a certificate authority, without confirming that the certificate's basic constraints or key usage actually permit it to sign other certificates. In RFC 6961 multi-stapling, the server supplies OCSP responses for several certificates along the chain; the client is obligated to verify each certificate against a trusted root and confirm each issuer's authority to issue the certificate beneath it. wolfSSL 5.7.2–5.9.2 fails this step specifically in the multi-response path, so a certificate that merely chains to a trusted CA—but is not itself a CA—is accepted in an issuer role.

The practical consequence is a complete bypass of the chain-of-trust guarantee for affected clients. Because the attacker only needs any certificate chaining to a trusted root (plus its corresponding private key), the barrier to exploitation is dramatically lower than forging a CA certificate. The attacker can then mint end-entity certificates for arbitrary subject names, and the wolfSSL client validates them. A second, compounding issue is trust-store pollution: the server's end-entity certificate is written into the persistent trust store, so a forged certificate accepted during one connection can remain trusted for later connections that reuse the context—even after OCSP multi-stapling usage ceases.

The vulnerability was identified by internal wolfSSL testing. No CVSS vector has been assigned by NVD, and the flaw is not listed in CISA KEV.

Exploitation Scenarios

No public proof-of-concept is available; the attack chain below is inferred from the vulnerability class and the NVD description. No PoC or exploit code is known to exist publicly.

1. Reconnaissance / target identification. The attacker identifies a target that uses a wolfSSL-based client (or library embedding wolfSSL) compiled with HAVE_CERTIFICATE_STATUS_REQUEST_V2 and configured to call wolfSSL_UseOCSPStaplingV2 with WOLFSSL_CSR2_OCSP_MULTI. Because this is a build-time plus runtime configuration, the attacker must profile the victim application or rely on the fact that the feature is enabled in the target product.

2. Obtaining a chaining certificate. The attacker acquires any certificate that chains to a CA the client trusts, along with its private key. This can be a legitimate certificate issued to the attacker, an abandoned but still-valid certificate, or a compromised low-value certificate. Notably the attacker does not need CA privileges on that certificate.

3. Triggering the flaw class. The attacker positions themselves on the network path (e.g., man-in-the-middle on a shared network, DNS/route hijack) and presents a forged end-entity certificate for the target identity, backed by the attacker's chaining certificate acting as an unauthorized issuer. Because the vulnerable client accepts any chain certificate as a CA without verifying its authorization, the forged leaf validates.

4. Post-exploitation impact. With the forged certificate accepted, the attacker decrypts and/or modifies traffic the victim believes is protected by TLS. Additionally, the accepted end-entity certificate enters the persistent trust store, so the forged identity may continue to be honored across subsequent connections that reuse the context—extending the window of compromise beyond the initial session and beyond the OCSP multi-stapling path itself.

The high attack complexity reflects that the attacker must both possess a chaining certificate plus its private key and be positioned to intercept traffic; the absence of public tooling further constrains opportunistic exploitation.

Impact Assessment

Impact is high for confidentiality and integrity, with no direct availability impact:

• Confidentiality (High): Successful certificate forgery enables decryption of intercepted TLS sessions, exposing credentials, tokens, and sensitive application data.
• Integrity (High): The attacker can impersonate arbitrary server identities, enabling content injection, redirection, and modification of data in transit.
• Availability (None): The flaw does not directly cause denial of service.
• Scope (Unchanged): The vulnerability affects the vulnerable TLS client component.
• Attack Vector (Network) / Complexity (High): Exploitation requires network positioning and possession of a chaining certificate with its private key.
• Privileges (None) / User Interaction (None): No special privileges or user actions are required beyond the client establishing an affected connection.

The blast radius covers any product or application embedding wolfSSL 5.7.2–5.9.2 with the affected feature and API usage. Because the flaw stems from a widely reused embedded TLS library, impact can extend across IoT, embedded, and server-side software that ships wolfSSL. Trust-store pollution raises the persistence of compromise for any long-lived SSL context.

Detection Guidance

Sigma Rule

title: Potential wolfSSL OCSP Multi-Stapling Certificate Forgery
id: 8f2c1e7a-4b91-4d3e-9a2c-1f6b0d5e7c31
status: experimental
description: Detects client applications loading the vulnerable wolfSSL OCSP V2 multi-stapling path, indicative of exposure to CVE-2026-89102.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-89102
author: valtersit.com
date: 2026/01/01
tags:
  - attack.defense_evasion
  - attack.t1553
logsource:
  category: process_creation
  product: linux
detection:
  selection_bin:
    Image|endswith:
      - '/wolfssl'
      - '/examples/client'
  selection_args:
    CommandLine|contains:
      - 'UseOCSPStaplingV2'
      - 'OCSP_MULTI'
  condition: selection_bin and selection_args
falsepositives:
  - Legitimate OCSP multi-stapling test harnesses
level: medium

YARA Rule

rule CVE_2026_89102_wolfSSL_OCSP_MULTI
{
    meta:
        description = "Detects wolfSSL binaries/libraries referencing the vulnerable OCSP V2 multi-stapling code path (CVE-2026-89102)"
        author = "valtersit.com"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-89102"
        tlp = "WHITE"
    strings:
        $s1 = "WOLFSSL_CSR2_OCSP_MULTI" ascii
        $s2 = "HAVE_CERTIFICATE_STATUS_REQUEST_V2" ascii
        $s3 = "wolfSSL_UseOCSPStaplingV2" ascii
    condition:
        uint32(0) == 0x464c457f or uint16(0) == 0x5a4d and any of ($s*)
}

Suricata IDS Rule

alert tls any any -> any any (msg:"CVE-2026-89102 wolfSSL OCSP Multi-Stapling Possible Certificate Forgery"; flow:established,to_client; tls.store; content:"|00 00|"; tls.cert_subject; pcre:"/wolfSSL/i"; classtype:attempted-recon; sid:202689102; rev:1; metadata:affected_product wolfSSL, cve CVE-2026-89102;)

Elastic Detection

process where process.command_line like~ "*UseOCSPStaplingV2*" or process.command_line like~ "*OCSP_MULTI*"

Splunk SPL Query

index=main (sourcetype=sysmon OR sourcetype=linux:audit)
| search (process_command_line="*UseOCSPStaplingV2*" OR process_command_line="*OCSP_MULTI*")
| table _time host user process_name process_command_line
| sort -_time

Wazuh OSSEC Rule

<group name="wolfssl,cve-2026-89102,">
  <rule id="100891" level="10">
    <decoded_as>json</decoded_as>
    <field name="command">UseOCSPStaplingV2</field>
    <description>CVE-2026-89102: wolfSSL OCSP multi-stapling path invoked (possible cert forgery exposure)</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED) — no patch evidence from any tracked source. No vendor fix, workaround, or affected-version mapping has been published.

1. Immediate mitigations:

   • Disable the HAVE_CERTIFICATE_STATUS_REQUEST_V2 build feature and remove or avoid calls to wolfSSL_UseOCSPStaplingV2(..., WOLFSSL_CSR2_OCSP_MULTI, ...) where operationally possible. This eliminates the vulnerable code path.
   • Where feature removal is not feasible, enforce strict certificate pinning on the client side so that only known-good server certificates are accepted, limiting forged-certificate acceptance.
   • Do not reuse SSL contexts across connections for extended periods, and periodically clear persistent trust stores to reduce the effect of trust-store pollution.
   • Constrain network exposure: prevent untrusted networks from being able to intercept client TLS sessions (e.g., enforce managed networks / trusted proxies).

2. Patch / upgrade steps:

   • Monitor wolfSSL's official release channels and security advisories for a fixed version. No patched release exists at the time of writing; upgrade as soon as a fix is announced.
   • Because this is an embedded TLS library, track wolfSSL versions across all deployed products (IoT, VPN clients, embedded devices) and plan revalidation once a fix is available.

3. Long-term hardening:

   • Adopt strict certificate validation posture: require CA basic constraints and key usage to be enforced for every certificate in the chain, including issuer-position certificates.
   • Rotate/replace trust stores and validate that no forged end-entity certificates were persisted into trust stores on potentially exposed hosts.
   • Add continuous SBOM tracking for wolfSSL and other embedded TLS libraries so that future advisories can be mapped quickly to deployed assets.

References

• NVD — CVE-2026-89102: https://nvd.nist.gov/vuln/detail/CVE-2026-89102
• wolfSSL official site / security advisories: https://www.wolfssl.com/
• CWE-295 — Improper Certificate Validation: https://cwe.mitre.org/data/definitions/295.html
• RFC 6961 — Multiple Certificate Status Request Extension: https://datatracker.ietf.org/doc/html/rfc6961
• CISA Known Exploited Vulnerabilities Catalog (not currently listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No known threat actor campaigns or exploit-in-the-wild evidence have been reported for CVE-2026-89102 at this time.