fix(deps): update dependency io.netty:netty-handler to v4.1.137.final [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
io.netty:netty-handler (source)	4.1.119.Final → 4.1.137.Final

---

Netty has an IPv6 Subnet Filter Bypass via Incorrect Comparator Masking

CVE-2026-44249 / GHSA-3qp7-7mw8-wx86

More information

Details

Summary

An attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions.

Details

io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress) method performs a bitwise AND between the incoming IP address and the configured networkAddress, instead of the subnetMask.

Impact

Access Control Bypass. Attacker can bypass IpSubnetFilter IPv6 access controls.

Severity

• CVSS Score: 8.1 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/netty/netty/security/advisories/GHSA-3qp7-7mw8-wx86
• https://nvd.nist.gov/vuln/detail/CVE-2026-44249
• https://github.com/netty/netty
• https://github.com/netty/netty/releases/tag/netty-4.1.135.Final
• https://github.com/netty/netty/releases/tag/netty-4.2.15.Final

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Netty: Wrapping plain trust manager silently disables hostname verification

CVE-2026-50010 / GHSA-c653-97m9-rcg9

More information

Details

SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) performs no hostname verification at all.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/netty/netty/security/advisories/GHSA-c653-97m9-rcg9
• https://nvd.nist.gov/vuln/detail/CVE-2026-50010
• https://github.com/netty/netty
• https://github.com/netty/netty/releases/tag/netty-4.1.135.Final
• https://github.com/netty/netty/releases/tag/netty-4.2.15.Final

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Netty: SNI handler pre-allocates up to 16 MiB from nine attacker bytes

CVE-2026-45416 / GHSA-x4gw-5cx5-pgmh

More information

Details

SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates ctx.alloc().buffer(handshakeLength) (line 161). The guard at line 140 is handshakeLength > maxClientHelloLength && maxClientHelloLength != 0, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/netty/netty/security/advisories/GHSA-x4gw-5cx5-pgmh
• https://nvd.nist.gov/vuln/detail/CVE-2026-45416
• https://github.com/netty/netty
• https://github.com/netty/netty/releases/tag/netty-4.1.135.Final
• https://github.com/netty/netty/releases/tag/netty-4.2.15.Final

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Netty: SNI Routing Bypass via Fragmented TLS ClientHello Causing Fallback to Default SslContext

CVE-2026-75595 / GHSA-c4c3-7fpv-j4q5

More information

Details

Summary

A fragmented TLS ClientHello whose handshake header spans multiple records makes Netty silently fall back to the default SslContext; where per-SNI selection is the sole mTLS gate, an unauthenticated attacker can bypass the route's mTLS requirement.

Details

In io.netty.handler.ssl.SslClientHelloHandler#decode the guard that should wait for the 4-byte handshake header checks the wrong offset - it ignores the 5-byte record header that precedes it - and therefore never fires:

