OpenSSL 3.4 Support Ended 22 October; OpenSSL 3.6 Ends 1 November 2026

OpenSSL 3.4 reached the end of upstream support on 22 October 2026, and OpenSSL 3.6 follows on 1 November. The last releases are 3.4.8 and, so far, 3.6.5. Upstream now maintains 3.5 LTS, 4.0 and the new 4.1. If you build, bundle or install OpenSSL yourself, move to 3.5.9 or 4.0.3 now.

Most servers running a long-term distribution will not notice either date, because the distribution ships and patches its own OpenSSL package on its own schedule. The exposure sits elsewhere: developer machines with Homebrew, rolling and testing distributions, C and C++ builds that vendor the library through vcpkg or Conan, Rust crates that compile OpenSSL in, and container images built from a rolling base and never rebuilt.

This guide covers what the OpenSSL release strategy says and how the two dates played out, the exact last releases and checksums, the security advisories that 3.4 and 3.6 received in their final months, where each line actually ships today with package versions, a checker script with real output from a developer Mac, the commands to check and migrate on each platform, and the API changes to expect if you move to 4.0 rather than 3.5.

The short answer

OpenSSL 3.4 is no longer supported upstream as of 22 October 2026. Its last release is 3.4.8, published on 29 September 2026. As of 24 October, the OpenSSL downloads page no longer lists 3.4 in its table of current releases.

OpenSSL 3.6 support ends on 1 November 2026. Its latest release is 3.6.5, also from 29 September. Non-LTS releases from 3.5 onward get 13 months of full support, which is why 3.6, released on 1 October 2025, ends only ten days after 3.4.

Upstream now supports three lines: 3.5 LTS until 8 April 2030, 4.0 until 14 May 2027, and 4.1, released on 23 October 2026, until November 2027. 3.0 LTS public support ended on 7 September 2026; 1.1.1 and 1.0.2 ended earlier. Paid extended support is available for older lines from the OpenSSL Corporation.

What to do: if your OpenSSL comes from a distribution package, follow that distribution's security updates. If you build, vendor or install it yourself, move off 3.4 now and off 3.6 before 1 November. 3.5.9 is the conservative target. 4.0.3 or 4.1.0 are fine if you can take the API changes and the shorter windows.

What happened

Timeline

What changed since our first draft on 20 October

We drafted this post on 20 October, two days before the 3.4 cutoff. Several things have moved since.

1. OpenSSL 4.1.0 shipped on 23 October. It adds DTLS 1.3 (RFC 9147), RFC 8701 GREASE, DTLS support in the SSL listener API and an IKEv2 KDF. Its end of life is listed as November 2027. It is a non-LTS release, so it does not change the advice for teams that want long support.
2. The downloads page now omits 3.4. Its table of latest releases lists 4.1, 4.0, 3.6 and 3.5, with a note that versions not listed are out of support. The release strategy page itself still reads "will be supported until 2026-10-22" for 3.4, because it was last edited in May.
3. The OpenSSL Corporation lifecycle page is out of date. As of 24 October it still lists 3.0 and 3.4 as Supported and 4.1 as Planned. Where it disagrees with openssl-library.org, we follow the library site and the release strategy.
4. Node.js moved to OpenSSL 3.5.9. The 20 and 21 October security releases of Node.js 22, 24 and 26 all bundle 3.5.9. Our first draft cited 3.5.8 for Node.js 22 and 24.
5. Homebrew's Python moved again. python@3.14 is now 3.14.9 and depends on openssl@4. The openssl@3.6 formula carries a Homebrew deprecation date of 2026-11-01 and a disable date of 2027-11-01.
6. Nix unstable switched its default. Repology now lists Nix unstable's default openssl attribute at 3.5.9, with 3.6.5 kept as openssl_3_6. Nix 26.05 still defaults to 3.6.5.

What the release strategy says

The OpenSSL release strategy, first issued in December 2014 and last modified on 7 May 2026, sets these rules for 3.0 and later.

• Versioning. MAJOR.MINOR.PATCH. API and ABI compatibility is guaranteed within a major version. Minor releases add features compatibly; patch releases fix bugs and may backport accessor functions.
• Cadence. A new release every six months, in April and October. From 3.5, an LTS every two years. From 5.0 in October 2027, a major release every two years, six months after each LTS.
• LTS support. At least five years. In the final year, only security fixes are committed. There are always two fully supported LTS releases, and an LTS lands every April in odd-numbered years.
• Non-LTS support. Releases up to 3.4 got at least two years. In the page's words, "Non-LTS releases after 3.5 will be full supported for 13 months."
• Current dates. 4.0 until 2027-05-14, 3.6 until 2026-11-01, 3.5 until 2030-04-08 (LTS), 3.4 until 2026-10-22. Versions 3.0, 1.1.1 and 1.0.2 are no longer supported, with paid extended support available.

