CVE-2026-44249: Netty IPv6 Subnet Filter Bypass Vulnerability (CVSS 8.1)

Technical summary

The vulnerability resides in netty-handler's IpSubnetFilterRule.compareTo() method, which performs bitwise operations to determine whether an incoming IPv6 address matches restricted subnets. The masking operation is implemented incorrectly, causing the comparison logic to produce false negatives. As a result, valid public IPv6 addresses that fall outside the configured subnet rules are incorrectly permitted through. This is a logic error rather than a memory safety issue, but it undermines the security properties that applications depend on when deploying IPv6 firewall rules via Netty.

Business impact

Organizations using Netty-based services to enforce IPv6 network segmentation or access control policies face a direct bypass of those controls. An attacker on the internet could circumvent IP-based allowlists, potentially accessing backend services, APIs, or administrative interfaces that should be restricted to trusted subnets. The blast radius depends on how heavily the organization relies on IPv6 filtering as a security boundary; if IPv6 access control is a primary defense layer, this flaw could lead to unauthorized data access, service disruption, or lateral movement.

Affected systems

Netty versions prior to 4.1.135.Final (in the 4.1.x branch) and prior to 4.2.15.Final (in the 4.2.x branch) are affected. Any application using netty-handler from these branches and deploying IpSubnetFilterRule for IPv6 filtering is at risk. This includes microservices, API gateways, message brokers, and other networked Java applications that depend on Netty for connection handling.

Exploitability

Exploitation requires network access to a Netty-based service that is actively enforcing IPv6 subnet rules. An attacker would need to craft an IPv6 request that should logically be filtered but instead passes through due to the masking bug. The CVSS vector (AV:N/AC:H/PR:N/UI:N) indicates network accessibility but acknowledges that successful exploitation requires some specific conditions to be met—for instance, the target must actually be using IPv6 filtering rules and must have misconfigured or relied on Netty's filtering as a primary security control. This is not a trivial remote code execution; rather, it is a targeted access control bypass for organizations whose security architecture depends on Netty's IPv6 filtering.

Remediation

Upgrade netty-handler to version 4.1.135.Final or later (if on the 4.1.x branch) or to version 4.2.15.Final or later (if on the 4.2.x branch). These versions include a corrected masking operation that properly evaluates IPv6 subnet membership. Before upgrading, confirm your application's dependency on netty-handler and test the new version in a staging environment to ensure compatibility.

Patch guidance

Identify all projects and services that depend on netty-handler via your build automation or dependency scanning tools. For Maven projects, check your pom.xml and transitive dependencies. For Gradle, review build.gradle files. Prioritize applications that explicitly use IpSubnetFilterRule or that deploy IPv6-based access control policies. Plan upgrades in coordination with your deployment pipeline, testing particularly any authentication, authorization, or rate-limiting logic that relies on IP filtering. If you are on the 4.1.x line, upgrade to 4.1.135.Final or later; if on 4.2.x, upgrade to 4.2.15.Final or later. Verify against the official Netty release notes to confirm patch availability for your exact branch.

Detection guidance

Audit your codebase for instantiation of IpSubnetFilterRule, particularly with IPv6 CIDR blocks. Review firewall and network access logs for unexpected or anomalous IPv6 traffic that coincides with your Netty service deployments. If you suspect exploitation, look for IPv6 addresses that should have been filtered by your rules but appear in application logs or access traces. Implement enhanced monitoring on services that rely on IPv6 filtering to detect patterns consistent with bypass attempts, such as repeated connection attempts from public IPv6 ranges that your rules should have blocked.

Why prioritize this

This vulnerability merits high priority because it directly undermines network access controls in security-conscious deployments. Although it requires specific configuration (active use of IPv6 filtering rules) and some attack conditions, the impact on affected systems is severe: it enables complete bypass of intended subnet restrictions. Organizations that have already invested in IPv6-based network segmentation or that operate in compliance regimes requiring such controls should treat this as urgent. The CVSS score of 8.1 reflects the confluence of network accessibility and high impact. Remediation is straightforward and low-risk, making swift patching feasible.

Risk score, explained

CVSS 3.1 score of 8.1 (HIGH severity) reflects: (1) Network-based attack vector (AV:N), allowing remote exploitation; (2) High complexity (AC:H), indicating the attack requires specific conditions such as IPv6 rules being active; (3) No privileges required (PR:N) and no user interaction (UI:N); (4) Confidentiality, integrity, and availability all rated as high (C:H/I:H/A:H), because a successful bypass can lead to unauthorized access, modification of data or behavior, or disruption of services. The score appropriately captures that while exploitation is not trivial for all deployments, the impact on vulnerable configurations is substantial.

Frequently asked questions