RabbitMQ Java Client CVE-2026-63337

Exploitation requires the attacker to control or intercept the system.describe response returned to a JsonRpcClient during its initialization phase. Two concrete paths satisfy this: (1) the attacker operates a service registered on the same RabbitMQ broker and exchange as the victim - plausible in multi-tenant or shared-infrastructure deployments; or (2) the attacker performs a man-in-the-middle attack on the network path between the client and broker, which requires either absence of TLS or failure to validate the broker's certificate. The victim application must specifically use com.rabbitmq.tools.jsonrpc.JsonRpcClient - the vulnerability does not affect applications using only the core AMQP Channel/Connection API. The attacker cannot introduce new classes; they can only trigger static initializers of classes already present on the victim's classpath, meaning gadget availability is an implicit precondition. The CVSS 4.0 PR:L metric indicates some level of broker access privilege is assumed for the attacker. Exploitation is limited to JVM-based applications running amqp-client versions prior to 5.33.0 with the JSON-RPC feature in active use.

The CVSS 4.0 score of 7.5 (AV:N/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L) reflects serious CIA impact on the client process moderated by specific attack requirements (AT:P) and the need for low-privilege broker access (PR:L). The AT:P condition is the decisive real-world gating factor: exploitation is confined to attackers who either share a RabbitMQ broker with the victim or can intercept unencrypted AMQP traffic, neither of which is trivially achieved in TLS-protected, well-segmented deployments. The technique itself - arbitrary Class.forName() with static initializer execution - is conceptually mature in the Java security community and does not require novel exploit development, increasing concern for motivated attackers in susceptible environments. The absence of CISA KEV listing and public POC code suggests exploitation remains opportunistic or unreported rather than widespread. The vulnerability is scoped to applications specifically using JsonRpcClient, not all RabbitMQ Java client users, which materially reduces the exposed population. Priority should be highest for deployments using shared or multi-tenant brokers without TLS mutual authentication.

An attacker with co-tenant access on a shared RabbitMQ broker deploys a malicious JSON-RPC service on the same exchange targeted by the victim application. When the victim's JsonRpcClient initializes and issues its system.describe call, the attacker's service responds with a crafted javaReturnType value naming a class already on the victim JVM's classpath that contains a dangerous static initializer - for example, a class that opens an outbound connection, executes a subprocess, or leaks credentials upon load. The victim JVM immediately executes that static initializer via Class.forName(), achieving attacker-directed code execution within the client process without any additional steps.