That change in non-LTS length is the whole reason for the ten-day gap. 3.4 was released in October 2024 under the old two-year rule. 3.6 was released in October 2025 under the new 13-month rule. Both clocks run out at almost the same time.

The same rules mean the 4.x line moves quickly. 4.0 ends in May 2027, 4.1 in November 2027, and 4.2 in April 2027 is planned as the next LTS. A team that wants one migration and then five quiet years should target 3.5 now and 4.2 later.

Who is affected

The rule of thumb: if someone else's security team publishes updates for the package you install, their support policy is the one that matters. If nobody does, the upstream dates apply to you directly.

Technical details

This section holds the exact versions, dates, checksums, advisories and package data behind the summary.

Supported lines and latest releases, 24 October 2026

From the openssl-library.org downloads page:

The checksums are the contents of the .sha256 files published alongside each tarball on the project's GitHub releases. The downloads page says current releases are signed by the OpenSSL signing certificate with primary key fingerprint B146 647E 45A7 B339 47AB 226B 2A2C 87D1 6169 2D40. The earlier key, BA54 73A2 B058 7B07 FB27 CF2D 2160 94DF D0CB 81EF, is retired but still published so older releases can be verified, and it cross-certifies the new certificate.

Every 3.4 and 3.6 release

As of 24 October there is no announced 3.6.6. OpenSSL releases are driven by security fixes rather than a fixed date, so if one ships before 1 November it would be the last 3.6 release. If not, 3.6.5 is the last.

The last advisory both lines received: 29 September 2026

The OpenSSL security advisory of 29 September 2026 lists 14 CVEs. One is High, one Moderate and twelve Low. 3.4 is affected by 12 of them and 3.6 by 13.

Fixed versions named in the advisory: 4.0.3, 3.6.5, 3.5.9 and 3.4.8. For 3.0, 1.1.1 and 1.0.2, the advisory lists 3.0.23, 1.1.1zj and 1.0.2zs under "Premium support customers only." According to the advisory, the High DTLS issue was reported on 17 August 2026 by Laurent Gaffie (secorizon.com) and fixed by Ryan Hooper; its affected code is outside the FIPS module boundary.

Our separate post on the September 2026 OpenSSL advisory goes through which of these are reachable in common deployments.

The advisory before that: 25 August 2026

The 25 August advisory lists nine CVEs: three Moderate and six Low. 3.6 is affected by all nine and 3.4 by eight; only the QUIC server double free on INITIAL packets (CVE-2026-18798) leaves 3.4 out. The Moderate issues are CVE-2026-18798 (QUIC server double free), CVE-2026-63072 (heap buffer overflow in CMS key unwrapping) and CVE-2026-63076 (invalid pointer dereference in the CMP server via a crafted protectionAlg). For this advisory, 3.0 users were still told to upgrade to the public 3.0.22, because 3.0 public support had not yet ended.

Put together: a build still on 3.4.6 or 3.6.3, from June, is missing 20 or more CVE fixes that its own line received before it ended. The end of life date is the second problem. Being several patch releases behind is the first.

Where 3.4 and 3.6 ship today

We checked each platform at its own source where one exists, and used Repology, an aggregator, for the rest. Versions as of 24 October 2026.

Three things stand out.

The rolling world is on 3.6. Arch, Debian testing and unstable, Kali, MSYS2 on Windows, Termux on Android and vcpkg for C and C++ all ship 3.6.5 today. Every one of them needs to move in the next week or carry a line upstream no longer patches.

The long-term distributions skipped 3.4 and 3.6 entirely. Debian 13, Ubuntu 26.04, Fedora, Alpine, AlmaLinux and Rocky Linux 9 and CentOS Stream ship 3.5, while Debian 12, Ubuntu 22.04 and 24.04 ship 3.0 with their own backported fixes. Ubuntu published USN-8847-1 for 26.04, 24.04 and 22.04 on 29 September, the same day as OpenSSL's advisory, and a further notice for 26.04, USN-8861-1, on 1 October. Upstream's dates do not describe what those systems get; their vendors' policies do.

