Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2024-23321

CVE-2024-23321: Apache RocketMQ Information Disclosure

CVE-2024-23321 is an information disclosure vulnerability in Apache RocketMQ that allows attackers to expose administrator credentials. This article covers the technical details, affected versions, impact, and mitigation.

Updated:

CVE-2024-23321 Overview

CVE-2024-23321 is an information disclosure vulnerability in Apache RocketMQ versions 5.2.0 and below. The flaw allows an attacker with regular user privileges, or one whose IP is on the whitelist, to retrieve the administrator's account and password through specific broker interfaces. Successful exploitation grants full administrative control over the RocketMQ cluster, provided the attacker can reach the broker IP addresses. The issue persists even when RocketMQ authentication and authorization are enabled, undermining the assumed security posture of ACL-protected deployments. The vulnerability is tracked under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.

Critical Impact

Low-privileged users or whitelisted IPs can extract administrator credentials, resulting in complete takeover of the RocketMQ messaging infrastructure.

Affected Products

  • Apache RocketMQ versions 5.2.0 and below
  • Deployments using the original RocketMQ ACL (ACL 1.0)
  • RocketMQ broker instances exposed on trusted networks or IP allow lists

Discovery Timeline

Technical Details for CVE-2024-23321

Vulnerability Analysis

Apache RocketMQ is a distributed messaging and streaming platform used to broker high-throughput event data. In versions 5.2.0 and earlier, several administrative interfaces return sensitive configuration information without validating whether the requesting principal has administrative authority. The interfaces respond with data that includes the administrator's account name and password when queried by an authenticated regular user or from an IP present in the broker's whitelist. This behavior undermines the least-privilege model that RocketMQ ACL 1.0 was intended to enforce.

Because the leaked credentials belong to the administrator role, an attacker escalates from a limited principal to full control over broker configuration, topic management, and message flow. The current EPSS probability for exploitation is approximately 0.89%.

Root Cause

The root cause is improper access control on administrative RPC endpoints exposed by the broker. Authorization checks either omit role-based validation or rely solely on network-level allow lists. As a result, the response payloads include configuration fields containing administrator credentials that should never be returned to non-administrative callers. This is a classic information exposure defect [CWE-200] combined with broken access control on internal management interfaces.

Attack Vector

Exploitation requires network reachability to a broker IP and either valid low-privilege credentials or membership in the broker IP whitelist. The attacker issues a request to a vulnerable administrative interface and parses the returned configuration payload for the administrator username and password. With those credentials, the attacker reconnects as an administrator and gains authority to create, modify, or delete topics, redirect message flows, exfiltrate queued messages, or disrupt broker availability. No user interaction is required, and the attack complexity is low.

No verified public exploit code is available. Refer to the Apache Security advisory for authoritative technical details.

Detection Methods for CVE-2024-23321

Indicators of Compromise

  • Unexpected administrative operations on RocketMQ brokers originating from accounts that historically held only producer or consumer roles.
  • Broker log entries showing configuration queries from IPs on the whitelist immediately followed by administrator authentication events.
  • New topic creations, ACL rule modifications, or subscription group changes that do not correlate with change-management records.
  • Anomalous outbound traffic from broker hosts indicating message queue exfiltration.

Detection Strategies

  • Enable verbose audit logging on RocketMQ brokers and forward the logs to a centralized analytics platform for correlation.
  • Alert on any administrator login that follows a configuration-read request from a non-administrator principal within a short time window.
  • Baseline normal per-user API call patterns and flag deviations, particularly access to management or configuration endpoints by producer or consumer accounts.
  • Monitor for authentication events originating from whitelisted IPs that were not previously observed performing management actions.

Monitoring Recommendations

  • Ingest RocketMQ broker and NameServer logs into a SIEM and retain them for at least 90 days.
  • Track credential-use patterns for the RocketMQ administrator account and alert on logins from new source IPs or at unusual times.
  • Instrument network monitoring at the broker perimeter to detect access from hosts outside documented producer and consumer subnets.

How to Mitigate CVE-2024-23321

Immediate Actions Required

  • Upgrade all Apache RocketMQ deployments to version 5.3.0 or later, which removes the credential exposure from management interfaces.
  • Migrate from RocketMQ ACL 1.0 to RocketMQ ACL 2.0 as part of the upgrade to enforce stronger role-based authorization.
  • Rotate the RocketMQ administrator account name and password after upgrading, assuming the prior credentials are compromised.
  • Audit broker IP whitelists and remove any entries that are not strictly required for operations.

Patch Information

Apache addressed the flaw in RocketMQ 5.3.0. The fix restricts sensitive fields from being returned by administrative interfaces to non-administrator callers and aligns the authorization model with ACL 2.0. Refer to the Apache announcement thread for release notes and upgrade guidance.

Workarounds

  • Restrict broker network exposure using firewalls or security groups so that only trusted producer and consumer hosts can reach broker ports.
  • Remove low-privilege accounts that are not strictly required, and enforce unique credentials per application.
  • Segment the RocketMQ management plane onto a dedicated network reachable only from administrative jump hosts.
  • Enforce mutual TLS between clients and brokers to raise the bar for network-adjacent attackers.
bash
# Verify RocketMQ broker version and plan upgrade to 5.3.0+
sh mqbroker -v

# Example: enable ACL 2.0 in broker.conf after upgrading to 5.3.0
aclEnable=true
authenticationEnabled=true
authorizationEnabled=true

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.