Vulnerabilities

OpenSSL published a security advisory on September 29 covering 14 vulnerabilities: one high, one moderate and twelve low. The high one, CVE-2026-84782 (CVSS 8.2), lets a remote peer read fragments of heap memory or crash the process, without logging in, but only in applications that use DTLS. Four days earlier, on September 25, wolfSSL released 5.9.4 with fixes for 11 flaws, three of them high severity and two of those letting an attacker get a forged certificate accepted.

Neither project, nor any of the outlets covering the fixes, reports exploitation in the wild. The work this week is mostly inventory: both libraries end up inside software that never shows up as "OpenSSL" or "wolfSSL" in a package list.

How the OpenSSL DTLS bug works

DTLS (Datagram Transport Layer Security) is TLS adapted to run over UDP. Because UDP drops packets without telling anyone, DTLS keeps a copy of each handshake message and resends it when a retransmission timer fires and no reply has arrived.

The bug sits where that timer meets non-blocking I/O. In non-blocking mode, when the network layer cannot take more data, OpenSSL stops writing partway through a message and returns WANT_WRITE, meaning "call me again when the socket is ready". If the retransmission timer fires while that write is suspended, the resend reuses the half-written message's buffer and position tracking without resetting the position to the start. The resend begins at a stale offset, picks up leftover bytes from a different message and keeps reading past the end of the buffer.

Whatever heap memory sits past that buffer goes to the peer as plaintext handshake data. If the read reaches unmapped memory, the process crashes instead.

The flaw affects OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2, but only in applications using DTLS with non-blocking I/O. Red Hat points out that ordinary TLS over TCP, used by most web servers, mail servers and API clients, never touches this retransmission path.

The moderate flaw, CVE-2026-84783, is a use-after-free in OpenSSL's cache of decoded X.509 certificate extensions. When several threads use the same certificate for the first time at once, one thread can free cached values that another is still reading. A remote, unauthenticated attacker who opens concurrent connections can crash multi-threaded TLS clients, and servers that verify client certificates. It affects only the 4.0 branch.

How the wolfSSL flaws work

wolfSSL is a small TLS library aimed at embedded devices, and it also offers an OpenSSL compatibility layer so servers written for OpenSSL can be built against it. The three high-severity bugs all depend on build options and API calls, so whether you are exposed comes down to how your copy was compiled:

• CVE-2026-93302 affects builds with WOLFSSL_TRUST_PEER_CERT that load certificates through wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). The trusted-peer match ignores the public key, so an attacker who knows which CA certificates you trust can present a forged clone that passes verification. The wolfSSL release notes name builds for nginx, HAProxy, stunnel, Apache httpd, BIND and rsyslog. Versions 5.3.0 to 5.9.2 are affected.
• CVE-2026-89102 affects clients that use multiple OCSP response stapling (RFC 6961), enabled with HAVE_CERTIFICATE_STATUS_REQUEST_V2 and wolfSSL_UseOCSPStaplingV2() in multi mode. Such a client accepts any certificate in the server's chain as a certificate authority. An attacker holding one certificate and private key that chain to a trusted CA can then issue certificates for any name. Versions 5.7.2 to 5.9.2.
• CVE-2026-89136 affects clients built with Raw Public Key (RPK) support, which uses a bare public key in place of a certificate. A malicious server can send an RPK the client never asked for and skip X.509 chain validation altogether, over TLS 1.2, TLS 1.3 or DTLS 1.2. RPK is off by default but comes in with --enable-rpk, --enable-all and --enable-distro. Versions 5.6.0 to 5.9.2.

The four medium-severity fixes cover more certificate checking: name constraints that can be bypassed (CVE-2026-89133, CVE-2026-89134), a failed verification that leaves an unverified CA in the shared certificate store (CVE-2026-89135), and a TLS 1.2 or DTLS 1.2 client that accepts ChangeCipherSpec too early (CVE-2026-93304).

What attackers are doing

Nothing confirmed so far. None of the sources report exploitation or a public exploit for any of these CVEs as of October 1. CVE-2026-84782 is the one to watch, since it needs no credentials and leaks memory. The wolfSSL certificate flaws need an attacker in the network path or a malicious server, so they matter most for devices that connect out to services over networks you do not control.

What to do

1. Upgrade OpenSSL to 4.0.3, 3.6.5, 3.5.9 or 3.4.8. Fixes for 3.0 (3.0.23), 1.1.1 (1.1.1zj) and 1.0.2 (1.0.2zs) go to premium support customers only. On a Linux distribution, take the vendor's patched package; distributions backport fixes, so the version string will not match upstream.
2. Upgrade wolfSSL to 5.9.4 wherever you build it yourself, and ask device and appliance vendors when their firmware will ship it.
3. Restart whatever loaded the old library. A process keeps the old copy mapped until it restarts. On Debian and Ubuntu, needrestart lists those services after an upgrade.
4. If you cannot patch today, start with UDP. ss -ulpn lists UDP listeners and their processes; any of them linked to OpenSSL and speaking DTLS is in scope for CVE-2026-84782, and restricting those ports to known peers narrows who can reach the bug. For wolfSSL, check whether your code calls the trusted-peer APIs or enables OCSP stapling v2 or RPK. If it does not need them, rebuilding without them removes the high-severity paths.
5. Check for crashes. The DTLS bug leaves no specific log entry, and memory read by a peer leaves no trace on the host. Unexpected restarts or segfaults in DTLS-speaking services since late September (journalctl -k | grep -i segfault, or coredumpctl list) are the closest signal.

Finding every copy

The system package is the easy part. dpkg -l | grep -Ei 'libssl|wolfssl' or rpm -qa | grep -Ei 'openssl|wolfssl' covers it, and openssl version only reports the copy behind the command-line tool, not what each application uses.

Dynamically linked programs show up with ldd /path/to/binary | grep -E 'libssl|libwolfssl'. For everything running right now, lsof -n | grep -E 'libssl|libwolfssl' | awk '{print $1}' | sort -u lists the processes that have either library mapped.

Statically linked binaries are invisible to both checks. Security agents, backup clients, VPN clients and many vendor tools bundle their own TLS library. Run strings -a /path/to/binary | grep -Ei 'openssl [0-9]|wolfssl' against the binaries you care about to find an embedded version string. On Windows, search for bundled DLLs with Get-ChildItem C:\ -Recurse -Include libssl*.dll,libcrypto*.dll,wolfssl*.dll -ErrorAction SilentlyContinue and check each file's version.

Containers carry their own copy in each image. An SBOM (software bill of materials) tool such as syft <image> lists the OpenSSL or wolfSSL package inside, and the fix is rebuilding the image on a patched base. Language runtimes can bundle their own too: python3 -c "import ssl; print(ssl.OPENSSL_VERSION)" and node -p process.versions.openssl show what they actually use.

Servers often report it themselves: nginx -V prints the TLS library it was built with, and haproxy -vv shows both the build and the runtime version. Firewalls, VPN gateways, phones and IoT devices cannot be inspected this way; list them and chase each vendor for its advisory.

Keep what this search turns up. SBOMs for your images and a list of which appliances embed which TLS library turn the next advisory into a lookup. If you want help building that inventory, our attack surface management service maps what you run and what it exposes, and our on-demand risk reduction team can work through a patch backlog with you. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: OpenSSL security advisory, September 29, 2026, OpenSSL vulnerabilities list, wolfSSL 5.9.4 release notes, SecurityWeek, SecurityOnline, eSecurity Planet, Red Hat on CVE-2026-84782, Cybersecuritynews on wolfSSL 5.9.4.