CVE-2026-94419

Executive Summary

CVE-2026-94419 is an improper-authentication vulnerability (CWE-287) in wolfSSL affecting builds that leave the session cache reference mode enabled (NO_SESSION_CACHE_REF undefined). In these builds, wolfSSL_get_session() returns an internal ClientSession handle rather than a session object, and AddSessionToCache() matches cached sessions on the server-chosen TLS 1.2 session ID alone, allowing an attacker-controlled server to overwrite a client-side cache entry with its own master secret, cipher suite, and version. The client subsequently completes an abbreviated handshake with the attacker that omits the Certificate message, so neither chain verification nor wolfSSL_check_domain_name() runs, allowing full impersonation of the original server for the lifetime of that connection.

Technical Analysis

This CVE is fixed — but is this the right issue in wolfSSL? The wolfSSL issue number is CVE-2026-94419, and is listed in GitHub as GHSA-jcp9-cx9q-8w4h. The underlying defect is a logical authentication and session-binding failure rather than a memory-safety bug.

Root cause. Without NO_SESSION_CACHE_REF, wolfSSL_get_session() does not return a session object. It returns what the description calls a ClientSession reference of the form {row, index, hash(sessionID)} into the process-global SessionCache. That handle is resolved by ClientSessionToSession(), which validates the reference against the stored hash of the session ID alone. The description states that "nothing on the write path compares the peer, the application's server ID or the WOLFSSL_CTX." There is therefore no binding between a cache handle and the origin server that owns it.

The overwrite. In TLS 1.2, the session ID is chosen by the server and transmitted in the clear (it is not encrypted, and in a resumed/abbreviated flow it is not authenticated by a Certificate message). AddSessionToCache() matches incoming sessions on the session ID. Because the ID is attacker-controllable, an attacker server can present the same session ID as a legitimate server, causing AddSessionToCache() to match the existing client-side entry and overwrite it with the attacker's master secret, cipher suite, and version. The existing ClientSession handle, which references {row, index, hash(sessionID)}, continues to resolve to the same slot; the tampered entry is now what the handle points at.

The authentication bypass. When the application resumes using that handle, the resumption path produces an abbreviated handshake in which no Certificate message is sent — this is normal TLS 1.2 resumption behavior. Because no Certificate is transmitted, wolfSSL performs neither chain verification nor domain-name verification via wolfSSL_check_domain_name(). Resumption trusts the cached master secret. The cached master secret now belongs to the attacker, so the attacker is accepted as the original server for the whole of that connection.

Affected build surface. The defect is configuration-gated and affects builds in which NO_SESSION_CACHE_REF, NO_SESSION_CACHE, NO_CLIENT_CACHE and TITAN_SESSION_CACHE are all undefined. Per the description this includes a plain ./configure, --enable-opensslextra and --enable-opensslall. Fifteen integration options define NO_SESSION_CACHE_REF and are therefore not affected; these include --enable-all, --enable-distro, --enable-curl, --enable-nginx, --enable-haproxy, --enable-stunnel, --enable-wpas and the remainder of the OPENSSL_COMPATIBLE_DEFAULTS family. Separately, --enable-leanpsk, --enable-leantls, --enable-lowresource and --enable-tinytls13 disable the cache outright, which also removes exposure. The NVD description is truncated mid-sentence ("The applicat..."), so further application-side preconditions may exist; no additional details should be assumed.

Attack surface and preconditions. Exploitation requires (1) a wolfSSL client built with one of the affected option sets and using the affected session-cache reference mode, (2) the client to cache a session with a legitimate server, and (3) the attacker to be able to present a TLS 1.2 session ID collision at the point the client connects or reconnects, or to induce the client to add the attacker's session to the cache. Network position (on-path, DNS/route manipulation, or a malicious endpoint the client is directed to) is a realistic enabler because the session ID is sent in cleartext and is therefore observable. The vulnerability class is improper authentication: the client is fooled into treating an attacker session as an authenticated continuation of a legitimate one.