if (handshakeLength == -1) {
    if (readerIndex + 4 > endOffset) {
        // Need more data to read HandshakeType and handshakeLength (4 bytes)
        return;
    }

When the first record's payload is < 4 bytes, handshakeLength = in.getUnsignedMedium(readerIndex + SslUtils.SSL_RECORD_HEADER_LENGTH + 1); leads to IndexOutOfBoundsException . That is caught by the generic catch (Exception) block, which calls select(ctx, null) - this is the default SslContext. Fallback to default on parse failure is a problem when per-SNI selection is the sole mTLS gate.

Impact

SNI routing bypass. Escalates to an unauthenticated mTLS bypass only when:

• mTLS is enforced solely via per-SNI SslContext (clientAuth=REQUIRE)
• the default/fallback SslContext is permissive (clientAuth=NONE/OPTIONAL)
• no secondary peer-certificate verification exists at the application layer.

Severity

• CVSS Score: 9.1 / 10 (Critical)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

References

• https://github.com/netty/netty/security/advisories/GHSA-c4c3-7fpv-j4q5
• https://nvd.nist.gov/vuln/detail/CVE-2026-75595
• https://github.com/netty/netty/pull/17213
• https://github.com/netty/netty/pull/17217
• https://github.com/netty/netty/commit/1b5abc6443b63726c72cdd285af2feb7ddbb8ff7
• https://github.com/netty/netty/commit/9e0519239108a69b7e9bbc5e9182ee139a0d7961
• https://github.com/netty/netty
• https://github.com/netty/netty/releases/tag/netty-4.1.137.Final
• https://github.com/netty/netty/releases/tag/netty-4.2.17.Final

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Netty: Fragmented ClientHello records trigger quadratic pre-handshake reassembly in default SNI parsing

CVE-2026-75596 / GHSA-fccg-mwvh-qqg4

More information

Details

Summary

Netty's default SNI entrypoint reparses and recopies previously received ClientHello fragments on every additional TLS handshake record. A remote peer can send a small first record that advertises a large ClientHello length and then drip the body in many tiny records, causing superlinear (quadratic) CPU work before the handshake completes. With 4095 one-byte fragments, the handler recopies 8,386,560 bytes from only 24,579 bytes on the wire — a 341× amplification ratio.

Affected Entrypoints

• io.netty.handler.ssl.SniHandler — default constructors
• io.netty.handler.ssl.SslClientHelloHandler — pre-handshake ClientHello aggregation path

Vulnerable Code Locations

• handler/src/main/java/io/netty/handler/ssl/SniHandler.java:85
• handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:75 (decode entry)
• handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:165 (handshakeBuffer.clear)
• handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:174 (writeBytes re-copy)
• codec-base/src/main/java/io/netty/handler/codec/ByteToMessageDecoder.java:294 (cumulation retention)

Exploit Path

1. TCP connection → SniHandler → SslClientHelloHandler.decode
2. First record: TLS handshake header declaring large ClientHello length (e.g., 4096 bytes)
3. Attacker sends thousands of tiny follow-on handshake records (1 byte each)
4. On each fragment: handshakeBuffer.clear() + writeBytes() re-copies ALL accumulated body bytes
5. Total bytes copied = n*(n+1)/2 where n = number of body bytes → quadratic
6. Event-loop CPU exhausted before SslHandler takes over

Impact

• Vulnerability Type: Inefficient Algorithmic Complexity
• An unauthenticated network attacker can drive disproportionate CPU consumption on the Netty event loop
• Affects all Netty deployments using SniHandler for TLS termination (the default SNI path)
• No privileges, user interaction, or special configuration required
• Can degrade or stall TLS connection handling for all clients on the affected event loop
• The attack requires only modest bandwidth (~25 KB) to trigger significant CPU work

---

Credits

Found by a security research team from the University of Sydney, focusing on detecting open source software vulnerabilities.
Liyi Zhou: https://lzhou1110.github.io/
Ziyue Wang: https://zyy0530.github.io/
Strick: https://str1ckl4nd.github.io/
Maurice: https://maurice.busystar.org/
Chenchen Yu: https://7thparkk.github.io/

Severity

• CVSS Score: 6.9 / 10 (Medium)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

• https://github.com/netty/netty/security/advisories/GHSA-fccg-mwvh-qqg4
• https://nvd.nist.gov/vuln/detail/CVE-2026-75596
• https://github.com/netty/netty/pull/17213
• https://github.com/netty/netty/pull/17217
• https://github.com/netty/netty/commit/1b5abc6443b63726c72cdd285af2feb7ddbb8ff7
• https://github.com/netty/netty/commit/9e0519239108a69b7e9bbc5e9182ee139a0d7961
• https://github.com/netty/netty
• https://github.com/netty/netty/releases/tag/netty-4.1.137.Final
• https://github.com/netty/netty/releases/tag/netty-4.2.17.Final

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Configuration

📅 Schedule: (in timezone America/New_York)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit 661e124.

♻️ This comment has been updated with latest results.

[renovate]

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: gradle/libs.versions.toml

Command failed: ./gradlew -Dorg.gradle.jvmargs=-Xms512m -Xmx512m --console=plain --dependency-verification lenient -q --write-verification-metadata sha256 dependencies

FAILURE: Build completed with 2 failures.

1: Task failed with an exception.
-----------
* What went wrong:
A problem occurred configuring root project 'open-integration-engine'.
> Could not resolve all artifacts for configuration 'classpath'.
   > Could not resolve org.owasp:dependency-check-core:12.2.2.
     Required by:
         root project : > org.owasp.dependencycheck:org.owasp.dependencycheck.gradle.plugin:12.2.2 > org.owasp:dependency-check-gradle:12.2.2
      > Could not resolve org.owasp:dependency-check-core:12.2.2.
         > Could not get resource 'https://plugins.gradle.org/m2/org/owasp/dependency-check-core/12.2.2/dependency-check-core-12.2.2.pom'.
            > Could not GET 'https://repo.maven.apache.org/maven2/org/owasp/dependency-check-core/12.2.2/dependency-check-core-12.2.2.pom'. Received status code 429 from server: Too Many Requests
   > Could not resolve org.owasp:dependency-check-utils:12.2.2.
     Required by:
         root project : > org.owasp.dependencycheck:org.owasp.dependencycheck.gradle.plugin:12.2.2 > org.owasp:dependency-check-gradle:12.2.2
      > Could not resolve org.owasp:dependency-check-utils:12.2.2.
         > Could not get resource 'https://plugins.gradle.org/m2/org/owasp/dependency-check-utils/12.2.2/dependency-check-utils-12.2.2.pom'.
            > Could not GET 'https://repo.maven.apache.org/maven2/org/owasp/dependency-check-utils/12.2.2/dependency-check-utils-12.2.2.pom'. Received status code 429 from server: Too Many Requests
   > Could not resolve net.gpedro.integrations.slack:slack-webhook:1.4.0.
     Required by:
         root project : > org.owasp.dependencycheck:org.owasp.dependencycheck.gradle.plugin:12.2.2 > org.owasp:dependency-check-gradle:12.2.2
      > Could not resolve net.gpedro.integrations.slack:slack-webhook:1.4.0.
         > Could not get resource 'https://plugins.gradle.org/m2/net/gpedro/integrations/slack/slack-webhook/1.4.0/slack-webhook-1.4.0.pom'.
            > Could not GET 'https://repo.maven.apache.org/maven2/net/gpedro/integrations/slack/slack-webhook/1.4.0/slack-webhook-1.4.0.pom'. Received status code 429 from server: Too Many Requests

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
==============================================================================

2: Task failed with an exception.
-----------
* What went wrong:
A problem occurred configuring root project 'open-integration-engine'.
> Could not resolve all artifacts for configuration 'classpath'.
   > Could not resolve org.owasp:dependency-check-core:12.2.2.
     Required by:
         root project : > org.owasp.dependencycheck:org.owasp.dependencycheck.gradle.plugin:12.2.2 > org.owasp:dependency-check-gradle:12.2.2
      > Could not resolve org.owasp:dependency-check-core:12.2.2.
         > Could not get resource 'https://plugins.gradle.org/m2/org/owasp/dependency-check-core/12.2.2/dependency-check-core-12.2.2.pom'.
            > Could not GET 'https://repo.maven.apache.org/maven2/org/owasp/dependency-check-core/12.2.2/dependency-check-core-12.2.2.pom'. Received status code 429 from server: Too Many Requests
   > Could not resolve org.owasp:dependency-check-utils:12.2.2.
     Required by:
         root project : > org.owasp.dependencycheck:org.owasp.dependencycheck.gradle.plugin:12.2.2 > org.owasp:dependency-check-gradle:12.2.2
      > Could not resolve org.owasp:dependency-check-utils:12.2.2.
         > Could not get resource 'https://plugins.gradle.org/m2/org/owasp/dependency-check-utils/12.2.2/dependency-check-utils-12.2.2.pom'.
            > Could not GET 'https://repo.maven.apache.org/maven2/org/owasp/dependency-check-utils/12.2.2/dependency-check-utils-12.2.2.pom'. Received status code 429 from server: Too Many Requests
   > Could not resolve net.gpedro.integrations.slack:slack-webhook:1.4.0.
     Required by:
         root project : > org.owasp.dependencycheck:org.owasp.dependencycheck.gradle.plugin:12.2.2 > org.owasp:dependency-check-gradle:12.2.2
      > Could not resolve net.gpedro.integrations.slack:slack-webhook:1.4.0.
         > Could not get resource 'https://plugins.gradle.org/m2/net/gpedro/integrations/slack/slack-webhook/1.4.0/slack-webhook-1.4.0.pom'.
            > Could not GET 'https://repo.maven.apache.org/maven2/net/gpedro/integrations/slack/slack-webhook/1.4.0/slack-webhook-1.4.0.pom'. Received status code 429 from server: Too Many Requests

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
==============================================================================

BUILD FAILED in 34s