Skip to main content

Netty CVE-2026-44250

HIGH
Uncontrolled Resource Consumption (CWE-400)
2026-06-08 https://github.com/netty/netty GHSA-3244-j874-rhc2
7.5
CVSS 3.1 · Vendor: https://github.com/netty/netty
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Identify Netty RESP listener
  2. Delivery
    Open TCP connection to decoder
  3. Exploit
    Stream unbounded nested array headers
  4. Execution
    RedisArrayAggregator allocates AggregateState per level
  5. Persist
    JVM heap exhausted, OutOfMemoryError thrown
  6. Impact
    Service crashes or becomes unresponsive

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK

1 technique across 1 tactic: Impact

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

The target application must use Netty's netty-codec-redis module and place RedisArrayAggregator (typically together with RedisDecoder) into a pipeline that processes RESP bytes from an untrusted peer - for example a Netty-based Redis proxy, a custom RESP-speaking server, or any service that forwards client-supplied Redis traffic. No authentication, no user interaction, and no special configuration beyond having the vulnerable pipeline reachable over the network are required (CVSS PR:N/UI:N/AC:L). Exploitation is limited to applications that actually expose the decoder to attacker-controlled bytes: a client that only uses netty-codec-redis to talk to its own trusted Redis server is not realistically exposed because it does not receive arbitrary RESP from attackers, and any network-layer restriction (firewall, mTLS, allowlist) on who can reach the RESP port directly reduces reachability.

Impact

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H accurately reflects a network-reachable, unauthenticated, low-complexity availability-only attack and produces a base score of 7.5 (High). EPSS and CISA KEV data were not supplied in the intelligence pack, so probabilistic exploitation likelihood and active exploitation status are unknown - treat the risk as 'high CVSS, unproven in-the-wild activity'. Practical risk depends heavily on exposure: a server that pipes attacker-controlled bytes into a Netty Redis decoder (for example a Redis-protocol proxy, an embedded RESP server, or a service that relays untrusted RESP traffic) is genuinely at risk, while applications that only use netty-codec-redis to talk to a trusted Redis backend face limited exposure because the 'attacker' would have to control the Redis server or the link to it. The description states 'untrusted Redis traffic' as the precondition, which aligns with the CVSS vector but is the limiting factor defenders should evaluate before prioritizing as a true 7.5.

Exploit ScenarioDerived

An attacker who can open a TCP connection to a service that decodes untrusted RESP traffic with RedisArrayAggregator (for example a Redis-protocol proxy or RESP-speaking server built on Netty) opens a single socket and streams an unbounded sequence of array-header frames such as *1\r\n*1\r\n*1\r\n.... The decoder pushes a new AggregateState plus a backing ArrayList for each header, and within seconds heap usage climbs until the JVM throws OutOfMemoryError and the process becomes unresponsive or crashes. No public exploit identified at time of analysis, but the payload is trivial to construct from the advisory description.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jun 08, 2026

Denial of service in Netty's netty-codec-redis module (versions <= 4.1.134.Final and 4.2.0.Final through 4.2.14.Final) allows remote unauthenticated attackers to exhaust JVM heap memory by sending Redis payloads with unbounded nested array headers. The RedisArrayAggregator allocates a new AggregateState and ArrayList for every nested array header without enforcing a depth limit, so a continuous stream of *1\r\n headers triggers an OutOfMemoryError. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.

RemediationAI

Vendor-released patch: upgrade to io.netty:netty-codec-redis 4.1.135.Final (4.1.x line) or 4.2.15.Final (4.2.x line) as documented at https://github.com/netty/netty/releases/tag/netty-4.1.135.Final and https://github.com/netty/netty/releases/tag/netty-4.2.15.Final and tracked in advisory https://github.com/netty/netty/security/advisories/GHSA-3244-j874-rhc2. If upgrading the Netty dependency cannot be done immediately, restrict the RESP-accepting endpoint to trusted peers via network ACLs or mTLS so only authenticated Redis clients can reach the decoder, or front the service with a Redis-aware proxy that rejects pathologically nested arrays - note that ACL-based mitigations only help where the deployment can practically enumerate trusted callers, and a proxy adds latency and a new failure point. Lowering the JVM heap or enabling -XX:+ExitOnOutOfMemoryError will not prevent the DoS but can shorten time-to-restart and contain blast radius until the patched version is rolled out.

Affected Packages

maven io.netty:netty-codec-redis fix: 4.1.135.Final, 4.2.15.Final

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in maven

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Netty is a widely embedded asynchronous network application framework for the JVM, and netty-codec-redis implements the RESP (REdis Serialization Protocol) used to talk to Redis servers. The vulnerable class io.netty.handler.codec.redis.RedisArrayAggregator reassembles streamed RedisMessage parts into ArrayRedisMessage objects, using a Deque<AggregateState> to track each level of nesting. The root cause is CWE-400 (Uncontrolled Resource Consumption): the aggregator pushes a fresh AggregateState plus a backing ArrayList for every array header it sees, but never caps the maximum nesting depth, so the attacker controls how many state objects get allocated on the heap. Affected packages per CPE are pkg:maven/io.netty:netty-codec-redis on both the 4.1.x and 4.2.x release lines.

Know when Redis gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/netty/netty) PRIMARY 7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
SUSE HIGH
Red Hat 7.5 HIGH