Rust's vendored OpenSSL has a gap. The openssl-src crate embeds an OpenSSL source tree. Its 300.x line, which embeds 3.x, last published 300.6.1+3.6.3 on 9 June 2026. The current crate, 400.0.2+4.0.3, embeds 4.0.3. A Rust project that builds openssl-sys with the vendored feature and resolves a 300.x openssl-src is compiling in 3.6.3, which misses the August and September fixes. Check with cargo tree -i openssl-src.

What runtimes bundle

If you move to 4.0 instead of 3.5

4.0 is a major release, so API and ABI compatibility with 3.x is not guaranteed. The 4.0.0 entry in OpenSSL's NEWS.md lists these potentially significant or incompatible changes, among others:

• engines are removed entirely; OPENSSL_NO_ENGINE is always defined;
• SSLv3 and the SSLv2 Client Hello are removed;
• ASN1_STRING is now opaque;
• many function signatures, including X.509 ones, gained const qualifiers;
• deprecated fixed SSL and TLS version method functions are removed, as are custom EVP_CIPHER, EVP_MD, EVP_PKEY and EVP_PKEY_ASN1 methods;
• ERR_get_state(), ERR_remove_state() and ERR_remove_thread_state() are removed;
• deprecated RFC 8422 elliptic curves in TLS and explicit EC curves are disabled at compile time by default;
• the c_rehash script is removed in favor of openssl rehash;
• libcrypto no longer cleans up via atexit(), and OPENSSL_cleanup() runs in a global destructor or not at all by default;
• X509_cmp_time() and related functions are deprecated in favor of X509_check_certificate_times().

New in 4.0: Encrypted Client Hello (RFC 9849), RFC 8998 SM algorithms and the curveSM2MLKEM768 hybrid group, cSHAKE, ML-DSA-MU, SNMP and SRTP KDFs, deferred FIPS self tests and negotiated FFDHE in TLS 1.2 (RFC 7919).

4.1.0 adds DTLS 1.3, GREASE, DTLS in the listener API and an IKEv2 KDF, and drops the Windows on Itanium and Windows CE targets and the no-ecdsa and no-ecdh configure options. Its NEWS entry lists four known DTLS issues at release, including dropped post-handshake records after a DTLS 1.3 KeyUpdate. If you use DTLS, read those before choosing 4.1.

For most applications that moved to 3.x APIs years ago, 3.4 or 3.6 to 3.5 is a drop-in rebuild within the same major version. 3.x to 4.0 is a porting exercise for anything that used engines, custom methods or deprecated APIs.

The 3.0 situation

3.0 was the previous LTS. Its public support ended on 7 September 2026. 3.0.22, from 25 August, is the last public 3.0 release; the 29 September advisory offers 3.0.23 to premium support customers only. Debian 12 ships 3.0.22 with Debian's own patches, and Ubuntu 22.04 and 24.04 ship older 3.0 bases with Ubuntu's backports. That is normal and supported by those vendors. A 3.0 build you compiled yourself, however, is now in the same position as 3.4.

Check a machine

The script below reports the OpenSSL behind Python's ssl module, every openssl binary on the PATH (plus any you name), Node.js, Ruby, curl and pyca/cryptography when they are installed. It prints the upstream status of each line based on today's date. It tells you about the version line, not whether your vendor patches it. Standard library only.

#!/usr/bin/env python3
"""Report which OpenSSL each runtime on this machine uses, and its upstream status.

Checks Python's ssl module, every openssl binary on PATH (plus any given as
arguments), Node.js, Ruby, curl and pyca/cryptography when present. Upstream
end dates are from openssl-library.org (release strategy and downloads pages,
read 24 October 2026). A distribution may still patch a line that upstream has
dropped, so "ended" is a prompt to check your vendor, not proof of exposure.
Standard library only.

Usage: python3 openssl_lines.py [/path/to/openssl ...]
"""
import datetime
import os
import re
import shutil
import ssl
import subprocess
import sys

# line: (upstream end date, label)
UPSTREAM = {
    "4.1": (datetime.date(2027, 11, 30), "until Nov 2027"),
    "4.0": (datetime.date(2027, 5, 14), "until 2027-05-14"),
    "3.6": (datetime.date(2026, 11, 1), "until 2026-11-01"),
    "3.5": (datetime.date(2030, 4, 8), "LTS until 2030-04-08"),
    "3.4": (datetime.date(2026, 10, 22), "ended 2026-10-22"),
    "3.0": (datetime.date(2026, 9, 7), "LTS ended 2026-09-07"),
}
TODAY = datetime.date.today()


def status(text):
    if "LibreSSL" in text:
        return "LibreSSL, not OpenSSL: check its own policy"
    if "BoringSSL" in text:
        return "BoringSSL, not OpenSSL: tracks its embedder"
    m = re.search(r"OpenSSL[ /](\d+)\.(\d+)\.\d+", text)
    if not m:
        return "unrecognized"
    line = f"{m.group(1)}.{m.group(2)}"
    if line not in UPSTREAM:
        return f"{line}: upstream support ended; check your vendor"
    end, label = UPSTREAM[line]
    days = (end - TODAY).days
    if days < 0:
        return f"ENDED  {label}; check your vendor"
    if days <= 30:
        return f"SOON   {label} ({days} days left)"
    return f"ok     {label}"


def short(text):
    m = re.search(r"(OpenSSL|LibreSSL|BoringSSL)[ /][\d.]+[a-z]?", text)
    return m.group(0).replace("/", " ") if m else text[:24]


def run(cmd):
    try:
        out = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        return (out.stdout or out.stderr).strip()
    except (OSError, subprocess.TimeoutExpired) as e:
        return f"error: {e}"


def binaries(extra):
    found, seen = list(extra), set()
    for d in os.environ.get("PATH", "").split(os.pathsep):
        p = os.path.join(d, "openssl")
        if os.access(p, os.X_OK):
            found.append(p)
    for p in found:
        real = os.path.realpath(p)
        if real not in seen:
            seen.add(real)
            yield p


def report(name, text):
    print(f"{name:<26} {short(text):<16} {status(text)}")


def main():
    report("python ssl module", ssl.OPENSSL_VERSION)
    for b in binaries(sys.argv[1:]):
        report(b, run([b, "version"]))
    if shutil.which("node"):
        report("node", "OpenSSL " + run(["node", "-p", "process.versions.openssl"]))
    if shutil.which("ruby"):
        report("ruby", run(["ruby", "-ropenssl", "-e", "puts OpenSSL::OPENSSL_LIBRARY_VERSION"]))
    if shutil.which("curl"):
        report("curl", run(["curl", "-V"]).splitlines()[0])
    try:
        from cryptography.hazmat.backends.openssl.backend import backend
        report("pyca/cryptography", backend.openssl_version_text())
    except ImportError:
        print(f"{'pyca/cryptography':<26} not installed")


if __name__ == "__main__":
    main()

We ran it on 24 October on the same developer Mac we used for the first draft, a Homebrew machine that had not been upgraded for a few weeks:

$ python3 openssl_lines.py
python ssl module          OpenSSL 3.6.4    SOON   until 2026-11-01 (8 days left)
/opt/homebrew/bin/openssl  OpenSSL 4.0.3    ok     until 2027-05-14
/usr/bin/openssl           LibreSSL 3.3.6   LibreSSL, not OpenSSL: check its own policy
node                       OpenSSL 3.6.4    SOON   until 2026-11-01 (8 days left)
ruby                       OpenSSL 3.6.4    SOON   until 2026-11-01 (8 days left)
curl                       LibreSSL 3.3.6   LibreSSL, not OpenSSL: check its own policy
pyca/cryptography          OpenSSL 4.0.1    ok     until 2027-05-14

Seven runtimes, four different TLS libraries and versions, on one laptop.

• The openssl command says 4.0.3, but Python, Node.js and Ruby use 3.6.4. The installed Homebrew packages on this machine were Python 3.14.7, Node.js 26.7.0 and Ruby 4.0.6, all linked against the installed openssl@3, which was 3.6.4. otool -L /opt/homebrew/bin/node shows it loading /opt/homebrew/opt/openssl@3/lib/libssl.3.dylib.
• The current Homebrew formulae have moved on. openssl@3 is now 3.5.9, with version_scheme 1 so that Homebrew treats it as newer than an installed 3.6.4, and the current Python, Node.js and Ruby formulae depend on openssl@4. brew info --json=v2 openssl@3 on this machine reports it as outdated. A brew upgrade fixes all three.
• /usr/bin/openssl and /usr/bin/curl use LibreSSL, Apple's system TLS library, with its own lifecycle. They are not affected by OpenSSL's dates.
• pyca/cryptography reports OpenSSL 4.0.1. That is cryptography 48.0.1, an older install whose wheel bundled 4.0.1 from June. The line is supported until May 2027, but 4.0.1 misses the August and September fixes. "Supported line" and "current patch" are separate checks. pip install -U cryptography moves it to 50.0.2 with 4.0.3.

