CVE-2026-15442

Executive Summary

CVE-2026-15442 is a heap-use-after-free (CWE-416) vulnerability in the wolfSSL embedded TLS library affecting all builds that make use of (D)TLS, including default builds. The flaw is triggered by a specific TLS shutdown sequence: an application that receives a partial wolfSSL_read() (often caused by a small user-supplied buffer), then calls wolfSSL_shutdown() for a bidirectional close, and then calls wolfSSL_read() again while the peer continues to transmit data during shutdown. No patch, workaround, affected version range, CVSS score, or public proof-of-concept was available at the time of writing, making this a high-uncertainty, unmitigated memory-safety defect in a widely embedded cryptographic library.

Technical Analysis

The vulnerability class is a heap-use-after-free, meaning a heap allocation is released via free while one or more references to that allocation remain reachable and are subsequently dereferenced. In memory-unsafe C implementations such as wolfSSL, this typically manifests as a read or write into a freed chunk, which can corrupt adjacent heap metadata or leak residual memory contents depending on the heap allocator's reuse behavior and the attacker's ability to shape allocations.

The wolfSSL (D)TLS implementation is the affected attack surface. The NVD description identifies a "series of conditional states during the TLS shutdown" as the root condition. Three application-side primitives are named explicitly and are central to the defect:

1. wolfSSL_read() returning a partial read — explicitly noted as "sometimes caused by a small user buffer passed in."
2. wolfSSL_shutdown() invoked for a bidirectional close.
3. A subsequent wolfSSL_read() call while the peer continues to send data during the shutdown handshake.

The stated failure mode is a state transition in which an internal TLS session/record buffer is freed during shutdown processing while the application's renewed wolfSSL_read() path still references the same freed allocation. The description states this "would lead to a state where a potential heap-use-after free happened," indicating that the trigger is a re-entrant or interleaved interaction between the application read loop and the library's own shutdown state machine, not a simple single-call defect.

The class is remotely reachable in the sense that the trigger requires "the peer continues trying to send data during the shutdown" — i.e., a remote counterparty controls the timing and volume of inbound data during the close handshake. This makes the peer a necessary participant in the exploit condition. The presence of partial reads caused by small application buffers is significant: it is a very common integration pattern in embedded, IoT, and constrained environments where stack-allocated scratch buffers of 256–1024 bytes are typical for TLS record consumption.

Because the description is sparse on internal data structures, record layer offsets, and specific allocation sizes, no claims about chunk layout, freelist behavior, or precise offset control can be made from the available data. What is derivable is limited to the vulnerable class (heap-use-after-free), the reachable surface (the (D)TLS shutdown path in all builds including default), and the application-side call sequence precondition. The full exploitability envelope — reliable code execution versus denial of service versus information disclosure — cannot be determined without the vendor's fix commit or a public analysis, neither of which exists in the provided data.

It is worth noting that because wolfSSL ships in default builds with (D)TLS enabled, the affected population is not limited to configurations with exotic compile-time flags. Any deployment using wolfSSL_read()/wolfSSL_shutdown() in the described pattern is potentially in scope.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and the call sequence explicitly described in the NVD entry. No internal function names beyond those stated in the description are asserted.

1. Reconnaissance / target identification. The attacker identifies a service whose TLS or DTLS stack is wolfSSL and whose application performs a read-consume-read pattern around close. Fingerprinting may rely on observable TLS library characteristics and JA3/JA3S-style fingerprints, though the data provided does not confirm any specific signature. In embedded/DTLS deployments (UDP-based), the target is typically reachable without establishing a full TCP handshake.

2. Triggering the flaw class. The attacker establishes a (D)TLS session and drives the application into a partial-read condition. Per the description, a small user buffer passed into wolfSSL_read() is a common cause: the application's buffer is smaller than the pending record/application data, so wolfSSL_read() returns a partial result and the remainder stays buffered in library state. The attacker then initiates or responds to shutdown such that the application calls wolfSSL_shutdown() for a bidirectional close.

3. Payload / execution method at class level. During the shutdown, the attacker's peer continues to send data. The application (per the described pattern) calls wolfSSL_read() again while shutdown is in progress. The interleaving of library shutdown state transitions with the renewed read path frees an internal buffer that the read path still references — a use-after-free. The attacker controls the timing of the continued data and, in a heap-grooming scenario, would attempt to influence what occupies the freed chunk. The data provided does not specify the freed structure's size or contents, so no claim about reliable reallocation control is made here.

