CVE-2026-49361 Overview
CVE-2026-49361 is a denial-of-service vulnerability affecting Apache Fluss (incubating) versions 0.8.0 and 0.9.0. The flaw stems from an insecure configuration of the Netty LengthFieldBasedFrameDecoder, which uses Integer.MAX_VALUE as the maximum allowed frame length. Unauthenticated remote attackers can send crafted frame headers that cause the TabletServer and CoordinatorServer components to exhaust Java Virtual Machine (JVM) heap memory. The result is a service-level denial of service that disrupts data processing workloads. The issue is tracked under CWE-400: Uncontrolled Resource Consumption. Apache addressed the flaw in Fluss 0.9.1.
Critical Impact
Unauthenticated network attackers can crash Apache Fluss TabletServer and CoordinatorServer instances by triggering JVM heap exhaustion through malformed frame headers.
Affected Products
- Apache Fluss (incubating) 0.8.0
- Apache Fluss (incubating) 0.9.0
- Fixed in Apache Fluss 0.9.1
Discovery Timeline
- 2026-06-01 - CVE-2026-49361 published to the National Vulnerability Database (NVD)
- 2026-06-01 - Last updated in NVD database
Technical Details for CVE-2026-49361
Vulnerability Analysis
Apache Fluss uses Netty as its underlying network framework for inter-component communication between clients, TabletServer, and CoordinatorServer. Netty's LengthFieldBasedFrameDecoder parses incoming frames based on a length prefix encoded in the message header. The decoder accepts a maxFrameLength parameter that bounds how large an incoming frame can be before the decoder rejects it.
In the affected releases, Fluss instantiates this decoder with Integer.MAX_VALUE (approximately 2.1 GB) as the maximum frame length. This effectively disables the upper bound. An attacker who can reach the Fluss network ports can send a header that declares an extremely large frame size, prompting the JVM to allocate buffers accordingly. Repeated requests, or a single request with a sufficiently large declared length, exhaust available heap and force the server process into garbage collection thrashing or an OutOfMemoryError.
Root Cause
The root cause is improper input validation on a network-controlled length field, classified under CWE-400. The decoder configuration trusts the attacker-supplied length prefix and allocates memory without enforcing a reasonable ceiling tied to the legitimate protocol payload size.
Attack Vector
Exploitation requires only network reachability to the TabletServer or CoordinatorServer listening port. No authentication or user interaction is required. An attacker crafts a TCP payload that begins with a length field encoding a value close to Integer.MAX_VALUE. When Netty attempts to buffer the declared payload, the JVM heap is exhausted and the affected Fluss process becomes unresponsive or terminates.
No public proof-of-concept exploit is currently listed for CVE-2026-49361. Technical details are described in the Apache mailing list disclosure and the OpenWall OSS Security update.
Detection Methods for CVE-2026-49361
Indicators of Compromise
- OutOfMemoryError: Java heap space entries in TabletServer or CoordinatorServer logs without corresponding legitimate workload growth.
- Sudden JVM garbage collection saturation or process termination on Fluss nodes correlated with inbound connections from untrusted sources.
- Unusually large declared frame lengths observed in packet captures targeting Fluss listener ports.
Detection Strategies
- Monitor Fluss server logs for repeated Netty decoding errors, heap allocation failures, and process restarts.
- Inspect network telemetry for inbound TCP sessions to Fluss ports that transmit a small number of bytes but declare very large length fields.
- Correlate JVM heap metrics with connection-rate spikes from unauthenticated peers to identify resource-exhaustion attempts.
Monitoring Recommendations
- Export JVM memory and garbage collection metrics from Fluss processes to a centralized observability platform and alert on sustained heap saturation.
- Track connection counts, byte rates, and source IP diversity on TabletServer and CoordinatorServer ports to baseline normal traffic and flag anomalies.
- Enable verbose Netty logging in non-production environments to surface decoder rejections that may indicate probing.
How to Mitigate CVE-2026-49361
Immediate Actions Required
- Upgrade all Apache Fluss (incubating) deployments running 0.8.0 or 0.9.0 to version 0.9.1.
- Restrict network access to TabletServer and CoordinatorServer ports so only trusted application tiers can reach them.
- Review JVM heap sizing and configure heap dump on OutOfMemoryError to preserve forensic evidence during incidents.
Patch Information
Apache Fluss 0.9.1 fixes CVE-2026-49361 by configuring the Netty LengthFieldBasedFrameDecoder with a bounded maximum frame length appropriate for the protocol. Upgrade instructions and release notes are linked from the Apache mailing list announcement.
Workarounds
- Place Fluss network endpoints behind a firewall or service mesh that enforces strict allowlists for client source addresses.
- Apply network-level rate limiting and connection caps on Fluss listener ports to reduce the impact of resource-exhaustion attempts.
- Isolate Fluss clusters on dedicated network segments where untrusted traffic cannot reach TabletServer or CoordinatorServer directly.
# Example: restrict Fluss server ports to trusted CIDR ranges using iptables
# Replace 10.0.0.0/24 with your trusted client subnet and 9123 with your Fluss port
iptables -A INPUT -p tcp --dport 9123 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 9123 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