For servers and images, the same checks work one runtime at a time:

openssl version -a
python3 -c "import ssl; print(ssl.OPENSSL_VERSION)"
node -p "process.versions.openssl"
ruby -ropenssl -e 'puts OpenSSL::OPENSSL_LIBRARY_VERSION'
php -r 'echo OPENSSL_VERSION_TEXT, PHP_EOL;'
curl -V | head -1
nginx -V 2>&1 | grep -o 'built with OpenSSL [0-9.]*\|running with OpenSSL [0-9.]*'

Find vendored and statically linked copies

Package queries find the system library. They do not find a copy compiled into your own binaries or shipped next to them. These commands do.

# Shared libraries anywhere on a Linux filesystem or an unpacked image
find / \( -name 'libssl*.so*' -o -name 'libcrypto*.so*' \) -not -path '/proc/*' 2>/dev/null

# The version string inside a shared library or a statically linked binary
strings -a /path/to/libcrypto.so.3 | grep -m1 -E '^OpenSSL [0-9]+\.[0-9]+\.[0-9]+'
strings -a ./your-binary | grep -m1 -E '^OpenSSL [0-9]+\.[0-9]+\.[0-9]+'

# Which libssl a dynamically linked binary loads
ldd ./your-binary | grep -E 'libssl|libcrypto'          # Linux
otool -L ./your-binary | grep -E 'libssl|libcrypto'     # macOS

# Rust: is OpenSSL vendored, and which version?
cargo tree -i openssl-src

# vcpkg: what the manifest resolves
vcpkg list openssl

On Windows, search for libssl-3*.dll and libcrypto-3*.dll under application folders, then read the file version from the DLL properties or with strings. Many Windows applications ship their own copy beside the executable.

Check and fix by platform

Debian and Ubuntu

apt-cache policy openssl libssl3t64 libssl3
sudo apt update && sudo apt install --only-upgrade openssl libssl3t64

The library package is libssl3t64 on Debian 13 and Ubuntu 24.04 and later, and libssl3 on Ubuntu 22.04 and Debian 12. On Debian testing or unstable, keep updating; the distribution will move off 3.6 on its own schedule. After an upgrade, restart services that loaded the old library: sudo needrestart lists them where it is installed, or lsof -n | grep -E 'libssl.*(deleted)' shows processes still mapping a replaced library.

Fedora, RHEL family and CentOS Stream

rpm -q openssl openssl-libs
sudo dnf upgrade openssl openssl-libs

These ship 3.5 today, so the dates in this post do not apply to them directly.

Alpine

apk info -v openssl libssl3 libcrypto3
apk upgrade --available openssl libssl3 libcrypto3

Alpine 3.22 to 3.24 and edge ship 3.5.9. In Dockerfiles, prefer bumping the base image tag and rebuilding over running apk upgrade in a later layer.

Arch Linux

pacman -Q openssl
sudo pacman -Syu

Arch ships 3.6.5. Its next OpenSSL update will come through a normal system upgrade; keep upgrading and avoid partial upgrades.

Homebrew

brew update
brew outdated openssl@3 openssl@3.6 openssl@4 python@3.14 node ruby
brew upgrade
brew uses --installed openssl@3.6     # anything still depending on 3.6?
brew uninstall openssl@3.6            # only when the line above prints nothing

Then run the checker again. If a virtualenv was created with the old Python, recreate it, because it keeps pointing at the old interpreter build.

vcpkg

The openssl port currently resolves 3.6.5. In manifest mode, pin a 3.5.x version that your baseline's version database contains, using an override in vcpkg.json, and rebuild:

vcpkg x-history openssl      # list the port versions your registry knows

{
  "dependencies": ["openssl"],
  "overrides": [{ "name": "openssl", "version": "3.5.9" }]
}

If your registry does not have 3.5.9, either update the baseline or use an overlay port. Do not leave the port floating to whatever the next baseline brings.

Conan

