CVE-2026-89135

Executive Summary

CVE-2026-89135 is a critical improper certificate validation vulnerability (CWE-295) affecting wolfSSL versions 5.8.4 through 5.9.2 when built with the OPENSSL_EXTRA macro set and the NO_CERTS and WOLFCRYPT_ONLY macros unset, or with the --enable-opensslextra configure option. When an application invokes the X509_verify_cert function and that call fails, the library permanently installs an unverified attacker-supplied CA into a shared CertManager, causing all subsequent certificate validation consumers (native TLS, OCSP, CRL, and direct CertManager verification) to trust it. This breaks the trust boundary for every type-blind sibling consumer of the shared manager, effectively nullifying certificate validation on affected hosts. No public proof-of-concept, exploit code, Nuclei template, or patch is currently available, and the CVE has not been added to CISA KEV.

Technical Analysis

The flaw is a state-corruption issue inside wolfSSL's OpenSSL-compatibility certificate path, not a memory-safety defect. CWE-295 ("Improper Certificate Validation") is the correct classification: validation logic is bypassed rather than the certificate store being corrupted at the memory level.

The mechanism, as described by the CNA, is as follows:

1. An application calls X509_verify_cert.
2. The verification call fails — for example, the certificate presented is not signed by a trusted root, is expired, or fails chain building.
3. Despite the failure, the certificate authority material associated with that failed verification is planted permanently in the shared CertManager.
4. The CertManager is a shared component, meaning the planted CA persists beyond the scope of the single failed call.
5. All "type-blind sibling consumers" of that shared manager — native TLS, OCSP, CRL, and direct CertManager verification — subsequently treat the planted CA as trusted.

The critical property is the word permanently. A correctly implemented verification routine must discard all state associated with a failed chain build; it must never mutate the trust anchor set on the failure path. Here, the failure path itself is what introduces the attacker-controlled anchor. This makes the vulnerability a persistent trust-store poisoning primitive: a single failed verification is sufficient to degrade the validation state of the entire process for the remainder of its lifetime.

The word type-blind is equally important. Because consumers such as OCSP, CRL processing, and native TLS all draw on the same CertManager without distinguishing how a given anchor was admitted, an anchor that was never validated for any particular purpose is nevertheless honored for every purpose. This defeats the intended separation between trust anchors used for TLS server authentication, OCSP responder signing, and CRL issuer authorization.

Scope and build conditions (strictly per the advisory):

• Affected versions: wolfSSL 5.8.4 through 5.9.2.
• Required build configuration: OPENSSL_EXTRA defined and !NO_CERTS and !WOLFCRYPT_ONLY, or built with --enable-opensslextra.
• Required application behavior: the application must specifically be making calls to X509_verify_cert.

This is a narrow but realistic intersection. --enable-opensslextra is widely used by applications ported from OpenSSL, and X509_verify_cert is a common explicit verification entry point in such code. Systems using wolfSSL's native wolfSSL_CTX_load_verify_locations-style configuration without calling X509_verify_cert, or builds with NO_CERTS or WOLFCRYPT_ONLY, are outside the stated affected set.

Attack surface: the boundary where an untrusted peer supplies X.509 material that reaches an X509_verify_cert call. This includes any network-facing TLS endpoint, OCSP responder client, or CRL consumer in an application built with the required macros.

No CVSS vector was published by the CNA (score: N/A). No EPSS value has been assigned by FIRST.org. No public exploit, PoC, or Nuclei template exists. The technical detail available does not permit identification of specific source files, internal function names beyond X509_verify_cert and CertManager, or exact code paths; the above describes only the mechanism explicitly stated by the CNA.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (improper certificate validation leading to persistent trust-anchor injection) and from the mechanism stated in the NVD description.

Step 1 — Reconnaissance and target identification. An attacker identifies a network service or application that (a) is linked against wolfSSL 5.8.4–5.9.2, (b) was built with --enable-opensslextra or the OPENSSL_EXTRA && !NO_CERTS && !WOLFCRYPT_ONLY macro combination, and (c) invokes X509_verify_cert on peer-supplied certificate material. Fingerprinting can leverage TLS handshake characteristics, wolfSSL-specific behavior, and Shodan/Internet-scanning services. The attacker does not need credentials or user interaction; they only need the ability to present X.509 material to a code path that reaches X509_verify_cert.

Step 2 — Triggering the flaw class. The attacker presents a certificate or certificate chain intended to fail verification — for example, a certificate issued by an attacker-controlled CA that is not in the legitimate trust store. The application calls X509_verify_cert. The call fails, as it should. The vulnerability is that this failure path plants the attacker's CA into the shared CertManager instead of discarding it. The attacker's material therefore does not need to pass validation; failure is the exploitation primitive.

