Loading story…
RabbitMQ has patched two vulnerabilities that could expose sensitive data and undermine tenant isolation in enterprise deployments. The most serious flaw, tracked as CVE-2026-57219 and reported by Miggo, allows an unauthenticated attacker to retrieve OAuth 2 configuration details, including a confidential client secret, from the obsolete /api/auth management endpoint. In deployments that use the management interface with OAuth-based identity provider authentication, an attacker could use the leaked secret to impersonate the broker, obtain an administrator token, and gain access to users, messages, queues, exchanges, and broker settings.
A second flaw, CVE-2026-57221, allows authenticated users without proper permissions to infer the existence of other tenants’ queues and exchanges and view related metadata and statistics, creating cross-tenant information leakage. The issues affect versions dating back to RabbitMQ 3.13.0 and have been fixed in 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15. Organizations are being urged to patch quickly, restrict or remove internet exposure of the management interface, apply segmentation or other configuration mitigations if patching is delayed, and rotate OAuth client secrets because software updates alone do not invalidate secrets that may already have been exposed.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
Two RabbitMQ flaws were present since 2024, including an OAuth secret disclosure issue that could enable broker takeover and an authorization flaw that exposed queue and exchange metadata to unauthorized authenticated users.
RabbitMQ fixed the vulnerabilities in versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15. The updates address the high-severity broker takeover risk from leaked OAuth client secrets and the medium-severity cross-tenant information leakage issue.
Miggo reported CVE-2026-57219, which exposes a confidential OAuth client secret through a management endpoint, and CVE-2026-57221, which allows authenticated users to enumerate queues and exchanges and read related statistics or metadata.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
6 references tracked. Mallory keeps watching after this page renders.
cysecurity.news
Open sourcecsirt.sk
Open sourcethehackernews.com
Open sourcescworld.com
Open sourcesecurityweek.com
Open sourcemiggo.io
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
RabbitMQ fixed a high-severity information disclosure vulnerability, **CVE-2026-57219**, that could let unauthenticated attackers retrieve OAuth 2 client secrets through the obsolete management API endpoint `GET /api/auth`. The issue affects deployments with the management plugin enabled and `management.oauth_client_secret` configured in certain less common OAuth 2 setups. Affected versions are `>= 3.13.0 and < 3.13.15`, `>= 4.0.0 and < 4.0.21`, `>= 4.1.0 and < 4.1.11`, and `>= 4.2.0 and < 4.2.6`; the flaw is rated **CVSS 4.0 8.7** and is classified under **CWE-200**. The vendor addressed the exposure in RabbitMQ `3.13.15`, `4.0.20`, `4.1.11`, and `4.2.6`. RabbitMQ `4.2.6` was released as a maintenance update with broader security-relevant hardening, including improved permission enforcement, access control, API behavior, WebSocket safety limits, login timeout handling, origin validation, and protections against excessive CPU and memory consumption from malformed inputs. The release also removed the deprecated unused API endpoint tied to the disclosure risk and reduced exposure of sensitive connection URI data in shovel status output, with users advised to upgrade and verify supported Erlang versions before deployment.
Jul 11, 2026
German authorities issued advisories for **Apache ActiveMQ Artemis** and **Apache ActiveMQ Classic** components after disclosing vulnerabilities that affect the broker, client, and web interfaces. One advisory warns that a flaw in **Apache ActiveMQ Artemis** can allow attackers to **bypass security measures**, raising the risk of unauthorized access or actions within affected messaging environments. A separate advisory reports **multiple vulnerabilities** in **Apache ActiveMQ** across the **Client, Broker, and Web** components, indicating broader exposure for organizations using the messaging platform in enterprise integrations and application back ends. The notices identify the affected Apache messaging products as requiring prompt review and remediation to reduce the risk of compromise in systems that rely on ActiveMQ services.
Jun 29, 2026
Apache disclosed two vulnerabilities affecting multiple **ActiveMQ** components, including Client, Broker, and bundled distributions. **CVE-2026-33227** is a low-severity pathname restriction flaw that lets an authenticated user manipulate a supplied `key` value to traverse the classpath in two cases: when creating a **STOMP** consumer and when browsing messages through the web console. Apache warned the issue could expose classpath resource loading and potentially be chained with another attack. The flaw affects the 5.x branch before **5.19.3** and the 6.x branch from **6.0.0** before **6.2.2**, but Apache said those initial fixes were incomplete on Windows because of path separator handling, and recommended upgrading instead to **5.19.4** or **6.2.3**. Apache also published **CVE-2026-39304**, an important denial-of-service flaw in ActiveMQ's **NIO SSL transports** caused by incorrect handling of **TLS 1.3 `KeyUpdate`** messages. A client can repeatedly trigger updates and exhaust broker memory in the SSL engine, causing out-of-memory crashes and service disruption. Apache added that related handshake handling is also broken for earlier TLS versions such as **TLS 1.2**, though those cases lead to hung connections rather than memory exhaustion. The DoS issue affects the 5.x branch before **5.19.4** and the 6.x branch from **6.0.0** before **6.2.4**; users are advised to upgrade to **5.19.5** or **6.2.4**.
Jun 29, 2026