OpenSSL 4.1.0 release notes list four known DTLS bugs and say a fix is in progress for one of them

Four known bugs, one stated fix: what OpenSSL 4.1.0 prints and what its tracker shows

OpenSSL published version 4.1.0 on Friday 23 October 2026 at 12:23 UTC, according to its GitHub release page, with four DTLS bugs listed under Known issues. The notes say a fix is in progress for one of them and give no fix status for the other three (derived: 4 minus 1 is 3). The oldest of the four was filed on 18 September, 35 days before the release (derived), so it stayed open through both test releases, beta 1 on 23 September and beta 2 on 9 October. Everything here was read between 09:40 and 10:06 GMT on Monday 26 October 2026, three days after the release, from the release page, the NEWS and CHANGES files and the source at the release tag, the project's issue tracker and its manual pages. GMT and UTC are the same time on these dates. The Help Net Security report of 26 October pointed the way and was not used as evidence.

What that does not establish is a vulnerability. The notes file all four under Known issues, not in a security advisory. OpenSSL's vulnerabilities page, last modified 29 September 2026 by its HTTP header, prints no newer entry and no 4.1 version range. The project's release timeline shows 4.1.0 on 23 October with no advisory beside it, and a National Vulnerability Database keyword search for OpenSSL in October 2026 returned three records, none for the library. No source I read reports anyone using any of the four against a target. The triggers the reports describe are ordinary: a lost packet, a closed socket, a full send buffer, a client that acknowledges early, a peer's KeyUpdate.

Nor does the headline feature establish readiness. The notes say "Support for DTLS 1.3 (RFC 9147)" and use neither the word production nor the word experimental, in the release page, NEWS, CHANGES or the DTLS guide. What the tracker adds is the useful part. An OpenSSL member wrote that one of the four, a wait that never ends, can hurt an application's "availability and reliability". A member's comment on another reports a worse case than the notes print. Five more open DTLS issues carry the 4.1 label and are not listed at all (derived count). The rest of this briefing sets out what is stated and not stated, the four bugs one by one, who is exposed, the other changes that can break an upgrade, the support window and a ranked checklist.

Stated and not stated: the record, line by line

Each row asks a question a reader would ask on Monday morning, then separates what a primary says from what no primary says. The right column is the one to keep. A known issue is a label, and a label is not a control: it tells you the project knows, not how bad it is, not whether you are exposed and not when it ends.

The four known issues, one by one

All four are on the tracker with the labels "triaged: bug", "branch: master" and "branch: 4.1". OpenSSL's release page prints each as a short paragraph, and NEWS.md carries the same text. The project's blog feed had no 4.1.0 announcement at read time: its newest post is the 23 September beta announcement, and neither that post nor the September post on DTLS 1.3 mentions any bug. The table shortens the four entries and adds the tracker state read at 09:41 GMT. OpenSSL itself does not describe any of the four as a security issue; the closest wording is the member's remark on availability and reliability below. Which are correctness bugs and which could be availability problems is this briefing's reading unless a member said it.

32878, the lost ticket. RFC 9147 says in section 5.8.4 that each category of post handshake message has its own reliability state machine, so a KeyUpdate and a NewSessionTicket should not cancel each other. The tagged source does not keep them independent, on my reading (derived, not built or run): read_state_machine() in ssl/statem/statem.c calls dtls1_stop_timer() at the two places where a read finishes, and dtls1_stop_timer() in ssl/d1_lib.c calls dtls1_clear_sent_buffer(s, 0), which empties the whole sent queue. The reporter's own output shows the effect: two tickets queued, then none after an unrelated KeyUpdate. The release note describes exactly that and no more.

The thread says more. Within a day a member added that they had found "a much more serious impact" through the same code path: with one dropped KeyUpdate, client to server application data can silently stop for the rest of a live connection while server to client data still flows and neither side reports an error. The member reproduced it in a test harness, and asked for the fix to be reconsidered for 4.1. It shipped as a known issue. The release note does not mention the stall. Whether the stall is covered by the note's wording is not stated, and the tagged source still contains the two calls above. None of the 11 commits that GitHub lists as referencing the issue is an ancestor of the 4.1.0 tag (derived from GitHub's compare endpoint), so the fix work, PR 32934, is not in the release.