Step 3 — Payload/execution at the vulnerability-class level. No code injection is required. The "payload" is the attacker CA certificate itself, delivered through whatever interface feeds X509_verify_cert (for example, a TLS client or server certificate, an OCSP response signer certificate, or a CRL issuer certificate). Once the failed call has seeded the shared CertManager, the attacker subsequently presents a leaf certificate signed by that same CA. Because the planted CA is now resident in the shared manager, the "type-blind sibling consumers" — native TLS, OCSP, CRL, and direct CertManager verification — accept the chain. The attacker's forged identity is then treated as valid.

Step 4 — Post-exploitation impact. Successful exploitation yields a full break of certificate-based authentication and encryption trust guarantees in the affected process. Practical consequences include: acceptance of attacker-signed TLS server certificates (enabling interception of connections the process initiates), acceptance of attacker-signed client certificates where mutual TLS is used, forged OCSP responses (making revoked certificates appear valid), and forged CRL issuer data (suppressing revocation). The persistence of the planted CA for the lifetime of the process means a single failed verification can retroactively and prospectively undermine all subsequent certificate decisions made by that process — including decisions made by unrelated components sharing the same CertManager.

Because scope changes as a result of the flaw, an attacker who can reach one X509_verify_cert invocation may compromise trust decisions belonging to otherwise-independent security components inside the same process.

Impact Assessment

CVE-2026-89135 has no published CVSS score (N/A), so the following is an analytical assessment rather than a vendor-scored rating. Under CVSS v3.1 conventions, the characteristics described are consistent with:

• Confidentiality: High — attacker-forged TLS identities permit interception of data the process believes is protected.
• Integrity: High — forged OCSP/CRL data and forged leaf certificates allow the attacker to assert false revocation and identity status.
• Availability: None to Low — the flaw does not directly cause denial of service; the failed call itself returns a failure.
• Attack Vector: Network — certificate material is supplied by remote peers.
• Attack Complexity: Low — no race condition, no privileged position, no special knowledge is required once the application behavior is known.
• Privileges Required: None / User Interaction: None — the attacker supplies the certificate; no authentication precedes the vulnerable call.
• Scope: Changed — the shared CertManager means compromise of one consumer's verification propagates to sibling consumers (native TLS, OCSP, CRL, direct CM verify), a classic scope-change scenario.

Affected systems: embedded and IoT firmware, industrial gateways, VPN concentrators, and any OpenSSL-compatibility application built on wolfSSL 5.8.4–5.9.2 with --enable-opensslextra that calls X509_verify_cert. These include environments where wolfSSL is chosen precisely for its small footprint — often long-lived devices with infrequent firmware update cadence.

Blast radius: within a single affected process, the entire certificate trust state is degraded after the first failed verification. In multi-tenant or multi-connection daemons sharing a CertManager, one malicious peer can poison trust decisions for all other connections handled by that process. Because the flaw is in the library and not the application, every application in the affected build configuration inherits the defect.

Business impact: potential loss of transport confidentiality, fraudulent authentication, and defeated revocation checking — directly relevant to regulatory obligations around encryption integrity and certificate lifecycle management.

Detection Guidance

Detection must address both the artifact (build configuration and version) and the behavior (failed X509_verify_cert calls that do not result in connection teardown or trust-store rejection). Because the flaw is logical and resides in-process, network detection is necessarily inferential; the strongest signals come from host telemetry and application logging.

Sigma Rule

title: Suspicious Successive Certificate Verification Failures - wolfSSL CVE-2026-89135
id: 6c9f1a24-1c2e-4f0b-9a71-8a3e5d2b7c14
status: experimental
description: Detects processes linking wolfSSL 5.8.x/5.9.x logging failed X509_verify_cert calls followed by successful certificate acceptance, consistent with persistent CertManager trust-anchor poisoning (CVE-2026-89135).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-89135
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1190
  - attack.t1553
logsource:
  category: application
  product: wolfssl
detection:
  selection_build:
    message|contains:
      - 'opensslextra'
      - 'OPENSSL_EXTRA'
  selection_fail:
    message|contains|all:
      - 'X509_verify_cert'
      - 'error'
  selection_accept:
    message|contains:
      - 'certificate accepted'
      - 'verify ok'
      - 'TLS handshake complete'
  timeframe: 5m
  condition: selection_fail and selection_accept
falsepositives:
  - Legitimate certificate rotation or deliberate testing of invalid certificate handling
  - Applications that log verbose certificate verification diagnostics during startup
level: high

YARA Rule

