Motivation

Netty 4.1.137.Final is a bug-fix and security
release, and upstream "strongly recommends" upgrading. It is the 4.1 counterpart of 4.2.17.Final,
which is being upgraded on master in #26300.

Security fixes. It resolves the same seven advisories as 4.2.17.Final — every one of them lists
<= 4.1.136.Final as a vulnerable range, so branch-4.2 is affected by all of them. Five 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, with a branch-4.2 caveat. 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 OpenSSL half of that precondition is met by default on branch-4.2: tlsProvider is unset in
conf/broker.conf, DefaultPulsarSslFactory then passes null to SslContextBuilder, and Netty
falls back to SslContext.defaultClientProvider(), which is OPENSSL whenever the native engine is
available — and it is, since Pulsar bundles netty-tcnative-boringssl-static. The Java 25+ half is
not met by default here: branch-4.2 builds and ships on JDK 21 (IMAGE_JDK_MAJOR_VERSION=21, and
the CI default is 21), unlike master which has moved to JDK 25 (#26070). So this only reaches
deployments that both run a 4.2 broker/client on a Java 25+ runtime and supply a plain rather than
extended trust manager via a custom PulsarTlsFactory. Lower exposure than on master, but the
upgrade removes the question either way.

Non-security fixes. 4.1.137.Final also carries several fixes in areas Pulsar leans on heavily:

• Fix buddy cache evicting chunks with live buffers (#17176)
• Adaptive allocator backports (#17206)
• Reject negative maxOrder in PooledByteBufAllocator (#17095)
• Fix AdaptiveByteBuf._setLongLE calling checked setLongLE (#17102)
• SslHandler: fix possible buffer leak when an OOME is thrown during allocation (#17078)
• Weakly reference engines from the OpenSSL engine map (#17205)
• Avoid classloader leak via GlobalEventExecutor terminationFuture failure (#17189)
• HttpObjectEncoder / DefaultHttp2FrameWriter: fix buffer leak when a Throwable is thrown during header encoding (#17178)
• HttpServerCodec: do not consume the method queue for 1xx interim responses (#17203)
• Do not write the WebSocket handshake response to the tail of the pipeline (#17200)
• AsciiString.cached(String) sanitization and the follow-up performance regression fix (#17075, #17080, #17083)
• Compression decoder hardening: guard the Snappy decoder against invalid chunk lengths (#17110), use the safe decompressor in Lz4FrameDecoder (#17121), fix maxAllocation for brotli-encoded content in HttpContentDecompressor (#17124) and prevent duplicate BrotliEncoder close scheduling (#17193)

netty-tcnative. Bumped 2.0.78.Final → 2.0.81.Final. Pulsar's pom.xml does not pin tcnative
separately — it is managed by the imported netty-bom, which declares
<tcnative.version>2.0.81.Final</tcnative.version> in 4.1.137.Final (it was 2.0.78.Final in
4.1.136.Final), so the bump comes along with the netty.version change.
The changes across those three tcnative releases
are:

• Clear the certificate chain in setKeyMaterial (netty-tcnative#987)
• 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) — the Netty-side OpenSslSession accessor built on it (netty#17058) landed on the 4.2 branch only, so on 4.1.137 this is just the tcnative bump (netty#17122)
• 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

Modifications

• pom.xml: netty.version 4.1.136.Final → 4.1.137.Final. netty-tcnative moves 2.0.78.Final →
  2.0.81.Final transitively via the netty-bom import; there is no separate version property to
  update on this branch.
• 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, src/check-binary-license.sh
was run locally against both distribution/server/target/apache-pulsar-4.2.5-SNAPSHOT-bin.tar.gz
and distribution/shell/target/apache-pulsar-shell-4.2.5-SNAPSHOT-bin.tar.gz (both exit 0) 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.1.136.Final to 4.1.137.Final and netty-tcnative from 2.0.78.Final to
2.0.81.Final.