OpenSSL 4.1.0-beta2 is for testers, not for production

OpenSSL’s release timeline shows 4.1.0-beta2 on 9 October 2026. A beta in this series is a test build of the next feature line. It is not the version you roll onto a public server to pick up security fixes.

Those fixes already shipped on 29 September, in the supported stable branches: 4.0.3, 3.6.5, 3.5.9, and 3.4.8. That advisory covers DTLS, QUIC, and a high-severity issue in the 3.5 line, among others. If a host is still on 3.5.8 or the matching older patch level, the beta is the wrong package to reach for. The stable update is the one that closes the holes.

Betas exist so distributors, language runtimes, and applications with their own OpenSSL builds can find breakage before a final release. APIs move. Defaults move. A library that still compiles against 3.5 can fail in 4.1 for reasons that have nothing to do with this week’s CVEs. That is useful to learn in a CI job. It is a bad surprise on a TLS terminator.

The practical split is simple. Production stays on the latest patch of a supported stable line, and someone should be able to say which line that is. A separate test environment can take 4.1.0-beta2 and report what breaks. Mixing those two jobs is how a “security upgrade” becomes an outage.

Juensy’s interest in the beta is the calendar. Node.js and Python have both just bumped bundled OpenSSL toward 3.5.9. The next time those runtimes move, 4.1 will be the line they have to decide about. Testing it now is how that decision gets made with evidence.