Zoom

33277, the wait that never ends. The manual says SSL_ERROR_WANT_READ means not enough data was available and the call can be retried later. On a listener connection, a permanent failure such as a closed UDP socket can come back with that same code, so a correct application waits, and keeps waiting, while the error stays on OpenSSL's error queue unread. The reporter, a member, says polling and later accept calls can also miss the failure; one test saw 7,406 receive calls in 20 milliseconds without an error event. In the thread a member wrote that callers left waiting after a detected failure can have their "availability and reliability" affected, and that if the fix missed 4.1 it should go in the release notes. It did. The draft fix, PR 33288, changes 10 files, with 978 lines added and 231 removed, and was still a draft at read time.

33278, the usable connection that gets closed. Here a write that only needs a retry comes back as SSL_ERROR_SYSCALL, which the manual defines as a non recoverable fatal I/O error after which no further I/O should be performed. An application that follows the manual closes a connection that still works. An application that retries on SYSCALL breaks the manual's contract and cannot tell this case from a real failure, because the reproducer's error queue was empty and errno was 0 (derived reading). A member answered the question of scope with "This affects any DTLS", so it reaches DTLS 1.2 users of the new listener API, not only DTLS 1.3. No fix PR links to it; the only linked PR is the documentation change that put it in the notes.

33242, the handshake that aborts on a polite acknowledgement. RFC 9147 section 7.1 recommends that a receiver of part of a flight send an ACK, and section 7.2 says the sender "SHOULD retransmit the unacknowledged messages or fragments". OpenSSL's own fix PR says the server is meant to do that and that its read transition did not accept an ACK in that state. The reporter, an outside implementer, says an OpenSSL client never sends such an ACK, so OpenSSL to OpenSSL tests cannot hit it. The report says BoringSSL and Pion do send one (from reading their code, not run against OpenSSL) and that the reporter's own Rust library, run against a 4.1 beta, triggered the abort. The server's fatal alert is protected with keys the client does not yet have, so the client sees a stalled handshake, not an alert. The notes add that it can also happen while the client prepares its authentication response, which needs no packet loss at all. The error on the server is a log line you can search for, printed in the technical details.

Five more open DTLS issues carry the 4.1 label and are not in the notes

A search of OpenSSL's tracker at 09:45 GMT for open issues with DTLS in the title and the label "branch: 4.1" returned nine. Four are the known issues above. The other five are in the table, with what each issue says about itself. I did not test any of them, and an open issue is a report, not a finding. Releases always ship with open issues, so this is not a failing. The point is narrower: the Known issues list is a selection, and the rule for the selection is not stated.

The three race issues sit awkwardly beside the project's own DTLS guide, which says that by default connections accepted from a listener can be safely used from multiple threads concurrently. A race reported by ThreadSanitizer is not proof of a failure in the field, and I do not claim one. It is a reason to test listener code under the sanitizer, or to use the single thread flag the guide describes, before trusting the default.

Who is exposed, and what the upgrade turns on

HelpNet's summary, that the bugs fall on developers who adopt DTLS 1.3 or the new listener API, matches the notes. The table turns it into a lookup. Both new features are listed as added in 4.1.0, so a program that stays on OpenSSL 4.0 or 3.x has neither the DTLS 1.3 code nor the DTLS listener (derived from the CHANGES entries).

