Netty CVE-2026-44249: Brief Summary of the IPv6 Subnet Filter Bypass in IpSubnetFilterRule

Introduction

Two subtle logic errors in Netty's IPv6 subnet filtering have been undermining access control for any application that relies on IpSubnetFilterRule to restrict connections by source address. Netty is an open-source framework embedded in the infrastructure of Google, Apple, Red Hat, Uber, WhatsApp, and over 750 other organizations, so the downstream blast radius of CVE-2026-44249 extends far beyond any single deployment.

The vulnerability is scored CVSS 8.1 (High) and allows remote, unauthenticated attackers to bypass IPv6 subnet rules in Netty's netty-handler module. The root cause is an incorrect bitwise masking operation compounded by a signed integer interpretation bug, both in IpSubnetFilterRule.compareTo(). Patched versions (4.1.135.Final and 4.2.15.Final) were released on June 1 and June 2, 2026, and the public advisory followed on June 5. No workarounds exist.

Technical Information

Root Cause: Two Distinct Bugs in One Method

CVE-2026-44249 consists of two independent logic errors in io.netty.handler.ipfilter.IpSubnetFilterRule, both on the IPv6 code path. Either bug alone is enough to break subnet filtering. Together they create a comprehensive bypass.

Bug #1: Wrong operand in the bitwise AND (the masking bug)

The compareTo() method determines whether an incoming IPv6 address falls within a configured subnet. It should apply the subnet mask to the incoming address with a bitwise AND, then compare the result against the stored networkAddress. The vulnerable code instead ANDed the incoming IP with the networkAddress itself rather than the subnetMask:

- .and(ip6SubnetFilterRule.networkAddress));
+ .and(ip6SubnetFilterRule.subnetMask));

Consider a /52 subnet with a mask of FFFF:FFF0::. The correct operation masks out the lower 76 bits of the incoming address and leaves only the network prefix for comparison. With networkAddress as the mask operand, the masking depends on the value of the network address rather than the prefix length. For many real-world subnets, this lets certain public IPv6 addresses through the filter even though they should be blocked, because the network address bits do not zero out the right bits in the host portion.

Bug #2: Signed interpretation of IPv6 address bytes

The Ip6SubnetFilterRule.ipToInt() helper converts a 16-byte IPv6 address into a BigInteger for arithmetic comparison. The vulnerable code used the single-argument BigInteger(byte[]) constructor:

- return new BigInteger(octets);
+ return new BigInteger(1, octets);

That constructor treats the byte array as a two's-complement signed number. Any IPv6 address whose first byte has the most significant bit set (any address in the range 8000:: through FFFF::) would be interpreted as a negative BigInteger. This breaks the comparison entirely. The masked result of such an address would always compare as less than any positive network address, so those IPs bypass the filter regardless of the subnet rule. The fix passes 1 as the signum parameter, which makes the constructor always read the byte array as a positive unsigned integer.

CWE Classification

The two CWE assignments follow the causal chain. CWE-697 (Incorrect Comparison) describes the root cause: the code compares values using the wrong operand and the wrong numeric interpretation. CWE-284 (Improper Access Control) describes the security consequence: the broken comparison produces an access control bypass that lets unauthorized IPs through the filter.

Attack Flow

An attacker targeting a Netty-based server that uses IpSubnetFilterRule for IPv6 access control would follow this general path:

1. Determine that the target service is built on Netty and uses IpSubnetFilterRule or RuleBasedIpFilter for IPv6-based access control. Server behavior, error messages, or knowledge of the application stack could reveal this.

2. Craft a source IPv6 address that, when bitwise ANDed with the target's configured networkAddress (not the subnet mask), produces a value that satisfies the broken comparison logic. Alternatively, use any IPv6 address in the 8000::/1 range (the upper half of the IPv6 address space). Bug #2 interprets such an address as a negative BigInteger, so it automatically compares as less than any positive network address and bypasses the filter.

3. Connect to the protected service from the crafted address. Because compareTo() applies the wrong mask and/or misreads the address as a negative number, the filter wrongly classifies the connection as permitted.

4. Reach whatever the filter was protecting. The CVSS vector assigns High impact to confidentiality, integrity, and availability, so depending on what sits behind the filter, the attacker could read sensitive data, modify resources, or disrupt service availability.

The CVSS vector rates attack complexity High (AC:H) because the attacker must either know the configured subnet rules to craft a matching address for Bug #1, or source traffic from the upper half of the IPv6 address space for Bug #2. No authentication or user interaction is required.

Patch Information

The Netty maintainers fixed CVE-2026-44249 in PR #16860, authored by Norman Maurer and merged on June 1, 2026 (commit 53c089f). The fix is compact. It changes 2 lines of production code in a single file (IpSubnetFilterRule.java), and each line corrects a distinct, critical logic error.

The first change replaces the incorrect networkAddress operand with the correct subnetMask in the bitwise AND:

