Amqp091 Go
Monthly
Denial of service in the RabbitMQ amqp091-go Go AMQP 0.9.1 client affects all releases prior to 1.13.0: the library's frame-dispatch path synchronously pushes publisher confirms, flow-control events, consumer cancellations, returned messages and connection-block notifications into application-registered listener channels, so an unbuffered, undersized or not-promptly-drained listener channel permanently blocks the connection's sole reader goroutine. Once that goroutine stalls, the client stops processing incoming frames, acknowledgments, deliveries and heartbeats, which leads to connection stalls, missed heartbeats, deadlocks and eventual broker-initiated disconnection; exploitation requires a broker-driven burst of the corresponding events against an application that registered an affected listener, rather than any attacker-supplied payload. Unauthenticated remote triggering is possible per the published PR:N vector, but only applications built on versions below 1.13.0 that back a notification listener with a small or undrained channel are exposed, and no public exploit code has been identified at time of analysis. The issue is fixed in v1.13.0, where each notification send is bounded by a 5-second timeout and slow deliveries are dropped instead of blocking the reader.
Parsing desynchronization in the RabbitMQ amqp091-go AMQP 0.9.1 client library before 1.13.0 lets a malicious or compromised broker - or anyone positioned to modify broker traffic - send a table field carrying a longstr whose declared length exceeds 0x7FFFFFFF; the client accepts it silently instead of returning ErrSyntax, leaves the declared bytes unread, and then parses every following field and frame from the wrong offset. The independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H, i.e. unauthenticated remote input that can corrupt parsing integrity and disrupt connection availability, but with high attack complexity because the victim application must first connect to an attacker-controlled or subverted broker (or be subject to a man-in-the-middle on that connection), and with no confidentiality impact since the Go library is memory-safe and this is a logic-level desynchronization rather than memory corruption. Vendor-released patch v1.13.0 fixes the defect; no public exploit code identified at time of analysis, and the vendor's CVSS 4.0 score of 9.5 with full High subsequent-system impact overstates real-world risk.
Denial of service in the official RabbitMQ Go client library amqp091-go (versions prior to 1.13.0): a malicious, compromised, or impersonated AMQP 0.9.1 broker can crash any application that connects to it. By encoding a byte-array field length as 0xFFFFFFFF (decoded into a signed int32 as -1) inside the connection.start server-properties table or a message header field table, the broker drives readField() to call make() with a negative size, producing a 'len out of range' runtime panic that escapes the reader goroutine and terminates the client process. Attackers must sit on the broker side of the connection - a trusted-broker deployment is largely unaffected - and the outcome is availability loss only, with no code execution or data disclosure. No public exploit code or confirmed active exploitation has been identified at time of analysis; vendor-released patch 1.13.0 is available.
RabbitMQ's amqp091-go Go client library, in all versions before 1.13.0, builds TLS configuration from amqps:// URIs without setting a minimum protocol version, so builds that use a Go runtime permitting TLS 1.0 or 1.1 can negotiate an obsolete protocol. An active man-in-the-middle positioned on the network path could then force a downgrade and weaken the confidentiality and integrity of AMQP traffic, including credentials, though the independently assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) shows this requires a high degree of attacker positioning plus the legacy-toolchain precondition, and the published 9.4 CVSS 4.0 score overstates real-world exposure for modern deployments. The fix is a two-line MinVersion change shipped in version 1.13.0; no public exploit identified at time of analysis.
Improper output encoding in the RabbitMQ amqp091-go Go client before 1.13.0 lets an attacker who can influence a TLS asset path value (CertFile, KeyFile, CACertFile, or ServerName) inject or overwrite AMQPS connection options whenever an application serializes a URI with URI.String() and later reparses it with ParseURI(). Because the values are concatenated into the query string without url.Values encoding, embedded '&' and '=' delimiters split into extra parameters that can redirect the client to different - but still pre-existing - local certificate, key, or CA files, corrupting connection configuration. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; the vendor fix is version 1.13.0, and the practical risk is well below the headline 8.7 CVSS 4.0 score because exploitation needs a specific serialize-then-reparse code path plus attacker-influenceable path data.
Memory-exhaustion denial of service in the official RabbitMQ Go AMQP 0.9.1 client library (amqp091-go) prior to 1.13.0 lets a malicious or compromised broker kill client processes: when a content header frame arrives, the client preallocates the message body buffer using the broker-declared 64-bit body size without capping that hint to the negotiated Connection.Config.FrameSize, so an extreme declared size drives a correspondingly huge Go heap allocation before any body bytes are received, exhausting memory and terminating the process. The exploitation model is broker-attacks-its-clients rather than exploitation by an arbitrary network attacker (CVSS 4.0 8.9 with AT:P, and the assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H), meaning the victim application must connect to a broker that is hostile, subverted, or on a path an attacker can tamper with; no client credentials or unusual configuration are needed, and a FrameSize of 0 ("unlimited") removes the cap entirely even after patching. There is no CISA KEV entry and no public exploit identified at time of analysis, but the upstream fix commit, test case, and 1.13.0 release are all public.
Memory exhaustion in the RabbitMQ amqp091-go Go AMQP 0.9.1 client library prior to 1.13.0 lets unauthenticated remote attackers who can influence an application's Qos settings make the client request an absurdly large prefetch limit and then buffer enough broker-delivered messages to exhaust host memory. Channel.Qos performs no bounds validation, so a negative prefetchCount or prefetchSize is cast straight into the uint16/uint32 fields of the basic.qos method and wraps to 65535 or 4294967295 instead of being rejected. The vendor CVSS 4.0 score of 8.2 (High) is availability-only and materially gated by the attack requirement that the embedding application accept untrusted Qos values; default usage with hard-coded, non-negative values is unaffected, and no public exploit code was identified at time of analysis. The defect is repaired in 1.13.0 via a new validateQos check.
Denial of service in the RabbitMQ amqp091-go Go client for AMQP 0.9.1 (versions prior to 1.13.0) allows a malicious or compromised broker to advertise a FrameMax below the protocol's 4096-byte frameMinSize during connection negotiation, causing the client to fragment subsequent publications into an excessive number of frames and write operations, consuming CPU and stalling the client process or its host. The assessed vector carries PR:N, so no authentication is required on the client side, but exploitation is bounded by a trust-boundary prerequisite: the victim Go application must connect to a broker that the attacker controls or has compromised, and TLS with proper broker authentication prevents an unrelated network attacker from impersonating the broker. Impact is availability-only with no loss of confidentiality or integrity, and no public exploit code has been identified at time of analysis.
Credential disclosure in the RabbitMQ amqp091-go Go client library before 1.13.0 leaves PLAIN and AMQPLAIN SASL passwords sitting in the exported, plaintext Password fields of Connection.Config.SASL for the entire lifetime of an authenticated connection, because Connection.openComplete never clears them after the handshake. Any in-process code that walks the Connection object - reflective or structured loggers, APM agents, debugger utilities, or panic/crash handlers that serialize state - can pull those credentials into logs or dumps that an attacker with local access to the host, logs, or crash artifacts can then read. Exploitation is local and prerequisites-dependent (it requires connecting with PlainAuth/AMQPlainAuth and the presence of config-traversing tooling, plus read access to the resulting output); no public exploit code has been identified at time of analysis and the issue is fixed in v1.13.0.
Silent AMQP 0.9.1 metadata corruption in the RabbitMQ amqp091-go Go client library prior to 1.13.0 lets an application that assigns an oversized value to any shortstr message property (CorrelationId, ReplyTo, MessageId, Expiration, UserId, AppId, ContentType, ContentEncoding, or Type) serialize a wrapped uint8 length prefix alongside only a truncated value while reporting no error. The result is broken request/reply correlation, routing, tracing, and downstream message processing rather than code execution or disclosure; the flaw requires attacker-influenced data to reach a shortstr property, so applications that only set short, trusted, fixed-length values are not practically exposed. No public exploit code or confirmed active exploitation was identified at time of analysis, and version 1.13.0 contains the vendor fix (CVSS 4.0 base 9.1; our independent assessment scores this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L, reflecting no privileges required but a high attack-complexity precondition).
Unbounded memory allocation in amqp091-go (RabbitMQ's official Go AMQP 0.9.1 client) before v1.13.0 allows a malicious or compromised AMQP broker to force connected clients to allocate and process content body frames exceeding the negotiated frame_max limit, bypassing protocol framing constraints and causing application-layer denial of service. The root cause - confirmed via PR diff - is the client's blind acceptance of broker-advertised frame sizes during the TUNE handshake without enforcing the AMQP specification's minimum frame floor. No public exploit or CISA KEV listing exists at time of analysis; a vendor-released patch is available in v1.13.0.
Denial of service in the RabbitMQ amqp091-go AMQP 0.9.1 client library (1.13.0 through pre-1.14.0) lets a malicious or compromised AMQP peer force the client to allocate attacker-chosen amounts of memory during the handshake. The peer only needs to send a short body-frame header with a large declared payload length: because the pre-negotiation maxFrameSize value is stored as zero - a state indistinguishable from 'unlimited' - the earlier frame-size mitigation is bypassed and ReadFrame allocates based on the declared length before the payload arrives, before connection.tune completes, and before authentication, even when Config.FrameSize is set to the protocol minimum. Overall a MEDIUM real-world risk with unauthenticated remote triggering, but exploitation is limited to clients that connect via the public Open function to an attacker-controlled, compromised, or MITM'd broker, and the impact is confined to client availability (memory pressure, OOM termination, process loss) with no data exposure or code execution; no public exploit identified at time of analysis.
Denial of service in the RabbitMQ amqp091-go Go AMQP 0.9.1 client affects all releases prior to 1.13.0: the library's frame-dispatch path synchronously pushes publisher confirms, flow-control events, consumer cancellations, returned messages and connection-block notifications into application-registered listener channels, so an unbuffered, undersized or not-promptly-drained listener channel permanently blocks the connection's sole reader goroutine. Once that goroutine stalls, the client stops processing incoming frames, acknowledgments, deliveries and heartbeats, which leads to connection stalls, missed heartbeats, deadlocks and eventual broker-initiated disconnection; exploitation requires a broker-driven burst of the corresponding events against an application that registered an affected listener, rather than any attacker-supplied payload. Unauthenticated remote triggering is possible per the published PR:N vector, but only applications built on versions below 1.13.0 that back a notification listener with a small or undrained channel are exposed, and no public exploit code has been identified at time of analysis. The issue is fixed in v1.13.0, where each notification send is bounded by a 5-second timeout and slow deliveries are dropped instead of blocking the reader.
Parsing desynchronization in the RabbitMQ amqp091-go AMQP 0.9.1 client library before 1.13.0 lets a malicious or compromised broker - or anyone positioned to modify broker traffic - send a table field carrying a longstr whose declared length exceeds 0x7FFFFFFF; the client accepts it silently instead of returning ErrSyntax, leaves the declared bytes unread, and then parses every following field and frame from the wrong offset. The independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H, i.e. unauthenticated remote input that can corrupt parsing integrity and disrupt connection availability, but with high attack complexity because the victim application must first connect to an attacker-controlled or subverted broker (or be subject to a man-in-the-middle on that connection), and with no confidentiality impact since the Go library is memory-safe and this is a logic-level desynchronization rather than memory corruption. Vendor-released patch v1.13.0 fixes the defect; no public exploit code identified at time of analysis, and the vendor's CVSS 4.0 score of 9.5 with full High subsequent-system impact overstates real-world risk.
Denial of service in the official RabbitMQ Go client library amqp091-go (versions prior to 1.13.0): a malicious, compromised, or impersonated AMQP 0.9.1 broker can crash any application that connects to it. By encoding a byte-array field length as 0xFFFFFFFF (decoded into a signed int32 as -1) inside the connection.start server-properties table or a message header field table, the broker drives readField() to call make() with a negative size, producing a 'len out of range' runtime panic that escapes the reader goroutine and terminates the client process. Attackers must sit on the broker side of the connection - a trusted-broker deployment is largely unaffected - and the outcome is availability loss only, with no code execution or data disclosure. No public exploit code or confirmed active exploitation has been identified at time of analysis; vendor-released patch 1.13.0 is available.
RabbitMQ's amqp091-go Go client library, in all versions before 1.13.0, builds TLS configuration from amqps:// URIs without setting a minimum protocol version, so builds that use a Go runtime permitting TLS 1.0 or 1.1 can negotiate an obsolete protocol. An active man-in-the-middle positioned on the network path could then force a downgrade and weaken the confidentiality and integrity of AMQP traffic, including credentials, though the independently assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) shows this requires a high degree of attacker positioning plus the legacy-toolchain precondition, and the published 9.4 CVSS 4.0 score overstates real-world exposure for modern deployments. The fix is a two-line MinVersion change shipped in version 1.13.0; no public exploit identified at time of analysis.
Improper output encoding in the RabbitMQ amqp091-go Go client before 1.13.0 lets an attacker who can influence a TLS asset path value (CertFile, KeyFile, CACertFile, or ServerName) inject or overwrite AMQPS connection options whenever an application serializes a URI with URI.String() and later reparses it with ParseURI(). Because the values are concatenated into the query string without url.Values encoding, embedded '&' and '=' delimiters split into extra parameters that can redirect the client to different - but still pre-existing - local certificate, key, or CA files, corrupting connection configuration. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; the vendor fix is version 1.13.0, and the practical risk is well below the headline 8.7 CVSS 4.0 score because exploitation needs a specific serialize-then-reparse code path plus attacker-influenceable path data.
Memory-exhaustion denial of service in the official RabbitMQ Go AMQP 0.9.1 client library (amqp091-go) prior to 1.13.0 lets a malicious or compromised broker kill client processes: when a content header frame arrives, the client preallocates the message body buffer using the broker-declared 64-bit body size without capping that hint to the negotiated Connection.Config.FrameSize, so an extreme declared size drives a correspondingly huge Go heap allocation before any body bytes are received, exhausting memory and terminating the process. The exploitation model is broker-attacks-its-clients rather than exploitation by an arbitrary network attacker (CVSS 4.0 8.9 with AT:P, and the assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H), meaning the victim application must connect to a broker that is hostile, subverted, or on a path an attacker can tamper with; no client credentials or unusual configuration are needed, and a FrameSize of 0 ("unlimited") removes the cap entirely even after patching. There is no CISA KEV entry and no public exploit identified at time of analysis, but the upstream fix commit, test case, and 1.13.0 release are all public.
Memory exhaustion in the RabbitMQ amqp091-go Go AMQP 0.9.1 client library prior to 1.13.0 lets unauthenticated remote attackers who can influence an application's Qos settings make the client request an absurdly large prefetch limit and then buffer enough broker-delivered messages to exhaust host memory. Channel.Qos performs no bounds validation, so a negative prefetchCount or prefetchSize is cast straight into the uint16/uint32 fields of the basic.qos method and wraps to 65535 or 4294967295 instead of being rejected. The vendor CVSS 4.0 score of 8.2 (High) is availability-only and materially gated by the attack requirement that the embedding application accept untrusted Qos values; default usage with hard-coded, non-negative values is unaffected, and no public exploit code was identified at time of analysis. The defect is repaired in 1.13.0 via a new validateQos check.
Denial of service in the RabbitMQ amqp091-go Go client for AMQP 0.9.1 (versions prior to 1.13.0) allows a malicious or compromised broker to advertise a FrameMax below the protocol's 4096-byte frameMinSize during connection negotiation, causing the client to fragment subsequent publications into an excessive number of frames and write operations, consuming CPU and stalling the client process or its host. The assessed vector carries PR:N, so no authentication is required on the client side, but exploitation is bounded by a trust-boundary prerequisite: the victim Go application must connect to a broker that the attacker controls or has compromised, and TLS with proper broker authentication prevents an unrelated network attacker from impersonating the broker. Impact is availability-only with no loss of confidentiality or integrity, and no public exploit code has been identified at time of analysis.
Credential disclosure in the RabbitMQ amqp091-go Go client library before 1.13.0 leaves PLAIN and AMQPLAIN SASL passwords sitting in the exported, plaintext Password fields of Connection.Config.SASL for the entire lifetime of an authenticated connection, because Connection.openComplete never clears them after the handshake. Any in-process code that walks the Connection object - reflective or structured loggers, APM agents, debugger utilities, or panic/crash handlers that serialize state - can pull those credentials into logs or dumps that an attacker with local access to the host, logs, or crash artifacts can then read. Exploitation is local and prerequisites-dependent (it requires connecting with PlainAuth/AMQPlainAuth and the presence of config-traversing tooling, plus read access to the resulting output); no public exploit code has been identified at time of analysis and the issue is fixed in v1.13.0.
Silent AMQP 0.9.1 metadata corruption in the RabbitMQ amqp091-go Go client library prior to 1.13.0 lets an application that assigns an oversized value to any shortstr message property (CorrelationId, ReplyTo, MessageId, Expiration, UserId, AppId, ContentType, ContentEncoding, or Type) serialize a wrapped uint8 length prefix alongside only a truncated value while reporting no error. The result is broken request/reply correlation, routing, tracing, and downstream message processing rather than code execution or disclosure; the flaw requires attacker-influenced data to reach a shortstr property, so applications that only set short, trusted, fixed-length values are not practically exposed. No public exploit code or confirmed active exploitation was identified at time of analysis, and version 1.13.0 contains the vendor fix (CVSS 4.0 base 9.1; our independent assessment scores this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L, reflecting no privileges required but a high attack-complexity precondition).
Unbounded memory allocation in amqp091-go (RabbitMQ's official Go AMQP 0.9.1 client) before v1.13.0 allows a malicious or compromised AMQP broker to force connected clients to allocate and process content body frames exceeding the negotiated frame_max limit, bypassing protocol framing constraints and causing application-layer denial of service. The root cause - confirmed via PR diff - is the client's blind acceptance of broker-advertised frame sizes during the TUNE handshake without enforcing the AMQP specification's minimum frame floor. No public exploit or CISA KEV listing exists at time of analysis; a vendor-released patch is available in v1.13.0.
Denial of service in the RabbitMQ amqp091-go AMQP 0.9.1 client library (1.13.0 through pre-1.14.0) lets a malicious or compromised AMQP peer force the client to allocate attacker-chosen amounts of memory during the handshake. The peer only needs to send a short body-frame header with a large declared payload length: because the pre-negotiation maxFrameSize value is stored as zero - a state indistinguishable from 'unlimited' - the earlier frame-size mitigation is bypassed and ReadFrame allocates based on the declared length before the payload arrives, before connection.tune completes, and before authentication, even when Config.FrameSize is set to the protocol minimum. Overall a MEDIUM real-world risk with unauthenticated remote triggering, but exploitation is limited to clients that connect via the public Open function to an attacker-controlled, compromised, or MITM'd broker, and the impact is confined to client availability (memory pressure, OOM termination, process loss) with no data exposure or code execution; no public exploit identified at time of analysis.