One question decides the rows that say if 1.3 is not negotiated, and the primaries do not agree. The version flexible DTLS methods are documented in the tag's SSL_CTX_new page as supporting "DTLS 1.0 and DTLS 1.2". The DTLS guide in the same tag says "Even though DTLSv1.3 is enabled" in its SCTP section, and in ssl/ssl_local.h the internal maximum DTLS version is defined as DTLS1_3_VERSION (derived reading; nothing was built or run). So whether an existing DTLS 1.2 server picks up DTLS 1.3 on upgrade, with no code change, is not established by what OpenSSL printed. Test it with a client you control (commands in the technical details), and pin the maximum version if you want to stay on 1.2.

Other changes that can break an upgrade, and a label that did not do its job

The same release removes or changes things that have nothing to do with DTLS. They are quieter than the bugs and likelier to stop a build on the day you try it. The text is OpenSSL's, from the release page and CHANGES at the tag; the right column is this site's reading.

The friendly name here is no-ecdsa. OpenSSL says the options "did not really disable the implementations". A build flag whose name says an algorithm is gone, while the code stayed, is a label doing the work of a control. If a hardening record, a software bill of materials or a customer questionnaire says ECDSA was disabled by that flag, it was not established by the flag, on OpenSSL's own account. The replacement, no-ec, is far wider than what the old flags promised: in Configure at the tag, disabling ec also disables ec2m, ec_explicit_curves, sm2, gost, ecx and tls-deprecated-ec (derived reading, not run). The ecx feature covers the X25519 and Ed25519 family, so check what else in your estate needs it. The INSTALL file at the tag has no entry for no-ec; the replacement is stated only in CHANGES, NEWS and the release page.

The support window, and where a fix can land

OpenSSL's downloads page prints an end of life of "Nov 2027" for 4.1, with no day. The release strategy says non LTS releases after 3.5 are fully supported for 13 months, which puts 4.1 at about 23 November 2027, 396 days after release (derived; the page prints no 4.1 date). The rule reproduces the printed date for 4.0, 14 May 2027. The 4.1.0 release came 192 days after 4.0.0 on 14 April 2026 (derived).

Two things follow. First, DTLS 1.3 exists only in a release that is not an LTS: a team that wants it from OpenSSL now takes the 13 month series, with four open issues, until the next LTS, which OpenSSL's May 2026 schedule post says will be 4.2 in April 2027. Second, the fix has no home yet. The notes say "a future release" for one fix and nothing for the rest. For scale only: 4.0 had three patch releases in its first 168 days, 56 days apart on average (derived), and nothing states that 4.1 will follow that pattern.

The last OpenSSL security advisory, on 29 September 2026, fixed a different DTLS flaw, CVE-2026-84782, in 4.0.3, 3.6.5, 3.5.9 and 3.4.8; the earlier briefing on its two scores covers it. The vulnerabilities page lists no 4.1 range for it. Whether 4.1.0's code contained the flaw is not stated either way, so do not read the silence as an all clear.

Who reported the bugs and who is writing the fixes, as printed

Issues 32878, 33277 and 33278 were filed by accounts that GitHub marks as members of the project; 33242 was filed by an account with no association, an outside implementer. Its opening note says the report was found, reproduced, analysed and written up by an AI agent, and names the model as Claude Opus 5.5 used through GitHub Copilot; it ends with an Assisted-by line to the same effect. The open fix PR for it, 33267, ends with Assisted-by: Claude Code:claude-sonnet-5-5, and the draft fix for 33277, PR 33288, ends with Assisted-by: OpenAI:gpt-6-astra. These are the strings the pages print. Anthropic and OpenAI each sell the models named in those lines and each has an interest in AI assisted bug finding being seen as useful. None of this tells you whether a fix is right; the PRs show tests, reviewers' comments and a postponement, and those are the evidence to read.

Technical details

This is a correctness story, so the primaries print no hashes, domains, addresses or attack payloads, and none are given here. What they do print is text, error strings and commands. Each block names its source and the date read, copies the text exactly, and says what a defender does with it. Items this site assembled are marked derived. The OpenSSL text below is published under the Apache License 2.0 and is reproduced for reference.

1. The four known issues, exactly as printed. This is the whole list. Compare it with your own deployment, not with the summary above.

