CVE-2026-77403 in amqp091-go
Summary
by MITRE • 09/16/2026
RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, Connection.openTune in connection.go accepts a server-advertised FrameMax below the AMQP frameMinSize value of 4096 bytes because the connection negotiation loop does not enforce the protocol minimum. A malicious or compromised AMQP broker can therefore advertise an extremely small FrameMax, causing later client publications to be fragmented into excessive numbers of frames and write operations. This can consume CPU and stall the client or its host. This issue is fixed in version 1.13.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The RabbitMQ amqp091-go library serves as a widely adopted Go implementation for interacting with AMQP brokers, facilitating message queue communications across numerous enterprise applications. A critical vulnerability exists within the connection negotiation phase of this client prior to version 1.13.0, specifically in the logic governing how initial protocol parameters are processed upon establishing a link with an AMQP server. The Advanced Message Queuing Protocol specification defines a minimum frame size, known as FrameMinSize, which is set at 4096 bytes. This standard ensures that frames exchanged between clients and brokers remain within manageable limits to prevent resource exhaustion and ensure consistent processing behavior across different implementations. However, the affected versions of amqp091-go fail to enforce this lower bound during the connection open tune negotiation sequence. Instead of rejecting or adjusting a server-advertised FrameMax value that falls below 4096 bytes, the client accepts it as valid, thereby violating the protocol specification and introducing a significant operational risk.
This technical flaw allows for a denial-of-service attack vector where a malicious or compromised AMQP broker can exploit the client's lack of validation by advertising an extremely small FrameMax value during the handshake process. When such a low threshold is accepted, any subsequent message publication from the Go application must be fragmented into a disproportionately large number of smaller frames to fit within the restricted size limit. This fragmentation triggers excessive write operations and increases CPU utilization on both the client side and potentially the broker side as it processes these numerous tiny packets rather than larger, more efficient blocks of data. The resulting computational overhead can lead to severe performance degradation, causing the application thread or even the entire host system to stall due to resource exhaustion. This scenario effectively creates a remote denial-of-service condition that does not require authentication if the connection is established on an open channel or through other means of broker compromise.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the client fails to properly validate input parameters received from the server during protocol negotiation. It also relates to CWE-755 Improper Handling of Unusual Conditions, specifically regarding the failure to handle edge cases in protocol compliance checks. In terms of offensive security frameworks, this flaw supports techniques associated with resource exhaustion attacks under MITRE ATT&CK ID T1496, where an attacker uses limited resources to cause a denial of service against targeted systems. The attack relies on manipulating network-level parameters to force the victim into inefficient processing states rather than exploiting code execution flaws directly.
To mitigate this risk, organizations utilizing RabbitMQ amqp091-go must upgrade immediately to version 1.13.0 or later, where the connection negotiation loop has been patched to enforce the AMQP frameMinSize constraint strictly. During the transition period, if upgrading is not immediately feasible, administrators should implement network-level controls such as firewalls or intrusion prevention systems that inspect and restrict traffic from untrusted brokers. Additionally, application code can be modified to include manual validation of connection parameters post-negotiation, ensuring that any FrameMax value below 4096 bytes results in an immediate termination of the connection rather than proceeding with communication. Regular auditing of broker configurations and client library versions is essential to maintain resilience against protocol-level abuse vectors that target implementation inconsistencies.