Primary rating from Vendor (https://github.com/netty/netty).

CVSS VectorVendor: https://github.com/netty/netty

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

DescriptionCVE.org

Summary

An attacker can cause DoS by sending a crafted Redis payload with deeply nested arrays. This forces the server to allocate a massive number of state objects and collections, leading to memory exhaustion and an OutOfMemoryError.

Details

io.netty.handler.codec.redis.RedisArrayAggregator aggregates RedisMessage parts into ArrayRedisMessage. It uses a Deque<AggregateState> to keep track of nested arrays. However, it does not limit the maximum depth of nested arrays. When an attacker sends a continuous stream of nested array headers (e.g., *1\r\n*1\r\n*1\r\n...), RedisArrayAggregator pushes a new AggregateState onto the stack and allocates a new ArrayList for each header. Because there is no depth limit, an attacker can send millions of such headers. This consumes a massive amount of heap memory for the AggregateState instances and their backing ArrayLists, eventually resulting in an OutOfMemoryError.

Impact

Denial of Service due to memory exhaustion. Any application using Netty's RedisArrayAggregator to handle untrusted Redis traffic is vulnerable.

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 76 maven packages depend on io.netty:netty-codec-redis (4 direct, 72 indirect)

Ecosystem-wide dependent count for version 4.2.0.Final.

Executive ViewAI

Why It Matters

Netty's netty-codec-redis module (versions through 4.1.134.Final and 4.2.0-4.2.14.Final) contains a remote denial of service vulnerability allowing unauthenticated attackers to exhaust JVM heap memory and crash applications. Organizations using these versions face immediate availability risk, as any service processing Redis protocol input can be rendered offline through specially crafted payloads. With no vendor patch currently available, interim mitigations must be deployed immediately to prevent production disruptions.

Business Impact: High
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: (1) Implement connection rate limiting and maximum depth validation in Redis protocol handlers to reject deeply nested arrays; (2) Restrict network access to services using affected Netty versions to trusted sources only via firewall rules or network segmentation; (3) Configure JVM heap size limits and enable memory exhaustion monitoring with automated alerting; (4) Deploy network-level DoS protection (rate limiting, connection limits); (5) Monitor application logs and metrics for OutOfMemoryError events or repeated malformed Redis protocol patterns that may indicate exploitation attempts.

Threat Intelligence Overview

EPSS Score
0.0%
Top 88% exploitable
Threat Intel
1
1 sources
Data Quality
7 sources
Confidence: High
NVD CVE.org EPSS Vulnrichment GHSA Vendor GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact
High
Technical Impact
Partial

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

Affected Products (CPE)CVE.org

pkg:maven/io.netty:netty-codec-redis
pkg:maven/io.netty:netty-codec-redis

More in Redis

View all
CVE-2026-48172 CRITICAL POC
10.0 May 21

Privilege escalation to root in the LiteSpeed User-End cPanel Plugin (versions 2.3 through before 2.4.5) lets attackers

CVE-2025-49844 CRITICAL POC
9.9 Oct 03

UAF in Redis 8.2.1 via crafted Lua scripts by authenticated users. EPSS 12.4%. Patch available.

CVE-2022-0543 CRITICAL POC
10.0 Feb 18

It was discovered, that redis, a persistent key-value database, due to a packaging issue, is prone to a (Debian-specific

CVE-2018-11218 CRITICAL POC
9.8 Jun 17

Memory Corruption was discovered in the cmsgpack library in the Lua subsystem in Redis before 3.2.12, 4.x before 4.0.10,

CVE-2025-46817 HIGH POC
7.0 Oct 03

Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user

CVE-2015-4335 CRITICAL POC
10.0 Jun 09

Redis before 2.8.21 and 3.x before 3.0.2 allows remote attackers to execute arbitrary Lua bytecode via the eval command.

CVE-2016-8339 CRITICAL POC
9.8 Oct 28

A buffer overflow in Redis 3.2.x prior to 3.2.4 causes arbitrary code execution when a crafted command is sent. Rated cr

CVE-2026-77602 CRITICAL POC
9.9 Sep 23

Authenticated remote code execution in OpenC3 COSMOS (Ruby gem 'openc3' versions 5.1.0 through 7.2.1) lets any logged-in

CVE-2026-27574 CRITICAL POC
9.9 Feb 21

Code injection in OneUptime monitoring via custom JS monitor using vm module. PoC and patch available.

CVE-2026-84372 CRITICAL POC
9.8 Sep 01

RESP protocol command injection in Predis, the popular PHP client for Redis and Valkey, affects versions 3.0.0-RC1 throu

CVE-2021-31649 CRITICAL POC
9.8 Jun 24

In applications using jfinal 4.9.08 and below, there is a deserialization vulnerability when using redis,may be vulnerab

CVE-2020-11981 CRITICAL POC
9.8 Jul 17

An issue was found in Apache Airflow versions 1.10.10 and below. Rated critical severity (CVSS 9.8), this vulnerability

Vendor StatusVendor

SUSE

Severity: Important
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise High Performance Computing 15 SP4-ESPOS Affected
SUSE Linux Enterprise High Performance Computing 15 SP4-LTSS Affected
SUSE Linux Enterprise High Performance Computing 15 SP5-ESPOS Affected
SUSE Linux Enterprise High Performance Computing 15 SP5-LTSS Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy