Vulnerabilities fixed in OpenSSL: 14 (Source: SecurityWeek (September 30, 2026))
A patch release is a list of ways software can fail. In this OpenSSL release, several entries share a shape: a small input from a remote peer makes the receiving software spend far more memory or processor time. The conditions differ from bug to bug, and most of the fixes carry a low rating. Still, the shared shape is worth understanding.
OpenSSL is an open-source cryptography library. Encrypted connections in a wide range of software depend on it. SecurityWeek reports that its developers fixed 14 vulnerabilities. One is rated high, one medium and the rest low. SecurityWeek says the low-rated flaws mostly lead to denial of service, meaning a service slows down or stops.
Small input, large work on the receiver
The high-rated flaw and the medium-rated flaw are covered below. Neither is one of the resource bugs in this section. SecurityWeek's counts (one high, one medium, the rest low) suggest these sit in the low group, though the text we reviewed does not rate each one.
The clearest case involves certificates. OpenSSL says a certificate that fits under the roughly 100 KiB size limit can lead to several hundred MiB of memory in use on the receiving side. This happens during a normal TLS handshake, the setup step of an encrypted connection.
The cause is a cache for certificate extensions. A certificate with many CRL distribution points, which say where to find revocation lists, makes the cache grow out of proportion.
The conditions matter here. OpenSSL describes the impact as affecting clients, or servers that ask clients for certificates. A crash needs multiple concurrent connections that each cause a large allocation. The fix delays processing of that extension until the value is needed.
Three QUIC flaws add to the pattern. QUIC is a newer transport protocol. Each has its own preconditions.
In the first, a QUIC server lets a peer that has completed the handshake force slow, list-searching work. OpenSSL calls the worst case quadratic. The peer needs little bandwidth. In the second, a peer can keep packet buffers in memory for as long as it chooses.
In the third, OpenSSL enforced a per-stream limit but not the connection-level flow control limit. A malicious peer could make the stack receive about 100 MB instead of the 768 KiB default window. OpenSSL says three conditions must be met to exploit this. The text we reviewed cuts off before listing them. We cannot say how hard the flaw is to use.
What the pattern does and does not show
This pattern shows something about design. When software accepts input from outside, the cost of handling that input falls on the receiver. If nothing caps that cost, a small message can make a large demand. That is our interpretation, not a claim in the advisories.
The advisories do not say how much an attacker spends or how much a defender spends. They describe resource use on the receiving side. They also show that each flaw needs its own conditions: a completed handshake, several simultaneous connections, or a particular configuration.
The more severe items are different in kind
The one high-rated flaw is CVE-2026-84782, with a CVSS score of 8.2. It affects DTLS, a version of TLS that runs over UDP. SecurityWeek says DTLS is common in VPNs, VoIP and IoT products. It also reports that an attacker can reach this flaw across the network, with no login and no action from a user.
OpenSSL explains the cause. A handshake message can be sent in pieces, and a send can pause when the network is busy. If the retransmission timer fires during that pause, the resend reads from the wrong buffer position. The result can be heap memory sent to the peer in plaintext, or a crash.
SecurityWeek also lists CVE-2026-84783, a medium flaw that lets a remote, unauthenticated peer crash a multi-threaded TLS client. It says the low-rated fixes also include QUIC servers being used to amplify DDoS attacks, and timing side channels that could lead to private key recovery.
OpenSSL sets limits on the timing leak in elliptic-curve signing. It needs a large number of measurements. It sits in the fallback code for curves without a dedicated implementation. OpenSSL lists P-256, P-384 and P-521 as unaffected.
Other flaws need narrow conditions. One crash requires a malicious or compromised CMP server. An out-of-bounds read needs an unusual setup, and OpenSSL rated it low. For each issue we reviewed, OpenSSL says FIPS modules are not affected. The text we reviewed did not include every affected-version list, so teams should check those directly.
WolfSSL: same inventory problem, different flaws
We include WolfSSL because the same question applies: do you know which cryptography library sits inside which product? WolfSSL is a separate library. Its version 5.9.4 shipped on September 25. SecurityWeek reports it fixes 11 vulnerabilities, three rated high. These are authentication flaws, not resource-use bugs, and each has conditions.
CVE-2026-93302 comes from ignoring the public key when matching a certificate to a trusted one. SecurityWeek reports that a rogue server, if it knows which certificate authorities (CAs) a client trusts, could present an imitation of one and get past the client's authentication check. Affected builds include those made for Nginx, HAProxy, Stunnel and Apache httpd.
CVE-2026-89102 involves someone who legitimately holds a certificate and its private key, issued under a CA the client trusts. According to SecurityWeek, that person could forge certificates in the names of other identities. CVE-2026-89136 needs a malicious server and a client with Raw Public Key support enabled. The server selects a certificate type the client never requested.
What to ask your team
The hard part is not the patch. It is knowing where these libraries live. They sit inside web servers, VPN gateways, appliances and vendor products that may not list them.
Ask five questions. First, which of our systems use OpenSSL or WolfSSL, including inside products we buy? Second, do we run DTLS or QUIC anywhere on the internet edge? Third, which OpenSSL branch is each system on, and is it supported? OpenSSL's notice says versions before 1.1.1 get no updates. Only 1.0.2 has paid extended support.
Fourth, do any of our WolfSSL builds match certificates against trusted ones, or use Raw Public Key support? Fifth, do we watch memory and CPU use in services that accept certificates or connections from outside?
Patching fixes these specific bugs. The wider point, in our view, is that any service taking outside input benefits from limits on what that input can make it spend. Ask your teams where those limits exist.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OpenSSL.
