OpenSSL Fixes 14 Vulnerabilities in September 29, 2026 Advisory: What Businesses Should Check

On September 29, 2026, the OpenSSL project published a security advisory covering 14 vulnerabilities and released fixed versions across all of its supported branches. One of the issues is rated high severity, one moderate and the remaining twelve low.

OpenSSL is the encryption library behind a large share of HTTPS connections, and most businesses never install it deliberately. It arrives inside the server operating system, the web server, the language runtime and the container images that your application is built on. That is why an OpenSSL advisory is less a question of "do we use it" and more a question of "where is it, and who updates it". For companies that depend on a partner for web and mobile software development, it is a good moment to check how those lower layers are maintained.

This article summarizes what the advisory says, which versions contain the fixes, and what to ask your developers or hosting provider. It also flags two support deadlines that fall in the next few weeks.

What OpenSSL published on September 29, 2026

The OpenSSL security advisory of September 29, 2026 and the project's vulnerabilities page list 14 CVEs. The fixed releases for the publicly supported branches are:

• OpenSSL 4.0: fixed in 4.0.3
• OpenSSL 3.6: fixed in 3.6.5
• OpenSSL 3.5 (long-term support): fixed in 3.5.9
• OpenSSL 3.4: fixed in 3.4.8

Fixes also exist for the older 3.0, 1.1.1 and 1.0.2 branches (3.0.23, 1.1.1zj and 1.0.2zs), but the advisory marks those as available to premium support customers only. Not every CVE affects every branch, so the vulnerabilities page is the place for your developers to check their exact version.

The advisory does not report that any of these issues is being exploited.

The high severity issue: DTLS

The one high severity item is CVE-2026-84782. According to the advisory, it is an error in how OpenSSL retransmits handshake messages in DTLS, and it can cause a server or client to disclose a portion of its own memory to the other party or to crash. It affects every branch from 1.0.2 through 4.0.

The key detail for a business reader is the protocol. DTLS is the variant of TLS used over UDP rather than TCP. An ordinary website or API served over HTTPS uses TLS, not DTLS, and is not exposed to this particular bug through its normal web traffic. DTLS typically appears in real-time audio and video (WebRTC), some VPN products, and device-to-server communication in connected hardware.

So the realistic position is this: if your product includes video calling, live streaming, voice features, a VPN component or communication with physical devices, this fix deserves prompt attention and a direct question to your developers. If your software is a conventional website, web application or mobile app backend, the high severity item is unlikely to be reachable, but the update should still go through your normal patching cycle.

The moderate issue and the low severity group

The moderate item, CVE-2026-84783, affects OpenSSL 4.0 only. The advisory describes a memory-safety error in certificate handling when several threads use the same certificate at once, and says a remote, unauthenticated peer could crash a multi-threaded TLS client, or a multi-threaded TLS server that requests client certificates. That is a denial of service risk for teams that have already moved to the 4.0 branch; 3.6 and earlier are listed as unaffected.

Most of the twelve low severity issues sit in OpenSSL's QUIC implementation, the transport underneath HTTP/3, and involve ways a remote peer could make a process use more memory or CPU than it should. Others are timing side channels in specific elliptic curve and SM2 operations, plus a DTLS issue where a single malformed packet can end a connection. None of these is alarming on its own, which is why they are rated low, but they are a reminder that newer protocol features carry their own maintenance cost.

Two support deadlines that matter more than they look

OpenSSL's release strategy page lists the end-of-support dates for each branch. Two of the four publicly supported branches reach their end very soon: OpenSSL 3.4 is supported until October 22, 2026, and OpenSSL 3.6 until November 1, 2026. OpenSSL 4.0 is supported until May 14, 2027, and the 3.5 long-term support branch until April 8, 2030.

The same page states that 3.0, 1.1.1 and 1.0.2 are no longer supported by the project, with extended support available commercially. In other words, if someone on your team compiled or bundled OpenSSL 3.4 or 3.6 directly, the fix they install this month may be one of the last free ones for that branch. For anything expected to run for years, 3.5 is the branch with the long support commitment.

What this means for your business

Most companies receive OpenSSL second-hand. A Linux distribution packages its own build and publishes its own security updates. A language runtime such as Node.js or Python may bundle or link its own copy. A container image freezes whatever version was current on the day it was built. A mobile app may ship an encryption library inside the app itself. Each of those has a different owner and a different update path.

This has two consequences. First, the version number alone can mislead. Distribution maintainers commonly apply security fixes to an older version number rather than moving to a new upstream release, so "we are on 3.0" does not automatically mean "we are unpatched". The reliable check is the security notice from whoever supplied the build. Second, the copies most likely to be forgotten are the ones nobody updates automatically: old container images, statically linked binaries, and third-party appliances or SDKs.

In our view, the value of this advisory for a non-technical owner is as a test of the maintenance process. A team that can answer "where does OpenSSL come from in our stack" in an afternoon is in good shape. A team that cannot will struggle the day a critical advisory lands.

What to ask your developers or hosting provider

These questions cover the ground without requiring you to read the advisory yourself:

• Does any part of our product use DTLS, for example WebRTC calling, a VPN component or device communication? If so, when will the September 29 fixes be deployed?
• Where does OpenSSL come from on our servers: the operating system, the language runtime, a container base image or our own build? Who applies updates to each?
• Has our operating system or cloud provider published its own update for this advisory, and is it installed?
• When were our container images last rebuilt, and do we rebuild them on a schedule or only when code changes?
• Are we running any OpenSSL branch that is out of support or about to be, such as 3.4 or 3.6 built from source?

If you use managed hosting or a platform service, much of this is the provider's responsibility, and the right step is to ask them for their statement on the advisory. If your team runs its own servers, expect a routine operating system update and a restart of the affected services, since a running process keeps using the old library until it is restarted.

Conclusion

The September 29, 2026 OpenSSL advisory fixes 14 issues, of which one is high severity and limited to DTLS, with patched releases 4.0.3, 3.6.5, 3.5.9 and 3.4.8 available now. For most websites and web applications this is a scheduled patch rather than an emergency. The more durable takeaways are the approaching end of support for the 3.4 and 3.6 branches and the need to know which copies of OpenSSL your software depends on.

If you would like a second opinion on how your servers, containers and application dependencies are kept up to date, Entrant Technologies builds and maintains web applications, mobile apps and custom software. You can request a quote for a review or ongoing maintenance.