Answer in brief
CVE-2026-61634 records a Low severity vulnerability in RabbitMQ Java client accepts broker frames larger than the negotiated AMQP frame_max. The current sources do not mark it as known exploited. The current feed maps rabbitmq/rabbitmq-java-client (generic), com.rabbitmq:amqp-client (maven), com.rabbitmq:amqp-client (maven). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-61634 records a Low severity vulnerability in RabbitMQ Java client accepts broker frames larger than the negotiated AMQP frame_max. The current sources do not mark it as known exploited. The current feed maps rabbitmq/rabbitmq-java-client (generic), com.rabbitmq:amqp-client (maven), com.rabbitmq:amqp-client (maven). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps rabbitmq/rabbitmq-java-client (generic), com.rabbitmq:amqp-client (maven), com.rabbitmq:amqp-client (maven). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| rabbitmq/rabbitmq-java-clientgeneric | < 5.33.0 | Not reported |
| com.rabbitmq:amqp-clientmaven | <5.33.0 | 5.33.0 |
| com.rabbitmq:amqp-clientmaven | >=0 <5.33.0 | 5.33.0 |
Published upstream
Aug 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 18, 2026
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.33.0, the AMQP connection tuning path records the negotiated AMQP frame_max value, but src/main/java/com/rabbitmq/client/impl/SocketFrameHandler.java and NettyFrameHandlerFactory continue to validate broker-controlled frame payload lengths against maxInboundMessageBodySize because the negotiated limit is not applied consistently through setMaxInboundFramePayloadSize. A malicious or compromised broker can send a method frame larger than the negotiated frame_max during or after connection establishment, causing the client to allocate and decode a protocol-invalid frame instead of rejecting it with MalformedFrameException. The protocol violation can disrupt the affected connection and cause client-side denial of service. This issue is fixed in version 5.33.0.
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps rabbitmq/rabbitmq-java-client (generic), com.rabbitmq:amqp-client (maven), com.rabbitmq:amqp-client (maven). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| rabbitmq/rabbitmq-java-clientgeneric | < 5.33.0 | Not reported |
| com.rabbitmq:amqp-clientmaven | <5.33.0 | 5.33.0 |
| com.rabbitmq:amqp-clientmaven | >=0 <5.33.0 | 5.33.0 |
Published upstream
Aug 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 18, 2026
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.33.0, the AMQP connection tuning path records the negotiated AMQP frame_max value, but src/main/java/com/rabbitmq/client/impl/SocketFrameHandler.java and NettyFrameHandlerFactory continue to validate broker-controlled frame payload lengths against maxInboundMessageBodySize because the negotiated limit is not applied consistently through setMaxInboundFramePayloadSize. A malicious or compromised broker can send a method frame larger than the negotiated frame_max during or after connection establishment, causing the client to allocate and decode a protocol-invalid frame instead of rejecting it with MalformedFrameException. The protocol violation can disrupt the affected connection and cause client-side denial of service. This issue is fixed in version 5.33.0.
Quoted source text, attributed separately from HOL analysis.