Limitations of available data. CVSS score and vector are not provided by the sources (N/A). CWE is given as CWE-287. No public PoC, exploit code, or Nuclei template exists. No affected version list, vendor advisory, or patch is available. The analysis above is bounded strictly to what the description states; no function names, filenames, or parameters beyond those quoted here are asserted.

Exploitation Scenarios

No public PoC is available; the chain below is inferred from the vulnerability class and the mechanisms named in the description. No specific code patterns are invented.

1. Reconnaissance / target identification. The attacker identifies a wolfSSL-based client that uses session caching and is compiled in the affected configuration (reference mode, cache enabled: NO_SESSION_CACHE_REF, NO_SESSION_CACHE, NO_CLIENT_CACHE, TITAN_SESSION_CACHE all undefined). Because the TLS 1.2 session ID is sent in cleartext, an on-path attacker can passively observe session IDs for connections to a target legitimate server and record an ID of interest. The attacker also establishes control of, or a position in front of, an endpoint the client may contact.

2. Triggering the flaw class. The client caches a session with the legitimate server. The attacker then presents the same session ID observed in cleartext. AddSessionToCache() matches the incoming session on that ID — the write path compares no peer, no application server ID, and no WOLFSSL_CTX — and overwrites the client-side entry with the attacker's master secret, cipher suite, and version. The prior ClientSession handle {row, index, hash(sessionID)} still hashes to the same ID and therefore still resolves.

3. Resume through the tampered handle. When the application resumes via the handle, wolfSSL_get_session()/ClientSessionToSession() resolve it against the hash of the session ID alone, so the tampered entry is used. The resumption produces an abbreviated handshake, which by design sends no Certificate message. Consequently neither certificate-chain verification nor wolfSSL_check_domain_name() executes. The attacker, holding the cached master secret, is accepted as the original server.

4. Post-exploitation impact. For the entire lifetime of that connection, the attacker is treated as the authenticated origin server. Any application-layer data the client sends, and any response it accepts, is exposed to a party that never proved possession of the legitimate server's private key or a valid certificate for the expected name. This enables credential theft, manipulation of application data, and downgrade/transcript manipulation within the established session. The description does not state whether session tickets, PSK modes, or other resumption variants extend the impact, so those must not be assumed.

Impact Assessment

Successful exploitation yields confidentiality and integrity compromise of the affected client connection: the attacker is accepted as the original server without presenting a valid certificate. Business impact includes interception and modification of application traffic, potential credential or token exposure where the application transmits them over the hijacked session, and erosion of certificate-based trust assumptions in monitoring and compliance controls. Scope is changed (S:C) because the security decision for the session is made by a different component (the session cache) than the one that is normally responsible for peer authentication.

Blast radius is limited to clients built in the affected configuration and actively using the session-cache reference mode; wolfSSL builds using the fifteen integration options that define NO_SESSION_CACHE_REF or the options that disable the cache outright are not exposed. Because the vulnerable build flags include a plain ./configure and the widely used --enable-opensslextra and --enable-opensslall presets, a substantial subset of embedded, IoT, and application client deployments is plausibly in scope. The number of affected versions and deployments is not enumerated in the available data.

CVSS: no score or vector was published by the sources provided (N/A). The vector shown in METADATA is an analyst-supplied estimate based on the described mechanism (network, high attack complexity, no privileges, user interaction required, scope changed, high confidentiality and integrity impact, no availability impact) and should be treated as provisional until a vendor or NVD score is issued. EPSS has not been scored by FIRST.org and no EPSS value is asserted here. CISA KEV status is NO; there is no evidence of in-the-wild exploitation in the provided data.

Detection Guidance

The rules below are behavioral detections for the vulnerability class (suspicious TLS 1.2 session resumption, repeated session IDs across distinct peers, and unexpected abbreviated handshakes) and for the wolfSSL project artifacts that indicate the affected configuration. They do not rely on invented indicator values.

Sigma Rule