rule CVE_2026_89135_wolfSSL_opensslextra_build
{
    meta:
        description = "Detects wolfSSL binaries built with OpenSSL compatibility layer (--enable-opensslextra / OPENSSL_EXTRA) importing X509_verify_cert, potentially affected by CVE-2026-89135"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-89135"
        date = "2026-01-01"
        severity = "high"

    strings:
        $fn1 = "X509_verify_cert" ascii
        $cm1 = "CertManager" ascii wide
        $wl1 = "wolfSSL" ascii
        $wl2 = "wolfssl" ascii
        $ver1 = "5.8.4" ascii
        $ver2 = "5.9.2" ascii

    condition:
        uint16(0) == 0x5A4D or uint32(0) == 0x464C457F
        and $fn1
        and any of ($cm1, $wl1, $wl2)
        and any of ($ver1, $ver2)
}

YARA on compiled binaries will only match if version strings survive compilation. For reliable inventory, prefer scanning package manifests and SBOMs for wolfssl version 5.8.4–5.9.2 and for build flags containing opensslextra.

Suricata IDS Rule

alert tls any any -> any any (msg:"CVE-2026-89135 wolfSSL X509_verify_cert failed CA injection - repeated untrusted chain then accepted identity"; flow:established,to_server; tls.store; threshold: type both, track by_src, count 3, seconds 300; metadata:affected_product wolfSSL, affected_versions 5.8.4-5.9.2, cve CVE-2026-89135, mitre_tactic_technique T1190; classtype:attempted-user; sid:202689135; rev:1;)

Note: pure network signature coverage for this CVE is limited because the vulnerable decision is made in-process after the handshake. The rule above is a heuristic that flags repeated TLS sessions carrying certificate material from a non-standard issuer within a short window; it should be paired with TLS certificate inventory logs (JA3/JA4 and issuer/subject capture) rather than relied upon alone.

Elastic Detection

sequence by process.entity_id with maxspan=5m
  [ process where event.category == "process" and process.name != null and
      process.args : "*opensslextra*" ]
  [ network where network.protocol == "tls" and tls.server.x509.issuer.common_name != null and
      not tls.server.x509.issuer.common_name : ("*DigiCert*", "*Let's Encrypt*", "*GlobalSign*", "*Sectigo*", "*Entrust*") ]

This sequence flags processes whose command line indicates an OpenSSL-compatibility wolfSSL build immediately followed by TLS activity involving an atypical certificate issuer — a behaviorally consistent pattern with a poisoned CertManager, though it will require environment-specific tuning of the issuer allowlist.

Splunk SPL Query

index=linux OR index=windows sourcetype IN ("syslog","WinEventLog:Application","wolfssl")
| eval msg=coalesce(_raw, message, Message)
| where match(msg,"X509_verify_cert") OR match(msg,"CertManager") OR match(msg,"OPENSSL_EXTRA") OR match(msg,"opensslextra")
| eval failure=if(match(msg,"(?i)(fail|error|reject|untrusted)"),1,0)
| eval success=if(match(msg,"(?i)(accept|verify ok|handshake complete|trusted)"),1,0)
| stats sum(failure) as failures sum(success) as successes values(host) as hosts by process, msg
| where failures > 0 AND successes > 0
| sort - failures
| table process hosts failures successes msg

The objective is to surface processes that both log certificate verification failures and subsequently log successful certificate acceptance — the observable behavioral signature of a failed X509_verify_cert call that nonetheless leaves a CA trusted.

Wazuh OSSEC Rule

<group name="wolfssl,cve-2026-89135,">
  <rule id="100891" level="12">
    <decoded_as>syslog</decoded_as>
    <match>X509_verify_cert</match>
    <match>error|fail|untrusted</match>
    <description>CVE-2026-89135: wolfSSL X509_verify_cert failure detected - possible CertManager trust poisoning</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>

  <rule id="100892" level="14">
    <if_sid>100891</if_sid>
    <match>accept|verify ok|handshake complete</match>
    <description>CVE-2026-89135: Certificate validation failure followed by successful acceptance - strong indicator of shared CertManager trust-anchor poisoning</description>
    <mitre>
      <id>T1553</id>
    </mitre>
  </rule>

  <rule id="100893" level="10">
    <decoded_as>syslog</decoded_as>
    <match>OPENSSL_EXTRA|opensslextra|CertManager</match>
    <description>CVE-2026-89135: Affected wolfSSL build configuration or CertManager activity observed</description>
  </rule>
</group>

Companion File Integrity Monitoring rule to detect affected library versions on disk:

