CVE-2026-44249 - Netty IPv6 subnet filter bypass

Netty’s IpSubnetFilterRule compares IPv6 addresses using the configured network address where it should use the subnet mask. In affected versions, public IPv6 addresses can match rules they should not satisfy, allowing remote clients to bypass subnet-based allow or deny controls implemented with io.netty.handler.ipfilter.IpSubnetFilterRule.

When to use it

Use this recipe when a Java or Netty-based service uses IpSubnetFilterRule or subnet-based access control to protect admin, internal, tenant, webhook, or agent-facing routes. It is designed for source-code remediation, IPv6 boundary testing, deny-by-default review, and audit evidence that public IPv6 clients cannot satisfy private subnet rules.

Inputs

  • io.netty:netty-handler version, dependency tree, gateway/server config, IP allow/deny lists, route inventory, and deployment ingress.
  • Source paths that instantiate IpSubnetFilterRule, normalize client IPs, trust proxy headers, apply route filters, or log access decisions.
  • Regression fixtures for in-subnet IPv4/IPv6, out-of-subnet IPv6, mapped addresses, proxy headers, denied defaults, and allowed known clients.
  • Boundary evidence: protected routes, trusted proxy chain, network policies, test traffic source, and deployment artifact versions.

Affected versions

  • Vulnerable package: io.netty:netty-handler <=4.1.134.Final
  • Vulnerable package: io.netty:netty-handler >=4.2.0.Final,<=4.2.14.Final
  • Fixed package: 4.1.135.Final, 4.2.15.Final
  • Affected surface: custom IPv6 allowlists, admin-plane listeners, control APIs, service-to-service filters, or edge listeners using IpSubnetFilter

Indicator-of-exposure

  • The repository depends on vulnerable netty-handler versions directly or transitively.
  • Application code uses IpSubnetFilterRule, RuleBasedIpFilter, AbstractRemoteAddressFilter, or custom Netty IP filtering.
  • IPv6 access restrictions protect internal admin endpoints, brokers, RPC listeners, or ingress services.
  • Security tests cover only IPv4 or only expected addresses, not bypass cases.

Quick checks:

rg -n "netty-handler|IpSubnetFilterRule|IpSubnetFilter|RuleBasedIpFilter|RemoteAddressFilter|Inet6Address|allowlist|allow-list|denylist|deny-list" .
mvn -q dependency:tree | rg "io\\.netty:netty-handler"
gradle dependencies --configuration runtimeClasspath | rg "netty-handler"

Windows:

rg -n "netty-handler|IpSubnetFilterRule|IpSubnetFilter|RuleBasedIpFilter|RemoteAddressFilter|Inet6Address|allowlist|allow-list|denylist|deny-list" .
mvn -q dependency:tree | rg "io\\.netty:netty-handler"
gradle dependencies --configuration runtimeClasspath | rg "netty-handler"

Do not expose admin listeners to the public internet to test bypasses and do not log full customer IP datasets while reviewing filter rules.

Remediation strategy

  • Upgrade every controlled io.netty:netty-handler reference to 4.1.135.Final+ or 4.2.15.Final+.
  • Re-run dependency convergence because Netty modules often drift together; keep the handler line aligned with the broader Netty set in your build.
  • Add explicit IPv6 regression tests for both allowed and denied addresses, including boundary conditions on the same prefix length.
  • If upgrade is blocked, apply a temporary fail-closed wrapper that performs independent IPv6 subnet checks before allowing connections.
  • Review exposed services that trusted IpSubnetFilterRule for authz or network-boundary enforcement and tighten upstream firewall rules if needed.

The prompt

You are remediating CVE-2026-44249 / GHSA-3qp7-7mw8-wx86, a high-severity Netty
IPv6 subnet filter bypass in `IpSubnetFilterRule.compareTo()`. Produce exactly
one output:

- A reviewer-ready PR/change request that upgrades Netty, hardens IPv6 filter
  validation, and documents operator actions, or
- TRIAGE.md if this repository does not control an affected Netty dependency,
  IPv6 filter, image, or deployment.

## Rules

- Scope only CVE-2026-44249 and directly related IPv6 subnet filtering code.
- Treat client IPs, tenant network data, firewall rules, and service topology
  as sensitive.
- Do not test against production admin endpoints or widen allowlists for
  convenience.
- Do not remove existing network restrictions without a documented safer
  replacement.
- Do not auto-merge.

## Steps

1. Inventory every controlled `io.netty:netty-handler` reference: Maven/Gradle
   manifests, lockfiles, BOMs, images, SBOMs, and generated dependency reports.
2. Determine every resolved Netty handler version. Targets are vulnerable if
   they resolve to `<=4.1.134.Final` or `>=4.2.0.Final,<=4.2.14.Final`.
3. Find all uses of `IpSubnetFilterRule`, `IpSubnetFilter`, `RuleBasedIpFilter`,
   or custom IPv6 subnet logic around Netty listeners.
4. Determine whether any such rule protects admin interfaces, cluster RPC,
   broker listeners, or otherwise sensitive services.
5. If the repository does not control an affected dependency or filter runtime,
   stop with `TRIAGE.md` listing checked files, external owner if known, and
   required fixed versions `4.1.135.Final` / `4.2.15.Final`.
6. Upgrade all controlled Netty handler references to the fixed line compatible
   with the project. Refresh lockfiles, BOM pins, images, SBOMs, and docs.
7. Add or tighten IPv6 regression coverage:
   - addresses inside the prefix are allowed only when intended;
   - addresses outside the prefix are denied;
   - boundary addresses around the subnet mask are tested;
   - deny rules fail closed on parse or configuration errors.
8. If immediate upgrade is blocked, add a temporary independent IPv6 mask check
   or push equivalent restrictions into a trusted upstream firewall/load
   balancer and document the containment.
9. Add a PR body section named `CVE-2026-44249 operator actions` that states:
   - Netty versions before and after;
   - which listeners or services relied on IPv6 subnet filtering;
   - whether a temporary upstream network control was added;
   - which validation commands passed.
10. Run available validation: dependency resolution, unit/integration tests,
    listener tests, static analysis, container build, SBOM refresh, and
    non-secret smoke checks.
11. Use PR title:
    `fix(sec): remediate CVE-2026-44249 in netty-handler`.

## Stop conditions

- No affected Netty dependency, IPv6 filter, image, or deployment is controlled
  by this repository.
- Upgrade requires a broader framework or platform migration you cannot safely
  complete in-scope.
- Verification would require probing production-restricted endpoints.
- Validation fails for unrelated pre-existing reasons; document them instead of
  broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades netty-handler, adds deny-by-default IPv6 boundary tests, verifies proxy/header handling, and documents rollout.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, subnet rule boundary, protected routes, required fix, and residual risk.
  • The output must include exact validation commands and must not scan production networks, disclose allow-lists, or expose internal route data.

Verification - what the reviewer looks for

  • No controlled build resolves vulnerable netty-handler versions.
  • IPv6 subnet rules deny addresses outside the configured prefix.
  • Tests cover both accepted and rejected IPv6 samples around the mask boundary.
  • Operator notes identify any compensating network controls if used.

Watch for

  • Upgrading only a BOM or parent POM while a lockfile or image still resolves an old Netty line.
  • Testing only happy-path addresses from inside the allowed subnet.
  • Relying on subnet filtering as the sole authz control for sensitive endpoints.
  • Mixing incompatible Netty module versions while patching netty-handler.

References