title: Suspicious TLS Session Resumption Without Certificate Across Distinct Peers
id: 6a1f0c2e-9d3b-4c7a-8f21-wolfssl-94419
status: experimental
description: Detects TLS 1.2 sessions resumed against a peer using a session ID previously observed with a different server, consistent with wolfSSL session cache overwrite (CVE-2026-94419).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-94419
logsource:
  category: network_connection
  product: zeek
detection:
  selection_resume:
    tls.resumed: true
    tls.version: 'TLSv12'
    tls.server_name|exists: true
  selection_nocert:
    tls.server.cert_chain_length: 0
  detection:
    - selection_resume and selection_nocert
  condition: detection
fields:
  - src_ip
  - dest_ip
  - tls.server_name
  - tls.session_id
  - tls.server.cert_chain_length
falsepositives:
  - Legitimate session ticket resumption where certificate data is not logged by the sensor
  - TLS 1.3 fallback telemetry gaps
level: medium
tags:
  - attack.t1190
  - cve.2026.94419

YARA Rule

rule CVE_2026_94419_wolfSSL_SessionCache_Config
{
    meta:
        description = "Detects wolfSSL build artifacts/text indicating the affected session-cache configuration referenced in CVE-2026-94419"
        author = "valtersit.com threat intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-94419"
        date = "2026-01-01"
        severity = "medium"
        cve = "CVE-2026-94419"

    strings:
        $sym1 = "wolfSSL_get_session" ascii
        $sym2 = "ClientSessionToSession" ascii
        $sym3 = "AddSessionToCache" ascii
        $sym4 = "WOLFSSL_CTX" ascii
        $sym5 = "wolfSSL_check_domain_name" ascii
        $cfg1 = "NO_SESSION_CACHE_REF" ascii
        $cfg2 = "NO_SESSION_CACHE" ascii
        $cfg3 = "NO_CLIENT_CACHE" ascii
        $cfg4 = "TITAN_SESSION_CACHE" ascii

    condition:
        (uint32(0) == 0x464c457f or uint32(0) == 0xfeedface or uint32(0) == 0xfeedfacf) and
        (any of ($sym*)) and (any of ($cfg*))
}

Suricata IDS Rule

alert tls any any -> any any (msg:"CVE-2026-94419 Possible wolfSSL TLS1.2 Session Cache Overwrite / Resumption Without Certificate"; flow:established,to_client; tls.version:1.2; content:"|00 00|"; offset:0; depth:2; app-layer-protocol:tls; sid:9441901; rev:1; metadata:affected_product wolfSSL, cve CVE-2026-94419, created_at 2026_01_01; classtype:attempted-recon; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-94419;)

Note: Suricata has no native field for "resumed without Certificate," so this rule is a coarse heuristic keyed to TLS 1.2 handshake traffic plus the CVE metadata; it should be tuned or replaced with Zeek/tshark-derived stateful detection in production. Analysts should correlate with logs that record tls.resumed and absent certificate chains.

Elastic Detection

sequence by source.ip, destination.ip with maxspan=30m
  [ network where tls.version == "1.2" and tls.resumed == false and tls.server.certificate_chain_length > 0 and tls.server_name != null ]
  [ network where tls.version == "1.2" and tls.resumed == true and tls.server.certificate_chain_length == 0 and tls.session_id != null ]

This EQL sequence flags a session ID/peer that first appears with a presented certificate chain and later appears resumed without any certificate, which is the observable consequence of a session cache entry being overwritten and resumed (CVE-2026-94419).

Splunk SPL Query

index=network sourcetype=zeek:conn OR sourcetype=zeek:ssl OR sourcetype=suricata
| eval resumed=coalesce(tls_resumed, resumed)
| eval certlen=coalesce(tls_server_cert_chain_length, cert_chain_length)
| where (tls_version="TLSv12" OR tls_version="1.2")
| stats count values(dest_ip) as dests values(server_name) as snis values(certlen) as certlens by src_ip session_id resumed
| where resumed="true" AND certlens="0" AND mvcount(dests) > 1
| table _time src_ip session_id dests snis certlens count
| sort - count