Conan Center lists openssl/3.5.9, openssl/3.6.5, openssl/4.0.3 and the ended openssl/3.4.8. Set the reference explicitly in your conanfile.py or conanfile.txt, for example openssl/3.5.9, then rebuild dependents with conan install . --build=missing.

Rust

cargo tree -i openssl-src
cargo update -p openssl-src

If the tree shows openssl-src v300.6.1+3.6.3, the crate is embedding 3.6.3. Either allow the 400.x line (400.0.2+4.0.3 embeds 4.0.3), which requires an openssl-sys version that accepts it, or drop the vendored feature and link the system OpenSSL from a supported distribution.

Building from source

If you maintain your own build, verify and build 3.5.9:

curl -LO https://github.com/openssl/openssl/releases/download/openssl-3.5.9/openssl-3.5.9.tar.gz
curl -LO https://github.com/openssl/openssl/releases/download/openssl-3.5.9/openssl-3.5.9.tar.gz.asc
echo "603f5602e2eef00d77fbd429d34dcd5822bb301757a1bc9cdb24c670f1eb859a  openssl-3.5.9.tar.gz" | shasum -a 256 -c
gpg --verify openssl-3.5.9.tar.gz.asc openssl-3.5.9.tar.gz   # expect key B146 647E 45A7 B339 47AB 226B 2A2C 87D1 6169 2D40
tar xzf openssl-3.5.9.tar.gz && cd openssl-3.5.9
./Configure --prefix=/opt/openssl-3.5 --openssldir=/opt/openssl-3.5/ssl shared
make -j"$(nproc)" && make test && sudo make install_sw install_ssldirs
/opt/openssl-3.5/bin/openssl version

Then rebuild everything that links it, and check the result with ldd or strings as above. A new library on disk does nothing for binaries that statically linked the old one.

Containers

docker run --rm --entrypoint sh your-image:tag -c 'openssl version 2>/dev/null; cat /etc/os-release | head -2'

If the image was built from a rolling base such as Arch or Debian testing, or bundles its own OpenSSL, rebuild it from a base that ships 3.5 or a vendor-supported line, pin the base by digest, and redeploy.

What to do, in order

1. Inventory where OpenSSL comes from, not just which version is installed: distribution package, bundled in a runtime, vendored in a build, a package manager such as Homebrew, vcpkg or Conan, or a statically linked binary.
2. Leave vendor-supported packages to the vendor. An Ubuntu 24.04 server on 3.0.13-0ubuntu3.16 with current updates is supported by Ubuntu. Keep it patched and follow Ubuntu's notices.
3. Fix anything self-built on 3.4 now. It has had no upstream fixes since 22 October.
4. Move 3.6 builds before 1 November. vcpkg baselines, Rust vendored builds, Homebrew openssl@3.6, MSYS2 toolchains and images from rolling bases are the usual suspects.
5. Choose the target deliberately. 3.5.9 for stability until April 2030. 4.0.3 if you need ECH or other 4.0 features and can port. 4.1.0 if you need DTLS 1.3 and accept a November 2027 end.
6. Bring every copy to the latest patch release of its line, not just a supported line. 4.0.1 and 3.5.7 are supported lines but miss fixes.
7. Rebuild and redeploy, and restart long-running processes that still map the old library.
8. Pin and record the line in build files and SBOMs, so the next end of life date is a calendar item rather than a discovery.

For running the register of components whose upstream has stopped, see our guide to managing end-of-life software dependencies.

What would have helped

None of this was a surprise. The dates were published in May. What separates a calm week from a scramble is ordinary practice.

Knowing where each copy of OpenSSL comes from. Most teams know their distribution's OpenSSL. Fewer know about the copies inside a Rust binary, a Windows installer, a vcpkg build or a Python wheel. An SBOM per build, including native and vendored components, is what makes the list possible.

Pinning the TLS library line on purpose. A vcpkg baseline or a rolling base image will drift from 3.5 to 3.6 to whatever comes next without anyone deciding. An explicit pin, reviewed when it changes, turns that drift into a choice.

Rebuilding on a schedule. Images and binaries that statically link OpenSSL only pick up fixes when they are rebuilt. A weekly rebuild from a current base catches patch releases as well as line changes.

Tracking the patch level, not just the line. The desk Mac above had a supported 4.0 line in pyca/cryptography that was still three months behind on fixes.

