CVE-2026-44250 - Netty Redis array depth denial of service

Netty’s Redis codec aggregates nested Redis arrays using an internal stack of aggregate states. In affected versions, there is no depth limit. An attacker can stream a large number of nested array headers such as repeated *1 frames, forcing allocation of many AggregateState objects and backing collections until the process runs out of heap and crashes.

When to use it

Use this recipe when a Java service, gateway, proxy, broker, sidecar, or custom listener parses Redis/RESP traffic with Netty. It is most useful when Redis protocol traffic can come from untrusted clients, shared tenants, internet edges, test harnesses, or managed integration partners.

The goal is bounded parser remediation: upgrade the codec, prove safe nested array rejection, and document listener-level controls without generating destructive heap-exhaustion traffic.

Inputs

  • Maven/Gradle manifests, BOMs, lockfiles, SBOMs, image metadata, deployment manifests, and dependency reports that may resolve io.netty:netty-codec-redis.
  • Netty channel pipelines, Redis/RESP parser wrappers, gateway/proxy code, listener configuration, and parser tests.
  • Resolved Netty module versions across the full runtime, not only the Redis codec, so mixed-module drift can be detected.
  • Exposure evidence for Redis listeners: internet access, tenant boundaries, internal-only placement, rate limits, TLS/auth, memory caps, read timeouts, and restart supervision.
  • Existing validation commands for Java tests, dependency resolution, container builds, SBOM refresh, and non-secret smoke checks.

Affected versions

  • Vulnerable package: io.netty:netty-codec-redis <=4.1.134.Final
  • Vulnerable package: io.netty:netty-codec-redis >=4.2.0.Final,<=4.2.14.Final
  • Fixed package: 4.1.135.Final, 4.2.15.Final
  • Affected surface: any server or proxy that parses untrusted Redis protocol traffic with RedisArrayAggregator

Indicator-of-exposure

  • The repository depends on vulnerable netty-codec-redis versions directly or transitively.
  • Netty parses RESP/Redis traffic for brokers, gateways, proxies, sidecars, or custom services reachable by untrusted clients or shared tenants.
  • The pipeline includes RedisDecoder, RedisBulkStringAggregator, or RedisArrayAggregator.
  • There are no parser depth limits, frame guards, or connection-level memory circuit breakers around Redis ingestion.

Quick checks:

rg -n "netty-codec-redis|RedisArrayAggregator|RedisDecoder|RedisMessage|RESP|redis protocol|ChannelPipeline" .
mvn -q dependency:tree | rg "io\\.netty:netty-codec-redis"
gradle dependencies --configuration runtimeClasspath | rg "netty-codec-redis"

Windows:

rg -n "netty-codec-redis|RedisArrayAggregator|RedisDecoder|RedisMessage|RESP|redis protocol|ChannelPipeline" .
mvn -q dependency:tree | rg "io\\.netty:netty-codec-redis"
gradle dependencies --configuration runtimeClasspath | rg "netty-codec-redis"

Do not send heap-exhaustion payloads at production Redis listeners and do not capture customer traffic for reproduction.

Remediation strategy

  • Upgrade every controlled io.netty:netty-codec-redis dependency to 4.1.135.Final+ or 4.2.15.Final+.
  • Keep the broader Netty dependency set aligned to avoid mixed-module drift.
  • Add parser regression tests for excessive nested arrays and assert the connection is rejected before unbounded heap growth.
  • Add connection-level resource controls where feasible: inbound frame quotas, read timeouts, rate limits, per-connection memory caps, or protected listener segmentation.
  • If internet exposure exists, review listener placement and upstream rate limiting because parser fixes do not replace perimeter controls.

The prompt

You are remediating CVE-2026-44250 / GHSA-3244-j874-rhc2, a high-severity Netty
Redis codec memory-exhaustion issue caused by unlimited nested array depth.
Produce exactly one output:

- A reviewer-ready PR/change request that upgrades the Redis codec, adds safe
  parser limits and regression coverage, and documents operator actions, or
- TRIAGE.md if this repository does not control an affected Netty Redis codec,
  listener, image, or deployment.

## Rules

- Scope only CVE-2026-44250 and directly related Redis protocol parsing paths.
- Treat Redis traffic, tenant identifiers, credentials, and internal topology as
  sensitive.
- Do not run heap-exhaustion proofs against shared or production services.
- Do not remove authentication, TLS, or rate limits as a shortcut.
- Do not auto-merge.

## Steps

1. Inventory every controlled `io.netty:netty-codec-redis` reference across
   manifests, lockfiles, BOMs, images, SBOMs, and generated reports.
2. Determine every resolved version. Targets are vulnerable if they resolve to
   `<=4.1.134.Final` or `>=4.2.0.Final,<=4.2.14.Final`.
3. Find all Redis/RESP parsing pipelines using Netty codecs, proxies, or custom
   decoders.
4. Determine which listeners are reachable by untrusted clients, shared tenants,
   or internet-facing proxies.
5. If the repository does not control an affected dependency or 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 codec references to the fixed line compatible with the
   project. Refresh BOMs, lockfiles, images, SBOMs, and docs.
7. Add regression tests and guardrails:
   - nested-array payloads are rejected safely;
   - the connection closes or errors before unbounded allocations occur;
   - normal Redis traffic still parses correctly;
   - logging does not emit attacker payload bodies.
8. Where feasible, add operational containment:
   - request/frame size limits;
   - upstream rate limiting;
   - listener segmentation or private-network exposure only;
   - memory restart supervision for parser workers.
9. Add a PR body section named `CVE-2026-44250 operator actions` that states:
   - Netty versions before and after;
   - which Redis listeners or parsers were patched or triaged;
   - what connection or perimeter limits were added;
   - which validation commands passed.
10. Run available validation: dependency resolution, unit/integration tests,
    Redis parser tests, static analysis, container build, SBOM refresh, and
    non-secret smoke checks.
11. Use PR title:
    `fix(sec): remediate CVE-2026-44250 in netty-codec-redis`.

## Stop conditions

- No affected Netty Redis codec, listener, image, or deployment is controlled by
  this repository.
- Upgrade requires an out-of-scope framework migration.
- Verification would require destructive heap-exhaustion tests on shared
  systems.
- Validation fails for unrelated pre-existing reasons; document them instead of
  broadening scope.

Verification - what the reviewer looks for

  • No controlled dependency graph resolves vulnerable netty-codec-redis versions.
  • Regression tests reject excessive nested arrays without exhausting heap.
  • Upstream or connection-level limits exist for exposed Redis parsing surfaces.
  • The broader Netty module set remains version-consistent.

Watch for

  • Upgrading only one Netty module while the runtime still ships an old codec.
  • Adding tests that allocate huge payloads instead of asserting bounded failure.
  • Treating parser patching as sufficient when the listener is still publicly exposed without rate limits.
  • Logging attacker-controlled Redis payloads while debugging.

Output contract

Return one of:

  • A reviewer-ready PR/change request that upgrades netty-codec-redis to 4.1.135.Final+ or 4.2.15.Final+, keeps Netty modules aligned, adds bounded nested-array regression coverage, refreshes generated artifacts, and documents listener-level containment.
  • TRIAGE.md when no controlled affected codec, listener, image, or deployment exists, or when the fix requires an out-of-scope framework migration.

The output must list resolved versions before/after, Redis parser/listener surfaces, exposure classification, connection or perimeter controls, validation commands, and remaining operator actions. It must not include production traffic captures, credentials, tenant identifiers, internal topology details, or destructive heap-exhaustion payloads.

References