CVE-2026-44249

What it actually does

Netty's netty-handler component contains an authorization bypass in IPv6 subnet filtering before 4.1.135.Final and 4.2.15.Final. The vulnerable logic performs an incorrect masking operation in IpSubnetFilterRule.compareTo(), which can cause IPv6 subnet allow/deny rules to be evaluated incorrectly. When an application relies on Netty IpSubnetFilterRule for network-level access control, a remote unauthenticated attacker using a crafted or strategically selected valid public IPv6 address may bypass intended subnet restrictions and reach services or functionality that should have been blocked.

Why it matters to the business

Applications that depend on Netty for IP-based access control may unintentionally expose restricted administrative, internal, partner-only, or sensitive network services to unauthorized IPv6 clients. Although public exploitation is not currently reported, the flaw has a high CVSS score because a successful bypass can undermine confidentiality, integrity, and availability controls. Organizations using Netty broadly through direct or transitive Java dependencies should treat this as a priority patching item, especially for internet-facing services or services that rely on IPv6 allowlists or denylists.

How an attack unfolds

An attacker first identifies an application or protocol service built on Netty that accepts IPv6 traffic and uses netty-handler IpSubnetFilterRule to enforce subnet-based access restrictions. The attacker then connects from a public IPv6 address that triggers the vulnerable subnet comparison behavior. Because of the incorrect masking operation, the application may incorrectly conclude that the attacker's address is permitted or not denied. If the subnet filter is used as a security boundary, the attacker can reach protected endpoints or services without credentials or prior access, then attempt follow-on actions such as accessing sensitive data, invoking administrative functions, probing internal APIs, or chaining the exposure with application-layer vulnerabilities.

How to fix it

Upgrade netty-handler to a fixed release: 4.1.135.Final or later for the 4.1.x line, or 4.2.15.Final or later for the 4.2.x line. Because Netty is commonly included as a transitive dependency, review Maven, Gradle, shaded JARs, application server bundles, container images, and vendor-provided packages for embedded vulnerable versions. If immediate upgrade is not possible, enforce IPv6 subnet restrictions outside the application using firewalls, security groups, load balancers, reverse proxies, service mesh policy, or WAF/network ACL controls. Consider temporarily disabling IPv6 exposure where it is not required, and avoid relying solely on Netty IpSubnetFilterRule as the security boundary until the patched version is deployed.

How to confirm the fix worked

Confirm that all deployed artifacts resolve netty-handler to 4.1.135.Final or later, or 4.2.15.Final or later. Use software composition analysis, dependency tree inspection, container image scanning, and runtime classpath inspection to identify direct, transitive, and shaded copies of Netty. Validate behavior with regression tests that exercise IPv6 allowlist and denylist rules, including public IPv6 addresses outside permitted ranges, and verify that unauthorized addresses are rejected. For internet-facing services, perform an external IPv6 connectivity test from addresses that should be denied and confirm that access is blocked at the network or application layer.

Typical attack path

1. Identify an internet-accessible or reachable service implemented with Netty and accepting IPv6 connections.
2. Determine or infer that the service uses Netty IP subnet filtering for allowlist or denylist enforcement.
3. Connect from a valid public IPv6 address chosen to evade the vulnerable subnet comparison logic.
4. Bypass the intended IPv6 subnet restriction and establish access to a protected service or endpoint.
5. Use the unauthorized network access to enumerate functionality, access data, attempt authentication bypasses, or chain additional vulnerabilities.

How to detect it

To determine whether this was already exploited, review application access logs, Netty service logs, reverse proxy logs, load balancer logs, WAF logs, cloud flow logs, firewall logs, and authentication logs for IPv6 clients that successfully reached endpoints intended to be limited to specific subnets. Focus on requests from public IPv6 addresses outside approved allowlists or inside configured deny ranges, especially to administrative interfaces, internal APIs, management ports, partner-only endpoints, or services that normally have very narrow source ranges. Compare historical accepted IPv6 source addresses against the configured subnet rules that were in effect at the time. Look for unusual first-time IPv6 sources, successful requests without expected upstream proxy or VPN source addresses, spikes in denied-versus-allowed mismatches, and follow-on activity such as enumeration, repeated 401/403 responses followed by successful access, or access to sensitive functionality. There are no known universal payload strings or malware artifacts for this vulnerability; detection is primarily based on policy-violation analysis of IPv6 source addresses versus intended subnet controls.

What your security team should do

• Prioritize inventory of internet-facing and security-sensitive Java services using Netty, especially those accepting IPv6 traffic or enforcing IP allowlists/denylists.
• Upgrade netty-handler to 4.1.135.Final, 4.2.15.Final, or later across direct, transitive, shaded, and containerized deployments.
• Add compensating IPv6 filtering at perimeter firewalls, load balancers, reverse proxies, or cloud security controls until application dependencies are verified fixed.
• Review services that rely on IP-based access control as a primary trust boundary and add authentication, authorization, and network segmentation where missing.
• Search historical access logs for successful IPv6 connections from addresses outside expected allowed ranges to restricted endpoints.
• Add regression tests for IPv6 subnet filter behavior to prevent dependency downgrades or future masking-rule regressions.
• Monitor vulnerability intelligence for emerging proof-of-concept exploit details, because current exploit maturity is reported as none and the issue is not listed in KEV.