Rabbitmq Java Client
Monthly
Denial of service in the RabbitMQ Java client (com.rabbitmq:amqp-client / rabbitmq-java-client) prior to the fixed release allows a single small, malformed JSON-RPC message body to permanently hang or crash a JVM. The deprecated com.rabbitmq.tools.jsonrpc tooling - JsonRpcServer and JsonRpcClient - falls back to DefaultJsonRpcMapper when no mapper is supplied, and that mapper hands raw message bodies straight to JSONReader.read(), whose string and comment scanners fail to stop at CharacterIterator.DONE. An input truncated inside a quoted string drives the parser into an unending append loop that exhausts the heap with OutOfMemoryError, while an unterminated // line comment pins a thread at 100% CPU indefinitely; neither condition is recoverable per request. Publicly available exploit code exists (a proof-of-concept is included in the vendor advisory) and the CVE is tracked by CISA SSVC with Exploitation=poc and Technical Impact=partial, though EPSS probability is low at roughly 0.49% (40th percentile) and no CISA KEV listing is present. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H indicates a network-reachable, unauthenticated availability-only impact.
Memory exhaustion in the RabbitMQ Java client (all versions prior to 5.34.0) lets a rogue AMQP broker or an in-path attacker crash the JVM host application: when both the client's default ConnectionFactory.DEFAULT_FRAME_MAX and the server's Connection.Tune frame_max negotiate to 0, the library's maxInboundMessageBodySize cap is silently discarded and an oversized inbound frame is allocated without limit. Attackers cannot force this against a passive, correctly connected client - the victim must connect outbound to attacker-influenced infrastructure, or the attacker must hold a man-in-the-middle position able to rewrite the Connection.Tune frame and inject frames, which the vendor's CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) and our assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) both treat as an unauthenticated, availability-only denial of service with no code execution or data exposure. Impact is limited to terminating the client process via heap exhaustion, and there is no public exploit identified at time of analysis and no CISA KEV listing; vendor-released patch: 5.34.0.
Unvalidated Class.forName() with initialization enabled in RabbitMQ Java Client's JSON-RPC tooling allows a network-positioned attacker to trigger arbitrary static initializers in the victim JVM. Applications using com.rabbitmq:amqp-client before 5.33.0 that employ the JsonRpcClient class are exposed when an attacker can control or spoof the system.describe broker response - either as a co-tenant on a shared broker or via network interception. Successful exploitation achieves code-like effects through static initializer execution and a secondary type-confusion path via mapper.parse, with full confidentiality, integrity, and availability impact on the client process. No public exploit identified at time of analysis, and this CVE is not listed in CISA KEV.
Unbounded mutual recursion in the RabbitMQ Java client library (amqp-client <= 5.33.0) allows a malicious AMQP server or network intermediary to crash the client JVM before authentication completes. By sending approximately 580 levels of nested AMQP table structures within a single connection.start frame - well within the default 131,072-byte frame limit - an attacker triggers a StackOverflowError that kills the client's I/O processing thread, resulting in denial of service. No public exploit code has been published, but the GHSA advisory includes a precise technical breakdown and proof-of-concept payload specification, significantly lowering the bar for exploitation.
Memory exhaustion denial of service in the RabbitMQ Java client library (com.rabbitmq:amqp-client ≤ 5.33.0) allows a malicious AMQP peer to crash the client JVM by sending a LongString field with a wire-declared length near Integer.MAX_VALUE during the pre-authentication connection.start handshake. The ValueReader.readBytes() method allocates a byte array sized by the attacker-controlled wire value before validating it against actual frame data, causing a ~2 GB allocation and OutOfMemoryError that terminates the entire JVM process. No public exploit code has been identified at time of analysis, but the GHSA advisory discloses the exact vulnerable code path, the precise trigger value (0x7FFFFFFE), and the step-by-step attack scenario, making independent implementation trivial.
RabbitMQ Java Client library releases prior to 5.35.0 can leak plaintext broker credentials because ConnectionFactoryConfigurator.load() wraps AMQP URI parsing failures in IllegalArgumentException messages that contain the raw amqp://user:pass@host URI. Any application that supplies credentials inside the connection URI and then hits a setup error - malformed URI syntax or a TLS NoSuchAlgorithmException/KeyManagementException - will write those credentials into startup logs, APM dashboards, CI output, or copied stack traces, where users without broker access may read them. This is a genuine but low-urgency credential-disclosure issue rather than a widely-exploitable critical flaw: exploitation is passive and conditional, requires the attacker to already have read access to the log sink, and only affects the configurator load() path where credentials are embedded in the URI. No public exploit identified at time of analysis; the vulnerable behavior is fixed in version 5.35.0, and the CVSS 4.0 score of 5.7 (AV:L/AC:L/AT:P/PR:L, VC:H) reflects that local, low-privilege, log-reading access with specific preconditions is needed.
Malformed UTF-8 echoed back through an AMQP shortstr property can permanently disable RPC consumers built on the RabbitMQ Java client before 5.36.0, forcing the affected consumer to fail on every redelivery of a single poison message. An attacker with low-privileged broker access publishes a request whose property value (for example correlation-id) contains invalid UTF-8; ValueReader.readShortstr decodes those bytes into U+FFFD replacement characters, which re-encode to more than the 255-byte AMQP shortstr limit that ValueWriter.writeShortstr enforces, so reply publication throws an unchecked exception. In RpcServer.mainloop() and tutorial-style echo consumers that exception aborts the loop before acknowledgement, the broker requeues the message, and the consumer is stuck until the queue is purged. No public exploit identified at time of analysis; impact is confined to availability of the target consumer (reported CVSS 4.0 base 6.0; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) with no code execution, authentication bypass, or data exposure.
TLS certificate validation is completely bypassed in the RabbitMQ Java client library (`com.rabbitmq:amqp-client`) prior to version 5.33.0 when applications call `ConnectionFactory.useSslProtocol()` or `useSslProtocol(String)`, because these methods silently install `TrustEverythingTrustManager` and leave hostname verification disabled. A network-positioned attacker can present any certificate - including self-signed or null-chain - to impersonate the RabbitMQ broker and decrypt or modify all AMQP traffic, including plaintext credentials transmitted via PLAIN SASL on default port 5672. A verified proof-of-concept is publicly available in GHSA-5m9f-rphj-c435; no confirmed active exploitation (CISA KEV) has been recorded at time of analysis.
Denial of service in the RabbitMQ Java client library (com.rabbitmq:amqp-client ≤ 5.30.0) allows a malicious or compromised AMQP broker to forcibly terminate any active client connection by sending a crafted malformed frame sequence. The flaw in CommandAssembler.consumeBodyFrame subtracts a peer-controlled body-frame payload length before validating it fits within the declared body size, driving remainingBodyBytes negative and triggering an unhandled UnsupportedOperationException - a legacy stub - rather than a proper MalformedFrameException, causing AMQConnection to perform a hard connection shutdown. A PoC is referenced in the GHSA advisory; no active exploitation is confirmed in CISA KEV.
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Pivotal Spring AMQP, 1.x versions prior to 1.7.10 and 2.x versions prior to 2.0.6, expose a man-in-the-middle vulnerability due to lack of hostname validation. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Denial of service in the RabbitMQ Java client (com.rabbitmq:amqp-client / rabbitmq-java-client) prior to the fixed release allows a single small, malformed JSON-RPC message body to permanently hang or crash a JVM. The deprecated com.rabbitmq.tools.jsonrpc tooling - JsonRpcServer and JsonRpcClient - falls back to DefaultJsonRpcMapper when no mapper is supplied, and that mapper hands raw message bodies straight to JSONReader.read(), whose string and comment scanners fail to stop at CharacterIterator.DONE. An input truncated inside a quoted string drives the parser into an unending append loop that exhausts the heap with OutOfMemoryError, while an unterminated // line comment pins a thread at 100% CPU indefinitely; neither condition is recoverable per request. Publicly available exploit code exists (a proof-of-concept is included in the vendor advisory) and the CVE is tracked by CISA SSVC with Exploitation=poc and Technical Impact=partial, though EPSS probability is low at roughly 0.49% (40th percentile) and no CISA KEV listing is present. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H indicates a network-reachable, unauthenticated availability-only impact.
Memory exhaustion in the RabbitMQ Java client (all versions prior to 5.34.0) lets a rogue AMQP broker or an in-path attacker crash the JVM host application: when both the client's default ConnectionFactory.DEFAULT_FRAME_MAX and the server's Connection.Tune frame_max negotiate to 0, the library's maxInboundMessageBodySize cap is silently discarded and an oversized inbound frame is allocated without limit. Attackers cannot force this against a passive, correctly connected client - the victim must connect outbound to attacker-influenced infrastructure, or the attacker must hold a man-in-the-middle position able to rewrite the Connection.Tune frame and inject frames, which the vendor's CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) and our assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) both treat as an unauthenticated, availability-only denial of service with no code execution or data exposure. Impact is limited to terminating the client process via heap exhaustion, and there is no public exploit identified at time of analysis and no CISA KEV listing; vendor-released patch: 5.34.0.
Unvalidated Class.forName() with initialization enabled in RabbitMQ Java Client's JSON-RPC tooling allows a network-positioned attacker to trigger arbitrary static initializers in the victim JVM. Applications using com.rabbitmq:amqp-client before 5.33.0 that employ the JsonRpcClient class are exposed when an attacker can control or spoof the system.describe broker response - either as a co-tenant on a shared broker or via network interception. Successful exploitation achieves code-like effects through static initializer execution and a secondary type-confusion path via mapper.parse, with full confidentiality, integrity, and availability impact on the client process. No public exploit identified at time of analysis, and this CVE is not listed in CISA KEV.
Unbounded mutual recursion in the RabbitMQ Java client library (amqp-client <= 5.33.0) allows a malicious AMQP server or network intermediary to crash the client JVM before authentication completes. By sending approximately 580 levels of nested AMQP table structures within a single connection.start frame - well within the default 131,072-byte frame limit - an attacker triggers a StackOverflowError that kills the client's I/O processing thread, resulting in denial of service. No public exploit code has been published, but the GHSA advisory includes a precise technical breakdown and proof-of-concept payload specification, significantly lowering the bar for exploitation.
Memory exhaustion denial of service in the RabbitMQ Java client library (com.rabbitmq:amqp-client ≤ 5.33.0) allows a malicious AMQP peer to crash the client JVM by sending a LongString field with a wire-declared length near Integer.MAX_VALUE during the pre-authentication connection.start handshake. The ValueReader.readBytes() method allocates a byte array sized by the attacker-controlled wire value before validating it against actual frame data, causing a ~2 GB allocation and OutOfMemoryError that terminates the entire JVM process. No public exploit code has been identified at time of analysis, but the GHSA advisory discloses the exact vulnerable code path, the precise trigger value (0x7FFFFFFE), and the step-by-step attack scenario, making independent implementation trivial.
RabbitMQ Java Client library releases prior to 5.35.0 can leak plaintext broker credentials because ConnectionFactoryConfigurator.load() wraps AMQP URI parsing failures in IllegalArgumentException messages that contain the raw amqp://user:pass@host URI. Any application that supplies credentials inside the connection URI and then hits a setup error - malformed URI syntax or a TLS NoSuchAlgorithmException/KeyManagementException - will write those credentials into startup logs, APM dashboards, CI output, or copied stack traces, where users without broker access may read them. This is a genuine but low-urgency credential-disclosure issue rather than a widely-exploitable critical flaw: exploitation is passive and conditional, requires the attacker to already have read access to the log sink, and only affects the configurator load() path where credentials are embedded in the URI. No public exploit identified at time of analysis; the vulnerable behavior is fixed in version 5.35.0, and the CVSS 4.0 score of 5.7 (AV:L/AC:L/AT:P/PR:L, VC:H) reflects that local, low-privilege, log-reading access with specific preconditions is needed.
Malformed UTF-8 echoed back through an AMQP shortstr property can permanently disable RPC consumers built on the RabbitMQ Java client before 5.36.0, forcing the affected consumer to fail on every redelivery of a single poison message. An attacker with low-privileged broker access publishes a request whose property value (for example correlation-id) contains invalid UTF-8; ValueReader.readShortstr decodes those bytes into U+FFFD replacement characters, which re-encode to more than the 255-byte AMQP shortstr limit that ValueWriter.writeShortstr enforces, so reply publication throws an unchecked exception. In RpcServer.mainloop() and tutorial-style echo consumers that exception aborts the loop before acknowledgement, the broker requeues the message, and the consumer is stuck until the queue is purged. No public exploit identified at time of analysis; impact is confined to availability of the target consumer (reported CVSS 4.0 base 6.0; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) with no code execution, authentication bypass, or data exposure.
TLS certificate validation is completely bypassed in the RabbitMQ Java client library (`com.rabbitmq:amqp-client`) prior to version 5.33.0 when applications call `ConnectionFactory.useSslProtocol()` or `useSslProtocol(String)`, because these methods silently install `TrustEverythingTrustManager` and leave hostname verification disabled. A network-positioned attacker can present any certificate - including self-signed or null-chain - to impersonate the RabbitMQ broker and decrypt or modify all AMQP traffic, including plaintext credentials transmitted via PLAIN SASL on default port 5672. A verified proof-of-concept is publicly available in GHSA-5m9f-rphj-c435; no confirmed active exploitation (CISA KEV) has been recorded at time of analysis.
Denial of service in the RabbitMQ Java client library (com.rabbitmq:amqp-client ≤ 5.30.0) allows a malicious or compromised AMQP broker to forcibly terminate any active client connection by sending a crafted malformed frame sequence. The flaw in CommandAssembler.consumeBodyFrame subtracts a peer-controlled body-frame payload length before validating it fits within the declared body size, driving remainingBodyBytes negative and triggering an unhandled UnsupportedOperationException - a legacy stub - rather than a proper MalformedFrameException, causing AMQConnection to perform a hard connection shutdown. A PoC is referenced in the GHSA advisory; no active exploitation is confirmed in CISA KEV.
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Pivotal Spring AMQP, 1.x versions prior to 1.7.10 and 2.x versions prior to 2.0.6, expose a man-in-the-middle vulnerability due to lack of hostname validation. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.