- .and(ip6SubnetFilterRule.networkAddress));
+ .and(ip6SubnetFilterRule.subnetMask));

The second change fixes the signed interpretation by passing an explicit positive signum to the BigInteger constructor:

- return new BigInteger(octets);
+ return new BigInteger(1, octets);

The commit also adds two unit tests, testIpv6MaskCorrectlyApplied() and testIpv6MatchesNoFalsePositiveForAllOnesNetworkBits(), that exercise both scenarios to prevent regressions.

The patched versions are:

There are no documented workarounds, and the GitHub security advisory describes no compensating controls short of upgrading. Organizations that cannot upgrade immediately should consider enforcing IPv6 subnet restrictions at the network layer (firewall rules upstream of the Netty-based service) as an interim measure, though the Netty project has not validated this approach.

Many applications consume Netty transitively through other frameworks. The OpenMetadata project, for example, found that its pom.xml pinned io.netty:netty-bom to 4.1.133.Final, which transitively pulled in the vulnerable netty-handler artifact. That discovery led to a BOM upgrade to 4.1.135.Final. Organizations should analyze the full dependency tree to find every path that pulls in io.netty:netty-handler.

Detection Methods

The primary way to detect CVE-2026-44249 is version-based dependency scanning with Software Composition Analysis (SCA) tools. The vulnerability is a logic error in Netty's internal IP filtering code, so it produces no distinctive network traffic signature for traditional IDS/IPS rules to match. On the wire, the attacker's IPv6 traffic would look structurally normal.

Multiple vulnerability databases have catalogued this CVE under the advisory identifier GHSA-3qp7-7mw8-wx86 for the Maven artifact io.netty:netty-handler. The following scanning tools and databases have confirmed coverage:

• GitLab Dependency Scanning: The GitLab Advisory Database entry confirms detection support for this CVE.
• Docker Scout: Has indexed CVE-2026-44249, so container image scans will flag vulnerable Netty handler versions bundled in image layers.
• Snyk, Meterian, Tenable, and TuxCare: All track this CVE for io.netty:netty-handler and feed into automated scanning workflows.

A review of the NSFOCUS NIPS/IPS signature library update lists, covering rule versions through June 2026, found no dedicated intrusion prevention signature for CVE-2026-44249. That is consistent with a logic flaw that leaves no distinctive traffic signature.

For behavioral detection, security teams should audit application access logs for unexpected IPv6 source addresses reaching endpoints that subnet rules should restrict. On a vulnerable Netty version with IPv6 subnet filter rules in use, any connection from outside the intended subnet that is accepted rather than rejected could indicate that the flawed masking logic is in effect. Spotting it requires knowing the specific subnet rules configured in the application.

Affected Systems and Versions

The vulnerability affects the io.netty:netty-handler Maven artifact across two active release branches:

• Netty 4.1.x: All versions prior to 4.1.135.Final
• Netty 4.2.x: Versions 4.2.0.Final through 4.2.14.Final

A deployment is functionally vulnerable only if it uses IpSubnetFilterRule (or RuleBasedIpFilter configured with subnet rules) for IPv6 access control. The vulnerable code still ships in every netty-handler build in the affected version ranges, so treat any application that bundles these versions as at risk if IPv6 filtering is or could be enabled.

The patched versions are 4.1.135.Final and 4.2.15.Final.

Vendor Security History

Netty has accumulated 49 CVEs according to OpenCVE, with at least 7 disclosed in the past year. Recent notable vulnerabilities include:

The recurring access control and protocol handling flaws reflect the complexity of a framework that provides flexible, high-performance network programming primitives. The CWE-697 (Incorrect Comparison) classification for CVE-2026-44249 covers bugs where the code functionally "works" but compares the wrong operands, which makes these defects particularly hard to catch with standard testing.

On the positive side, the Netty project maintains a formal security policy, publishes advisories through GitHub's advisory system, and follows responsible disclosure practices. For CVE-2026-44249, the patches shipped on June 1 and June 2, several days before the public advisory on June 5, which gave downstream consumers time to prepare.

References

• NVD: CVE-2026-44249
• GitHub Security Advisory: GHSA-3qp7-7mw8-wx86
• GitHub Advisory API: GHSA-3qp7-7mw8-wx86
• Netty PR #16860 (Fix)
• Commit 53c089f
• Netty 4.1.135.Final Release
• Netty 4.2.15.Final Release
• GitLab Advisory Database: CVE-2026-44249
• Docker Scout: CVE-2026-44249
• OSV.dev: GHSA-3qp7-7mw8-wx86
• Vulners: CVE-2026-44249
• Miggo Vulnerability Database: CVE-2026-44249
• Strobes: CVE-2026-44249
• OpenMetadata Issue #28879: Bump netty-bom for CVE-2026-44249
• Netty Adopters
• Netty Downloads
• OpenCVE: Netty CVEs
• Netty Security Policy
• IpSubnetFilterRule API Reference (4.1.135.Final)
• NSFOCUS IPS Signature Updates