Treating LibreSSL and BoringSSL as separate components. They appear in the same places and answer to different policies.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. It runs in an agentic mode and a deterministic scanner mode, issues findings as SGZ advisories before they reach public CVE databases, and covers seven package ecosystems. The OpenSSL issues in this post were reported to and published by the OpenSSL project, and we make no claim that this capability found any of them. A C library distributed as source tarballs and distribution packages sits largely outside the package ecosystems it covers, although copies that arrive through a language package, such as a Python wheel or a Rust crate, do appear in a dependency graph.

Gold Open Source at gold.safeguard.sh is free and needs no login: searchable CVE intelligence with CVSS, EPSS, CISA KEV status, affected and fixed versions and a recommended safe version, a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is a paid service providing hardened drop in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses. We have not checked which Gold images carry which OpenSSL line, so ask before planning around one. The habit Gold supports, starting from a known good, signed base and rebuilding quickly when the base changes, is exactly the habit that makes an OpenSSL line ending a routine rebuild.

Where Safeguard fits

Safeguard is not a Linux distribution, does not ship or patch OpenSSL itself, and cannot extend upstream support. Here is where it helps:

• SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output). For an image, that inventory includes the OS packages such as libssl3t64 or openssl and their versions; for a repository, language packages such as cryptography or openssl-src. The platform shows which projects contain a given component and version, so "every image with OpenSSL 3.6" is a query.
• Vulnerability matching of those components against vulnerability databases, including the 29 September CVEs.
• Reachability analysis, which ranks vulnerable code paths your application actually calls, useful when most of an advisory's CVEs are in QUIC, DTLS or CMP code that many services never use.
• Policies and gates evaluated in the platform, so an image or build that carries an OpenSSL line you have decided not to ship can fail or warn.
• Autonomous remediation that opens fix pull requests for vulnerable dependencies, such as bumping cryptography or a base image tag. It ships off by default.
• The Safeguard CLI's assistant, which edits code and runs commands with your approval under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You can ask it to change a vcpkg override, bump a base image, run cargo update -p openssl-src and rebuild, approving each command. safeguard exec runs the same kind of task in CI, and the desktop and phone apps can send work to a computer running the CLI and approve each command.

What it does not do: it does not patch the OpenSSL in a vendor appliance, a managed service or a host operating system you do not build, and a statically linked copy inside a third party binary still needs that vendor's fix.

Common mistakes

Checking the openssl command and stopping. The command and the runtimes can link different builds. On the Mac above, the command was 4.0.3 while three runtimes used 3.6.4.

Treating "3.0, upstream ended" as "unpatched." Debian 12, Ubuntu 22.04 and 24.04 patch their 3.0 packages. Follow the vendor's notices.

Treating "supported line" as "patched." A 4.0.1 or 3.5.7 build is on a supported line and still missing CVE fixes.

Updating the package but not restarting services. Long-running processes keep the old library mapped until they restart.

Forgetting static copies. Rust binaries with vendored OpenSSL, Go programs using cgo with static OpenSSL, and many Windows applications carry their own copy. A system update does not touch them.

Pinning 3.6 in a build because it was the latest. In a year with 13-month non-LTS windows, "latest" is a short-lived choice. Pin LTS unless you need something newer.

Jumping to 4.x for a quick fix without testing. Engines, custom methods and deprecated APIs are gone. Rebuild and run the full test suite.

Reading the OpenSSL Corporation lifecycle page as current. As of 24 October it still shows 3.4 as Supported. The library site's downloads page and release strategy are more current.

Assuming curl, Python or Node.js on macOS use OpenSSL. System curl uses LibreSSL; Homebrew builds use OpenSSL. Check which one is first on your PATH.

Open questions

• Will 3.6.6 ship before 1 November? No release is announced. If a security fix lands before then, 3.6 would receive it; after 1 November it would not.
• When will the rolling distributions move off 3.6? Arch, Debian testing and vcpkg had not moved as of 24 October. Each will choose 3.5, 4.0 or 4.1 on its own schedule.
• Will the openssl-src crate publish a 300.x release with 3.5.9 or 3.6.5? None exists as of 24 October.
• Will the OpenSSL Corporation lifecycle page be updated? We expect it to catch up with the library site.

FAQ

When did OpenSSL 3.4 reach end of life?

On 22 October 2026, per the OpenSSL release strategy. The last release is 3.4.8, from 29 September 2026.

When does OpenSSL 3.6 reach end of life?

On 1 November 2026. Its latest release is 3.6.5, from 29 September 2026.

Why does 3.6 end only ten days after 3.4?

