CVE-2026-57212 in Server
Summary
by MITRE • 07/10/2026
RabbitMQ is a messaging and streaming broker. Prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the rabbitmq_management HTTP API accepts oversized valid JSON bodies on with_decode and direct_request paths because read_complete_body checks the accumulated size before the final chunk but not the final combined size. This issue is fixed in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/10/2026
The vulnerability in RabbitMQ affects versions prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5 where the rabbitmq_management HTTP API exhibits improper handling of JSON payload sizes during specific request processing paths. This flaw exists within the management interface's handling of requests that utilize the with_decode and direct_request endpoints, creating a potential vector for resource exhaustion attacks.
The technical implementation issue stems from the read_complete_body function which performs size validation checks at intermediate stages but fails to verify the final combined size of all received chunks. This creates a scenario where an attacker can submit multiple smaller JSON chunks that individually pass size limits but collectively exceed the intended maximum payload size when aggregated. The vulnerability is classified as a memory exhaustion issue under CWE-400, specifically related to insufficient resource pool management and improper input validation.
This vulnerability has significant operational impact as it allows malicious actors to consume excessive system resources through carefully crafted requests. The attack vector involves sending multiple JSON chunks that bypass individual size checks but result in oversized final payloads, potentially leading to denial of service conditions, system instability, or memory exhaustion across the RabbitMQ server. The management interface typically handles administrative operations and monitoring functions, making this a critical entry point for resource exhaustion attacks.
The fix implemented in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5 addresses the core issue by ensuring proper validation of the complete combined payload size before processing. This remediation aligns with ATT&CK technique T1499.004 for resource exhaustion attacks and follows security best practices outlined in OWASP Top Ten A05:2021. Organizations should prioritize upgrading to these fixed versions immediately, as the vulnerability can be exploited without authentication and provides a straightforward path to system resource exhaustion.
The broader implications extend beyond simple denial of service as this vulnerability could enable attackers to consume all available memory or CPU resources, potentially causing cascading failures in systems that rely on RabbitMQ for message queuing operations. System administrators should also implement monitoring for unusual API request patterns and consider implementing additional rate limiting or payload size restrictions at the network level until full upgrades are completed. This vulnerability demonstrates the importance of comprehensive input validation across all stages of data processing rather than relying solely on intermediate checks.
Security teams should conduct thorough assessments of their RabbitMQ deployments to ensure compliance with the patched versions, particularly in environments where the management interface is exposed to untrusted networks or users. The vulnerability's exploitation requires minimal technical skill and can be automated, making it a high-priority target for defensive measures. Organizations maintaining legacy systems should consider implementing compensating controls such as API gateway restrictions or proxy-level payload filtering until complete version upgrades are achieved.