Known issues in 4.1.0

  * <https://github.com/openssl/openssl/issues/32878>
    When a DTLS 1.3 KeyUpdate is received, all other outstanding
    post-handshake records are dropped from the retransmission buffer.
    This means post-handshake records still awaiting an ACK (such as a
    NewSessionTicket) will no longer be retransmitted if the original
    transmission is lost. A fix is in progress and planned for a future
    release.

  * <https://github.com/openssl/openssl/issues/33277>
    A permanent receive failure on a DTLS listener can be reported as
    `SSL_ERROR_WANT_READ` on an accepted connection. Polling and subsequent
    accept calls may also fail to report the error, causing applications
    to continue waiting after a permanent failure.

  * <https://github.com/openssl/openssl/issues/33278>
    A retryable write failure on a nonblocking connection accepted from a
    DTLS listener can be reported as `SSL_ERROR_SYSCALL` instead of
    `SSL_ERROR_WANT_WRITE`. Applications treating this result as fatal may
    close a connection that is still usable.

  * <https://github.com/openssl/openssl/issues/33242>
    DTLS 1.3 servers may abort handshakes with an `unexpected_message` alert
    when a client acknowledges part or all of the server's first flight
    before sending its response. This can occur after packet loss or while
    the client is preparing its authentication response.

2. What the manual says SSL_ERROR_SYSCALL means. This is the contract that 33278 puts an application in conflict with. If your code treats SYSCALL as fatal, which the manual tells it to, a retry condition will close a working connection.

=item SSL_ERROR_SYSCALL

Some non-recoverable, fatal I/O error occurred. The OpenSSL error queue may
contain more information on the error. For socket I/O on Unix systems, consult
B<errno> for details. If this error occurs then no further I/O operations should
be performed on the connection and SSL_shutdown() must not be called.

This value can also be returned for other errors, check the error queue for
details.

3. What the issue reporters saw. These are the lines the reproducers print, copied from the issue bodies (read 26 October 2026 at 09:41 GMT). They show what to log in your own code: the value of SSL_get_error, whether OpenSSL's error queue is empty, errno, and, for 32878, the size of the sent queue. They are test program output, not field logs, and they are not a way to trigger anything.

SSL_read_ex rc=0 SSL_get_error=SSL_ERROR_WANT_READ (2) bytes=0
error still stacked after SSL_get_error: yes
read after restoring the BIO: rc=1 SSL_ERROR_NONE n=23

rc=0 written=0 SSL_get_error=SSL_ERROR_SYSCALL (5)
SSL_want=2 (SSL_WRITING=2) SSL_net_write_desired=1
ERR_peek_error=0 errno=0

Dropped 2 original ticket ACK datagrams; server has 2 messages
After unrelated inbound KeyUpdate: error=2 queued=0 timer_zero=1

4. A server log line to search for. For 33242 the issue prints the error OpenSSL raises on the server when it aborts. Search server logs and OpenSSL error dumps for it. A client sees only a stalled handshake, so the server log is where it shows. The file and line in the string match ssl/statem/statem_srvr.c line 342 at the 4.1.0 tag (derived check), where the generic unexpected message error is raised; the same string can have other causes, so read the handshake state around it.

error:0A0000F4:SSL routines:ossl_statem_server_read_transition:unexpected message (ssl/statem/statem_srvr.c:342)

5. The build options. OpenSSL prints this text for the removed Configure options. The derived block after it is how to check a build you already have. Because INSTALL.md at the tag lists no DTLS 1.3 only switch, and says no-dtls disables only dtls1 and dtls1_2, I read Configure. It builds its protocol list from a line that includes dtls1_3, and its cascade table disables every entry of that list when dtls is disabled. So no-dtls1_3 is probably accepted and no-dtls probably turns off all three versions (derived reading, not run). OpenSSL documents neither claim and does not offer either option as a workaround for these bugs, so treat both as untested.

 * Dropped `no-ecdsa` and `no-ecdh` options from `Configure`, as these options
   did not really disable the implementations.  Use `no-ec` to disable
   the elliptic curve support.

