Netty 4.2.17.Final is a bug-fix and security
release, and upstream "strongly recommends" upgrading.
Security fixes. It resolves seven advisories (five of them still have their CVE id pending
assignment upstream, so the release notes show CVE-2026-XXXXX):
netty-transport-sctp and netty-codec-mqtt are not bundled in Pulsar's distributions (they don't
appear in either LICENSE.bin.txt), so the last two are listed only for completeness.
netty-handler, netty-codec-socks and netty-codec-http are all shipped.
GHSA-p85m-gvr3-788c is the one worth calling out. Netty's earlier CVE-2026-50010 fix added hostname
verification to a plain X509TrustManager by wrapping it, and on the SslProvider.OPENSSL path that
wrapping is Unsafe-based reflection. Unsafe is not available by default on Java 25+, so the
wrapper degrades to a no-op and an OpenSSL client configured with a plain (non-extended)
X509TrustManager ends up doing no hostname verification. The two environmental preconditions are
ordinary for Pulsar on master: an unset tlsProvider resolves to OPENSSL_REFCNT whenever the
native engine is available (TlsFactorySupport), and master now defaults to JDK 25 (#26070).
Whether verification is actually lost additionally depends on a plain rather than extended trust
manager being in play, so this mainly concerns deployments supplying their own trust manager via a
custom PulsarTlsFactory; the upgrade removes the question either way.
Non-security fixes. 4.2.17.Final also carries several fixes in areas Pulsar leans on heavily:
Fix buddy cache evicting chunks with live buffers (#17154)
Fix direct memory OOM on low-core containers (#17166)
Reject negative maxOrder in PooledByteBufAllocator (#17093)
SslHandler: fix possible buffer leak when an OOME is thrown during allocation (#17059)
Weakly reference engines from the OpenSSL engine map (#17199)
Avoid classloader leak via GlobalEventExecutor terminationFuture failure (#17140)
HttpObjectEncoder / DefaultHttp2FrameWriter: fix buffer leak when a Throwable is thrown during header encoding (#17089)
AsciiString.cached(String) sanitization and the follow-up performance regression fix (#17007, #17074)
io_uring: preserve readPending when rescheduling canceled reads and fix the recvmmsg emulation (#17087, #17187)
netty-tcnative. Bumped 2.0.78.Final → 2.0.81.Final to stay aligned with what
netty-parent:4.2.17.Final itself declares (<tcnative.version>2.0.81.Final</tcnative.version>). The changes across those three releases
are:
Drop checks on SSL_CREDENTIAL support for older BoringSSL (netty-tcnative#980)
Add SSL.getGroupName(...), returning the named group used by the most recently completed handshake (netty-tcnative#991) — this is what backs Netty's new OpenSslSession named-group accessor (netty#17058)
Link the linux aarch_64 and x86_64 openssl-dynamic artifacts against OpenSSL 3.x (netty-tcnative#986, netty-tcnative#989) — not applicable to Pulsar, which bundles netty-tcnative-boringssl-static
Update the bundled jar lists in distribution/server/src/assemble/LICENSE.bin.txt and
distribution/shell/src/assemble/LICENSE.bin.txt to the new versions
Verifying this change
Make sure that the change passes the CI checks.
This change is already covered by existing tests. In addition to CI, ./gradlew checkBinaryLicense
was run locally for both the server and shell distributions to confirm the LICENSE.bin.txt entries
match the jars that are actually bundled.
Does this pull request potentially affect one of the following parts:
If the box was checked, please highlight the changes
Dependencies (add or upgrade a dependency)
The public API
The schema
The default values of configurations
The threading model
The binary protocol
The REST endpoints
The admin CLI options
The metrics
Anything that affects deployment
Netty is upgraded from 4.2.16.Final to 4.2.17.Final and netty-tcnative from 2.0.78.Final to
2.0.81.Final.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Netty 4.2.17.Final is a bug-fix and security
release, and upstream "strongly recommends" upgrading.
Security fixes. It resolves seven advisories (five of them still have their CVE id pending
assignment upstream, so the release notes show CVE-2026-XXXXX):
netty-transport-sctp and netty-codec-mqtt are not bundled in Pulsar's distributions (they don't
appear in either LICENSE.bin.txt), so the last two are listed only for completeness.
netty-handler, netty-codec-socks and netty-codec-http are all shipped.
GHSA-p85m-gvr3-788c is the one worth calling out. Netty's earlier CVE-2026-50010 fix added hostname
verification to a plain X509TrustManager by wrapping it, and on the SslProvider.OPENSSL path that
wrapping is Unsafe-based reflection. Unsafe is not available by default on Java 25+, so the
wrapper degrades to a no-op and an OpenSSL client configured with a plain (non-extended)
X509TrustManager ends up doing no hostname verification. The two environmental preconditions are
ordinary for Pulsar on master: an unset tlsProvider resolves to OPENSSL_REFCNT whenever the
native engine is available (TlsFactorySupport), and master now defaults to JDK 25 (#26070).
Whether verification is actually lost additionally depends on a plain rather than extended trust
manager being in play, so this mainly concerns deployments supplying their own trust manager via a
custom PulsarTlsFactory; the upgrade removes the question either way.
Non-security fixes. 4.2.17.Final also carries several fixes in areas Pulsar leans on heavily:
netty-tcnative. Bumped 2.0.78.Final → 2.0.81.Final to stay aligned with what
netty-parent:4.2.17.Final itself declares (<tcnative.version>2.0.81.Final</tcnative.version>).
The changes across those three releases
are:
Modifications
distribution/shell/src/assemble/LICENSE.bin.txt to the new versions
Verifying this change
This change is already covered by existing tests. In addition to CI, ./gradlew checkBinaryLicense
was run locally for both the server and shell distributions to confirm the LICENSE.bin.txt entries
match the jars that are actually bundled.
Does this pull request potentially affect one of the following parts:
If the box was checked, please highlight the changes
Netty is upgraded from 4.2.16.Final to 4.2.17.Final and netty-tcnative from 2.0.78.Final to
2.0.81.Final.