4. Post-exploitation impact. Class-dependent outcomes are: (a) crash/denial of service from invalid dereference of the freed region, which is the most likely outcome for a use-after-free reached via a hard-to-shape remote path; (b) heap metadata corruption enabling further primitive development; or (c) information disclosure if freed memory containing sensitive record plaintext, keys, or pointers is subsequently read and returned. Only (a) can be considered the default expectation given the available evidence; (b) and (c) require offset and allocator control that is not documented.

Impact Assessment

No CVSS score or vector was published by the assigning authority or NVD at the time of writing, so no subscores can be referenced. Impact must therefore be reasoned qualitatively:

• Memory safety class: CWE-416 heap-use-after-free is a high-severity class in aggregate; consequences range from remote denial of service to code execution depending on exploitability.
• Reachability: Affects "all builds that make use of (D)TLS, including default builds," per the description — a broad blast radius across wolfSSL's embedded, IoT, industrial, automotive, and appliance customer base.
• Attacker position: Requires a network peer capable of participating in the shutdown handshake and continuing to send data during shutdown. No local access, credentials, or prior authentication factors are implied by the description.
• Application dependencies: Exploitation requires the application to (i) use a small buffer yielding a partial wolfSSL_read(), (ii) perform a bidirectional wolfSSL_shutdown(), and (iii) call wolfSSL_read() again mid-shutdown. Deployments matching this pattern are the affected subset; others may be unreachable in practice even though the library code is unpatched everywhere.
• Business impact: For IoT/embedded fleets, a heap corruption primitive in the TLS stack can translate into device takeover, lateral movement into management networks, or mass denial of service. Patching is complicated by firmware update logistics.
• Exploit availability: None public. EPSS is not scored by FIRST.org in the supplied data; no KEV listing; no Nuclei template.

Detection Guidance

Sigma Rule

title: Potential wolfSSL Heap-Use-After-Free Shutdown Trigger (CVE-2026-15442)
id: 9f3c1a74-2b6e-4d51-8e0a-7c1f5b2d9a03
status: experimental
description: Detects application crash/abort patterns consistent with a heap corruption in processes linked against wolfSSL during TLS shutdown with continued peer data.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-15442
author: valtersit.com
date: 2026/01/01
logsource:
  category: process_creation
  product: linux
detection:
  selection_binary:
    Image|endswith:
      - '/wolfssl'
      - '/wolfsslserver'
  selection_crash:
    CommandLine|contains:
      - 'heap-use-after-free'
      - 'AddressSanitizer'
      - 'SIGABRT'
  condition: selection_binary and selection_crash
falsepositives:
  - Debug builds with sanitizers in CI pipelines
level: medium
tags:
  - attack.t1499
  - cwe.416

YARA Rule

rule CVE_2026_15442_wolfSSL_heap_uaf_markers
{
    meta:
        description = "Detects heap-use-after-free related strings in wolfSSL-linked binaries and crash dumps associated with TLS shutdown handling"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-15442"
        author = "valtersit.com"
        date = "2026-01-01"
        cwe = "CWE-416"

    strings:
        $lib  = "wolfSSL" ascii wide
        $f1   = "wolfSSL_read" ascii
        $f2   = "wolfSSL_shutdown" ascii
        $asan = "heap-use-after-free" ascii
        $tls1 = "(D)TLS shutdown" ascii nocase

    condition:
        uint16(0) == 0x5A4D or uint32(0) == 0x464C457F
        and $lib
        and 1 of ($f1, $f2)
        and 1 of ($asan, $tls1)
}

Suricata IDS Rule

alert tcp any any -> any any (msg:"CVE-2026-15442 wolfSSL TLS shutdown continued-data heap-use-after-free attempt"; flow:established,to_server; content:"|17 03 03|"; depth:3; byte_test:2,>,0,0,relative; pkt_data; threshold:type both, track by_src, count 30, seconds 10; classtype:attempted-dos; reference:cve,2026-15442; sid:2026154420; rev:1;)

Note: The rule above targets the observable network condition described — a peer continuing to transmit TLS application-data records (0x17 0x03 0x03) after shutdown initiation at an elevated rate, which is the precondition the NVD description calls out. It is an anomaly-rate heuristic, not a signature of a specific byte sequence, because the provided data specifies no malicious payload format.

Elastic Detection