<group name="wolfssl,sbom,">
  <rule id="100894" level="10">
    <if_sid>550</if_sid>
    <field name="file">libwolfssl</field>
    <description>wolfSSL shared library modified - verify version is not within 5.8.4-5.9.2 affected range (CVE-2026-89135)</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No vendor patch, workaround, or fixed version is available from any tracked source. The absence of a patch, PoC, or KEV listing means exploitation in the wild is not evidenced, but it also means every affected deployment remains exposed. Treat mitigation as compensating-controls-only until wolfSSL publishes a fix.

1) Immediate mitigations (until a patch exists):

• Remove the X509_verify_cert call path from reachable code, or gate it behind input that cannot be influenced by an untrusted peer. This is the single most direct mitigation, since the CNA explicitly scopes the vulnerability to applications "specifically making calls to the X509_verify_cert function."
• Rebuild wolfSSL without --enable-opensslextra / without OPENSSL_EXTRA where the application does not strictly require the OpenSSL compatibility layer. If WOLFCRYPT_ONLY or NO_CERTS can be defined without breaking functionality, doing so removes the system from the affected configuration class entirely.
• Isolate processes that call X509_verify_cert so that a poisoned shared CertManager cannot be consumed by high-value TLS, OCSP, or CRL logic — i.e., do not let untrusted certificate handling share a process with trusted certificate decisions.
• Treat all certificate-based decisions in affected processes as untrusted and add out-of-band verification — for example, certificate pinning at the application layer, or verification performed by an independent, non-affected TLS library in a separate process.
• Inventory first. Because the flaw is version- and build-flag-dependent, identify every deployment of wolfSSL 5.8.4–5.9.2 and record whether it was built with --enable-opensslextra or the OPENSSL_EXTRA && !NO_CERTS && !WOLFCRYPT_ONLY macro set. Deployments failing these conditions are out of scope.

2) Patch/upgrade steps (when available):

• No fixed version has been identified. Monitor the wolfSSL project's release channel and security advisories for a version exceeding 5.9.2 that explicitly addresses persistent CertManager state on failed X509_verify_cert calls.
• When a fix ships, upgrade from any 5.8.4–5.9.2 release, then re-validate build flags to confirm the OpenSSL compatibility layer is compiled as intended.
• Because a poisoned CertManager is process-resident, restart affected processes after upgrade to clear any previously planted trust anchors; an upgrade alone does not purge in-memory state from a still-running, already-poisoned process.
• Verify the patched build actually discards CA material on the verification failure path, and re-test negative certificate validation cases (untrusted CA, expired chain, broken chain) to confirm they now fail closed.

3) Long-term hardening:

• Adopt SBOM-driven library governance so that any component (wolfSSL here) can be matched against affected version and build-flag ranges in minutes, not weeks.
• Enforce fail-closed certificate validation policy by design, with explicit tests asserting that a failed verification never mutates shared trust state. Add regression tests that call X509_verify_cert with a deliberately invalid CA and then assert the CertManager trust set is unchanged.
• Minimize reliance on OpenSSL-compatibility layers in security-critical firmware; every compatibility shim (like --enable-opensslextra) widens the attack surface and increases the chance of state-management divergence from the reference implementation.
• Eliminate shared mutable trust state across consumers where architecture allows, so that a failure in one consumer (e.g., OCSP) can never alter the trust decisions of another (e.g., native TLS). The "type-blind sibling consumer" propagation described in this CVE is a design-level risk, not merely a coding defect.
• Ratchet certificate lifecycle monitoring: alerting on any new or unexpected certificate issuer observed on affected hosts will surface the post-exploitation state even where the initial trigger is missed.

References

1. NVD — CVE-2026-89135: https://nvd.nist.gov/vuln/detail/CVE-2026-89135
2. CWE-295 — Improper Certificate Validation: https://cwe.mitre.org/data/definitions/295.html
3. MITRE ATT&CK — T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
4. MITRE ATT&CK — T1553 Subvert Trust Controls: https://attack.mitre.org/techniques/T1553/
5. wolfSSL project release and security advisory channel: https://www.wolfssl.com/ (consult for a fixed release above 5.9.2)

Threat actor and exploitation status: No public proof-of-concept, exploit code, or Nuclei template is available for CVE-2026-89135, and the vulnerability is not listed in CISA's Known Exploited Vulnerabilities catalog. No threat actor campaign or in-the-wild exploitation has been reported by any tracked source. EPSS has not yet been scored by FIRST.org. The absence of observed exploitation should not be read as safety: the required preconditions (a reachable X509_verify_cert call in a wolfSSL 5.8.4–5.9.2 --enable-opensslextra build) are common enough in OpenSSL-ported network services that the flaw should be treated as high priority for inventory and compensating controls.