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

Introduction

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

The vulnerability, scored at CVSS 8.1 (High), 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 residing in IpSubnetFilterRule.compareTo(). Patched versions (4.1.135.Final and 4.2.15.Final) were released on June 1 and June 2, 2026, with the public advisory following 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 within the IPv6 code path. Each bug alone is sufficient to break subnet filtering; together they create a comprehensive bypass.

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

The compareTo() method is responsible for determining whether an incoming IPv6 address falls within a configured subnet. The correct approach is to apply the subnet mask to the incoming address via bitwise AND, then compare the result against the stored networkAddress. However, the vulnerable code was ANDing the incoming IP with the networkAddress itself instead of 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, isolating only the network prefix for comparison. By using the networkAddress as the mask operand instead, the masking behavior becomes dependent on the value of the network address rather than the prefix length. For many real world subnets, this causes certain public IPv6 addresses to pass through the filter even though they should be blocked, because the network address bits do not zero out the correct host portion bits.

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);

The single argument 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 comparisons entirely: the masked result of such an address would always compare as less than any positive network address, effectively letting those IPs bypass the filter regardless of the subnet rule. The fix passes 1 as the signum parameter, ensuring the byte array is always interpreted as a positive unsigned integer.

CWE Classification

The dual CWE assignment reflects 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 leads to an access control bypass where unauthorized IPs are permitted 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. Identify the target: Determine that the target service is built on Netty and uses IpSubnetFilterRule or RuleBasedIpFilter for IPv6 based access control. This could be inferred from server behavior, error messages, or knowledge of the application stack.

2. Craft a source IPv6 address: The attacker needs an 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, any IPv6 address in the 8000::/1 range (the upper half of the IPv6 address space) would be interpreted as a negative BigInteger, automatically comparing as less than any positive network address and bypassing the filter through Bug #2.

3. Connect to the protected service: The attacker initiates a connection from the crafted IPv6 address. Because the compareTo() method applies the wrong mask and/or misinterprets the address as a negative number, the filter incorrectly classifies the connection as permitted.

4. Access restricted resources: With the subnet filter bypassed, the attacker gains access to whatever the filter was protecting. The CVSS vector assigns High impact to confidentiality, integrity, and availability, meaning the attacker could read sensitive data, modify resources, or disrupt service availability depending on what lies behind the filter.

The attack complexity is rated High (AC:H) in the CVSS vector because the attacker must either know the configured subnet rules to craft a matching address for Bug #1, or must 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 addressed CVE-2026-44249 through PR #16860, authored by Norman Maurer and merged on June 1, 2026 (commit 53c089f). The fix is compact: just 2 lines of production code changed across a single file (IpSubnetFilterRule.java), but each line corrects a distinct and critical logic error.

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

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

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

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

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

The patched versions are:

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

Many applications consume Netty transitively through other frameworks. The OpenMetadata project, for example, discovered that its pom.xml pinned io.netty:netty-bom to 4.1.133.Final, which transitively pulled the vulnerable netty-handler artifact, prompting a BOM upgrade to 4.1.135.Final. Organizations should perform a full dependency tree analysis to identify all paths that pull in io.netty:netty-handler.

Detection Methods

The primary detection method for CVE-2026-44249 is version based dependency scanning through Software Composition Analysis (SCA) tools. Because this vulnerability is a logic error within Netty's internal IP filtering code, it does not produce a distinctive network traffic signature that traditional IDS/IPS rules can match. The attacker's IPv6 traffic on the wire would appear structurally normal.

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

• GitLab Dependency Scanning: The GitLab Advisory Database entry explicitly confirms detection support for this CVE.
• Docker Scout: Has indexed CVE-2026-44249, meaning 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 revealed no dedicated intrusion prevention signature for CVE-2026-44249. This is consistent with the nature of the flaw.

For behavioral detection, security teams should audit application access logs for unexpected IPv6 source addresses reaching endpoints that should be restricted by subnet rules. If IPv6 subnet filter rules are in use with a vulnerable Netty version, any connection from an IP outside the intended subnet that is being accepted rather than rejected could indicate the flawed masking logic is in effect. This requires knowledge of 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

Only deployments that use IpSubnetFilterRule (or RuleBasedIpFilter configured with subnet rules) for IPv6 access control are functionally vulnerable. However, since the vulnerable code ships in all netty-handler builds within the affected version ranges, any application bundling these versions should be considered 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 pattern of access control and protocol handling flaws reflects the inherent complexity of a framework that provides flexible, high performance network programming primitives. The CWE-697 (Incorrect Comparison) classification for CVE-2026-44249 points to a category of bugs where the code is functionally "working" but comparing the wrong operands, making these defects particularly difficult to catch through 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 were released on June 1 and June 2, several days before the public advisory on June 5, giving 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