process where process.name in ("wolfssl", "wolfsslserver") and
  process.command_line : ("*heap-use-after-free*" or "*AddressSanitizer*") and
  event.action == "process_crash"

Expanded EQL sequence detecting the application read/shutdown/read pattern followed by an abnormal termination in the same process:

sequence by host.id, process.entity_id with maxspan=10s
  [ network where network.transport in ("tcp","udp") and
      process.name : ("wolfssl", "wolfsslserver") ]
  [ process where event.action == "process_crash" and
      process.name : ("wolfssl", "wolfsslserver") ]

Splunk SPL Query

index=main sourcetype=syslog OR sourcetype=linux_secure
("wolfSSL_read" OR "wolfSSL_shutdown" OR "wolfssl")
AND ("heap-use-after-free" OR "AddressSanitizer" OR "use-after-free" OR "SIGSEGV" OR "SIGABRT")
| stats count min(_time) as first_seen max(_time) as last_seen values(host) as hosts by process_name, message
| where count > 0
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="wolfssl,cve-2026-15442,">
  <rule id="100642" level="10">
    <decoded_as>syslog</decoded_as>
    <match>heap-use-after-free|use-after-free|AddressSanitizer</match>
    <description>CVE-2026-15442: Possible wolfSSL heap-use-after-free during TLS shutdown</description>
    <mitre>
      <id>T1499</id>
    </mitre>
  </rule>
  <rule id="100643" level="12">
    <if_sid>100642</if_sid>
    <match>wolfSSL_read|wolfSSL_shutdown</match>
    <description>CVE-2026-15442: Confirmed wolfSSL shutdown-path heap corruption crash</description>
    <mitre>
      <id>T1499</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, advisory, or workaround has been published in the supplied data. Until a fixed release is available, the following controls are recommended:

1. Immediate mitigations

   • Audit application code for the exact pattern named in the description: a wolfSSL_read() returning a partial read (commonly due to a small caller-supplied buffer), followed by wolfSSL_shutdown() for a bidirectional close, followed by another wolfSSL_read(). Where this pattern exists, sequence the final read only after confirming shutdown has fully completed, and stop reading once shutdown is initiated.
   • Increase the user-supplied read buffer so that complete records can be consumed in a single wolfSSL_read() call, eliminating the partial-read precondition the description identifies as the common trigger.
   • Consider unidirectional shutdown (wolfSSL_shutdown() semantics that do not solicit a peer Close-Notify exchange) if the library build permits, reducing the window in which the peer can continue sending data.
   • Deploy network anomaly monitoring for peers that continue transmitting TLS application data during close (see Suricata rule above).
   • For embedded fleets, consider temporarily restricting inbound TLS/DTLS session termination handling at the edge (network ACLs against untrusted peers where operationally feasible).

2. Patch / upgrade steps

   • Monitor wolfSSL release channels and GitHub security advisories for a fix commit and fixed release version.
   • When a fixed version ships, inventory all static and dynamic linkages to the wolfSSL library (including firmware images, container base layers, and vendored copies in third-party SDKs) and rebuild/relink. wolfSSL is frequently statically linked, so OS package updates alone will not remediate applications that vendor the library.
   • Re-run the code pattern audit after upgrade to confirm the application-side call sequence is also corrected.

3. Long-term hardening

   • Build TLS-consuming binaries with AddressSanitizer or equivalent in pre-production to catch use-after-free regressions introduced by the described call interleavings.
   • Adopt a lifecycle policy that terminates reads once shutdown begins; treat read-after-shutdown as a programming error to be caught in code review.
   • Maintain a software bill of materials (SBOM) covering embedded crypto libraries, including vendored copies, to shorten response time for unpatched TLS-stack CVEs.
   • Fuzz the (D)TLS shutdown state machine at the integration layer (application read loop + library shutdown + adversarial peer), since the defect lives at the boundary between the two.

References

• NVD — CVE-2026-15442: https://nvd.nist.gov/vuln/detail/CVE-2026-15442
• MITRE CWE-416 — Use After Free: https://cwe.mitre.org/data/definitions/416.html
• wolfSSL security advisories (monitor for a fix commit): https://www.wolfssl.com/security/
• wolfSSL project repository (track for patch commits): https://github.com/wolfSSL/wolfssl
• CISA Known Exploited Vulnerabilities Catalog (no entry as of writing): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No exploit-in-the-wild evidence, threat actor campaign, EPSS score, or public proof-of-concept was identified in the supplied intelligence data for CVE-2026-15442.