This query surfaces a single source using one session ID across multiple destination peers with resumption and no certificate chain — the expected footprint of the cache-overwrite and abbreviated-handshake behavior described for CVE-2026-94419.

Wazuh OSSEC Rule

<group name="wolfssl,tls,cve-2026-94419,">
  <rule id="944190" level="10">
    <decoded_as>json</decoded_as>
    <field name="tls\.version">TLSv12</field>
    <field name="tls\.resumed">true</field>
    <field name="tls\.server\.cert_chain_length">0</field>
    <description>CVE-2026-94419: TLS 1.2 session resumed without certificate chain - possible wolfSSL session cache overwrite/impersonation.</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve_2026_94419,</group>
  </rule>

  <rule id="944191" level="7">
    <decoded_as>json</decoded_as>
    <field name="tls\.version">TLSv12</field>
    <field name="tls\.resumed">true</field>
    <description>CVE-2026-94419: TLS 1.2 session resumption observed - correlate for certificate omission across distinct peers.</description>
    <group>cve_2026_94419,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations.

• Rebuild wolfSSL with an integration option that defines NO_SESSION_CACHE_REF and is therefore not affected per the advisory: --enable-all, --enable-distro, --enable-curl, --enable-nginx, --enable-haproxy, --enable-stunnel, --enable-wpas, or another member of the OPENSSL_COMPATIBLE_DEFAULTS family.
• Alternatively, build with an option that disables the cache outright: --enable-leanpsk, --enable-leantls, --enable-lowresource, or --enable-tinytls13.
• If rebuild is not immediately possible, disable client-side session resumption in the application (do not call the session get/set APIs and do not persist session handles across connections), or pin the client to TLS 1.3 where the application permits, and enforce server certificate and hostname validation on every handshake at the application layer.
• Treat any build produced by a plain ./configure, --enable-opensslextra, or --enable-opensslall as potentially exposed and inventory it.

2. Patch/upgrade steps.

• No vendor patch or fixed version is identified in the available data (Patch sources: none; Vendor Fix: N/A). Monitor the wolfSSL project for a fixed release and the associated GitHub advisory (GHSA-jcp9-cx9q-8w4h is referenced for this issue number) and apply it as soon as it is published.
• Until a fix ships, the configuration changes above are the only reliable remediation, because they remove the vulnerable code path rather than relying on application behavior.

3. Long-term hardening.

• Eliminate plaintext, server-chosen session identifiers from trust decisions where possible; prefer TLS 1.3 PSK/session tickets with proper binding, or configurations that bind cached sessions to the peer identity and WOLFSSL_CTX.
• Ensure certificate-chain verification and domain-name checks cannot be skipped by the resumption path — defense in depth at the application layer (hostname pinning, post-handshake assertions).
• Enforce build-flag governance so security-relevant defines such as NO_SESSION_CACHE_REF are set deliberately and audited; maintain an SBOM noting the exact wolfSSL configuration per product.
• Deploy the detection logic above (TLS 1.2 resumption without certificate, single session ID across multiple peers) to catch this and similar cache-binding failures.

References

• NVD — CVE-2026-94419: https://nvd.nist.gov/vuln/detail/CVE-2026-94419
• wolfSSL project / GitHub advisory referenced for this issue (GHSA-jcp9-cx9q-8w4h): https://github.com/wolfSSL/wolfssl/security/advisories
• wolfSSL documentation — build/configuration options (NO_SESSION_CACHE_REF, OPENSSL_COMPATIBLE_DEFAULTS family, and cache-disabling options): https://www.wolfssl.com/documentation/
• CWE-287 — Improper Authentication: https://cwe.mitre.org/data/definitions/287.html
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-94419 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No public PoC, exploit code, Nuclei template, or evidence of in-the-wild exploitation or named threat-actor campaigns is available in the provided data for CVE-2026-94419. EPSS has not been scored by FIRST.org, and no CVSS score or vector has been published by the sources used; the vector in METADATA is a provisional analyst estimate.