my @dtls = qw(dtls1 dtls1_2 dtls1_3);
    "ec"                => [ qw(ec2m ec_explicit_curves sm2 gost ecx tls-deprecated-ec) ],
    "dtls"              => [ @dtls ],

    no-{ssl|ssl3|tls|tls1|tls1_1|tls1_2|tls1_3|dtls|dtls1|dtls1_2}

openssl version -a
openssl list -disabled

6. Which OpenSSL and which DTLS version your application uses. These commands are standard tools, not OpenSSL text, so the whole block is derived and was not run. Run ldd only on programs you trust, because on some systems it can execute the program; for an untrusted file use readelf -d or objdump -p and read the NEEDED lines instead. A statically linked or bundled copy will not show up in these lists: look for it in the vendor's software bill of materials, as the earlier briefing on CVE-2026-84782 explains. The two s_client lines use options that OpenSSL's s_client manual page lists (-dtls1_2, -dtls1_3); point them only at a DTLS server you operate, to see which version it will negotiate.

# Linux, trusted binaries only
ldd /path/to/app | grep -E 'libssl|libcrypto'
# Linux, any binary
readelf -d /path/to/app | grep NEEDED
# macOS
otool -L /path/to/app | grep -E 'libssl|libcrypto'
# negotiated version on a DTLS server you operate
openssl s_client -dtls1_3 -connect HOST:PORT
openssl s_client -dtls1_2 -connect HOST:PORT

7. The version question, in OpenSSL's own words. These are the two lines that disagree, and the header line that sets the internal maximum. The comparison is derived. It is why the checklist says to pin the version explicitly and test.

These are the version-flexible DTLS methods.
The supported protocols are DTLS 1.0 and DTLS 1.2.

Even though DTLSv1.3 is enabled, the client will only perform a DTLSv1.2 or DTLSv1.0 handshake.

#define DTLS_MAX_VERSION_INTERNAL DTLS1_3_VERSION

8. The tsget change. OpenSSL's text first, then a derived check that the replacement Perl module loads on the machine that runs tsget.

  * Changed `tsget` utility to use `Net::Curl::Easy` (from the `Net-Curl` CPAN
    distribution) instead of the abandoned `WWW::Curl::Easy`.  Users who rely
    on `tsget` should install `Net::Curl::Easy` before upgrading.

perl -MNet::Curl::Easy -e 'print qq(Net::Curl::Easy loads\n)'

What to do, in the order worth doing

Written for any operator or maintainer, in any country. The order puts the cheap, decisive step first: finding out whether any of this is yours.

What could not be verified

Nothing was built, installed or run: no OpenSSL source archive was downloaded and no reproducer was executed. Every statement about the source is a reading of files at the 4.1.0 tag, and each is marked derived. Whether a DTLS 1.2 program picks up DTLS 1.3 by default after the upgrade is therefore untested. Whether the stall in the 32878 thread is fixed, partly fixed or unfixed in 4.1.0 is not stated by OpenSSL; the open issue, the open PR and the unchanged calls in the tag suggest it is not fixed, but that is an inference. GitHub state changes quickly: the tracker figures are as of 09:41 to 09:45 GMT, with a reread at the end of the session. The five extra issues were read as opened and not followed through their comment threads. The Help Net Security article was read as a pointer only, and its account of the release notes matches OpenSSL's. I found no government or standards body guidance written about DTLS 1.3 or OpenSSL 4.x, so the sources here are OpenSSL's own and RFC 9147.

The question that exposes the gap

The notes tell developers that a permanent failure can look like a request to wait, and that a request to retry can look like a fatal error. The code that was meant to tell the difference is the library's return value, and for these two cases the return value is wrong. So the useful question is not whether you run OpenSSL 4.1. It is this: when OpenSSL tells your DTLS code to wait and the wait never ends, what part of your service notices, and how soon?

Key facts