# CVE-2026-15442: wolfSSL heap-use-after-free in TLS shutdown

Source: https://junglewise.ai/threats/cve-2026-15442-in-all-builds-that-make-use-of-d-tls-including-default-builds  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-09-27. Updated: 2026-09-27  
License: CC BY 4.0 with a link back

CVE-2026-15442 · Severity: info · Published 2026-09-27

wolfSSL is a cryptographic library used to secure network communications via TLS/DTLS. Under specific conditions during TLS connection shutdown—when an application reads partial data into a small buffer, initiates shutdown, and attempts to read again while the peer sends data—a heap-use-after-free vulnerability can occur, potentially leading to memory corruption or information disclosure.

Technologies: [Wolfssl](https://junglewise.ai/threats/technologies/wolfssl). Vendors: [Wolfssl](https://junglewise.ai/threats/vendors/wolfssl).

## Quick answers

**Is CVE-2026-15442 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-15442 being exploited in the wild.

**How severe is CVE-2026-15442?** Informational severity, published 27 September 2026.

**Which products and versions are affected?** wolfSSL wolfSSL.

**Is there a fix for CVE-2026-15442?** No fixed version is recorded yet. Check the vendor's advisory in the references below. If you run it, Junglewise drafts a mitigation that fits your setup and applies it once you approve, with senior security engineers behind it.

**How is CVE-2026-15442 attacked?** It is attacked over the network.

**Am I affected by CVE-2026-15442?** Check whether you run Wolfssl. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## Technical details

A heap-use-after-free occurs in wolfSSL's TLS shutdown sequence when specific conditional states are reached: a partial wolfSSL_read() with a small user buffer, followed by wolfSSL_shutdown() for bidirectional close, and another wolfSSL_read() attempt while the peer continues sending data. This requires application-level interaction and specific timing but affects all builds using (D)TLS by default. A fix has been merged upstream.

## Affected products

- wolfSSL wolfSSL

## References

- [https://github.com/wolfSSL/wolfssl/pull/10863](https://github.com/wolfSSL/wolfssl/pull/10863)

## Related threats

- [wolfSSL certificate validation bypass in ConfirmNameConstraints()](https://junglewise.ai/threats/cve-2026-95208-an-issue-in-the-confirmnameconstraints-function-wolfcrypt-src-asn)
- [wolfSSL revocation check bypass with OCSP and CRL](https://junglewise.ai/threats/cve-2026-94417-when-an-application-enables-both-ocsp-and-crl-revocation-checking)
- [wolfSSL TLS 1.2 ChangeCipherSpec message ordering bypass](https://junglewise.ai/threats/cve-2026-93304-a-d-tls-1-2-client-can-accept-a-changecipherspec-message-before)
- [wolfSSL MatchTrustedPeer public key validation bypass](https://junglewise.ai/threats/cve-2026-93302-matchtrustedpeer-ignores-the-public-key-used-leading-to-forged-ca)
- [wolfSSL TLS authentication bypass in Raw Public Key handling](https://junglewise.ai/threats/cve-2026-89136-when-using-rpk-raw-public-key-the-client-side-of-a-tls-1-2-1-3)