Non-LTS releases up to 3.4 were supported for at least two years. From 3.5 onward, non-LTS releases get 13 months. 3.4 was released in October 2024 and 3.6 in October 2025, so both windows close at almost the same time.

Which OpenSSL versions are supported now?

3.5 LTS until 8 April 2030, 4.0 until 14 May 2027, and 4.1 until November 2027. 3.6 is supported until 1 November 2026.

Should I move to 3.5 or 4.0?

3.5 if you want a long, stable target and the smallest change from 3.4 or 3.6. 4.0 or 4.1 if you need their features and can port away from engines and other removed APIs. 4.2 is planned as the next LTS in April 2027.

My Ubuntu 24.04 servers run OpenSSL 3.0.13. Are they unsupported?

Not by Ubuntu. Ubuntu backports fixes to its own 3.0 packages and published USN-8847-1 on 29 September 2026. Keep the package updated.

Is OpenSSL 3.0 still supported?

Not publicly upstream since 7 September 2026. The OpenSSL Corporation offers 3.0.23 and later fixes to premium support customers, and distributions such as Debian and Ubuntu patch their own 3.0 packages.

How do I find statically linked OpenSSL in my binaries?

Run strings -a ./binary | grep -m1 -E '^OpenSSL [0-9]+\.[0-9]+\.[0-9]+'. For Rust, cargo tree -i openssl-src shows the vendored version.

Does macOS use OpenSSL?

The system /usr/bin/openssl and /usr/bin/curl use LibreSSL. Homebrew, MacPorts and language runtimes installed through them use OpenSSL. Check each one.

Does this affect Node.js?

Current Node.js 22, 24 and 26 releases bundle OpenSSL 3.5.9, an LTS line. A Node.js built against a system or Homebrew OpenSSL uses that library instead, which is what the desk Mac above showed.

Fix it without waiting for upstream

For OpenSSL 3.4 and 3.6, upstream has stopped or is about to stop committing fixes, so the first gap below is the one to close: get every build onto a line and patch release that is still maintained.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows an OpenSSL migration. Each is a real Safeguard session, and each intro says how the same flow applies to the work in this guide.

This session sets up the Safeguard runner on your own machine, approves it with its device code, and scans from the terminal. That is the quickest way to get the inventory in step 1 above: run a scan locally against your repositories and container images, then filter the results for openssl, libssl, cryptography and openssl-src versions.

Click through it at your own pace, or open it full screen.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For OpenSSL you would open the CLI in a C or C++ project and ask it to add a vcpkg override pinning openssl to 3.5.9, or in a Rust project to run cargo tree -i openssl-src and update the crate, approving each edit and each build and test command.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here you would pick the folder with your Dockerfiles and ask for the base images that pull OpenSSL 3.6 to be moved to a base that ships 3.5, then rebuilt and checked with openssl version inside each image, approving or denying each step.

Click through it at your own pace, or open it full screen.

To try it on your own machines, download Safeguard and follow the CLI docs. For background on this year's OpenSSL fixes, see our posts on the June 2026 OpenSSL releases and the PKCS7_verify use-after-free, the CVE-2025-15467 patch response, and how OpenSSL, LibreSSL and BoringSSL compare in 2026.

Quick check

Sources

• OpenSSL Library: Release Strategy
• OpenSSL Library: Downloads
• OpenSSL Library: Release and Advisory Timeline
• OpenSSL Library: Old 3.4 releases
• OpenSSL Library: Old 3.6 releases
• OpenSSL Security Advisory, 29 September 2026
• OpenSSL Security Advisory, 25 August 2026
• OpenSSL: NEWS.md at openssl-4.1.0
• OpenSSL: release checksums on GitHub
• OpenSSL Corporation: Lifecycle
• endoflife.date: OpenSSL
• Arch Linux: core/openssl package
• Debian: madison package versions for openssl
• Launchpad: openssl source package in Ubuntu
• Ubuntu: security notices for OpenSSL
• Fedora: package metadata API
• Homebrew: openssl@3, openssl@3.6 and openssl@4 formulae
• Homebrew: python@3.14 formula
• microsoft/vcpkg: openssl port manifest
• crates.io: openssl-src versions
• Node.js: release index
• pyca/cryptography: changelog
• Repology: openssl across repositories

Last reviewed: 24 October 2026. OpenSSL 3.6 support ends on 1 November 2026; check the OpenSSL downloads page and your distribution's security notices for the latest status.