Detecting CVE-2026-44236 Exploitation Attempts in AMQP Traffic

CVE-2026-44236 has an unusual detection profile. The exploit never touches the target host as an inbound request, so host firewalls and web-facing sensors see nothing. The attack arrives on outbound traffic from the client to a malicious or impersonated AMQP server, and it completes inside the login handshake before any message is published.

Vulnerability overview

The issue is a heap-based buffer overflow (CWE-122) in rabbitmq-c before 0.16.0, published on 17 September 2026 and fixed in 0.16.0. NVD scores it 7.1 on CVSS 3.1 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H.

Mechanism and exploitation conditions

The AMQP handshake begins with protocol-header and connection.start, then the server's connection.tune. That tune frame carries frame_max, the largest frame the peer will accept. rabbitmq-c reads the value in amqp_login_inner() in librabbitmq/amqp_socket.c and accepts a server value below its own request.
amqp_tune_connection() in librabbitmq/amqp_connection.c then uses the value as the outbound buffer size without enforcing the AMQP 4096-byte minimum. A tune frame advertising frame_max of 1 yields a one-byte buffer, and writing connection.tune-ok through amqp_frame_to_bytes() overruns it by a byte at offset 1.
Exploitation prerequisites are narrow and clear: a rabbitmq-c client below 0.16.0, a connection to an attacker-influenced endpoint, and, for the on-path variant, plaintext AMQP. The advisory reproduces the overflow with AddressSanitizer and a crafted handshake stream.

Impact

The expected outcome is a crash of the client process. Confidentiality is unaffected, integrity impact is low and availability impact is high, which is why the vector ends in C:N/I:L/A:H. Code execution is described as theoretically possible and was not demonstrated.
From a detection standpoint the useful consequence is that an attempt looks like an ordinary connection to an unusual endpoint followed by a peer sending an absurdly small frame size and a client dying.

Affected products and scope

Any application linked against librabbitmq below 0.16.0 is exposed, plus wrappers that speak through the C library. The broker is not the vulnerable component.

Exposure context

The product query app="RabbitMQ" on ZoomEye returned 741,523 assets. The CVE filter vul.cve="CVE-2026-44236" returned 0.
That mismatch is expected. The vulnerable code runs in clients, which generally open outbound connections and expose no service banner, so scanning the internet for the CVE finds nothing even when vulnerable clients exist. Treat the product count as context about how widely RabbitMQ is deployed, not as a list of victims.

Detection opportunities

Several places can see this attack.
Packet capture on the client host or its egress path can parse the AMQP handshake and flag a connection.tune frame whose frame_max falls below 4096. This is the cleanest signal, because legitimate brokers do not advertise a frame size under the protocol minimum.
Connection inventory and proxy logs can flag a client reaching a broker address that is new, self-signed, or outside the approved allowlist. Combined with a crash in the same minute, that sequence is worth escalating.
Process telemetry can record the crash itself. A message consumer or integration worker that terminates during connect, repeatedly and across deployments, is a plausible symptom.
Each signal is weak alone, and together they help separate a tampering attempt from routine broker instability.

Remediation and mitigations

Upgrade to rabbitmq-c 0.16.0. The release notes list the fix and pull request 879 contains it.
Supporting controls:

• Enforce TLS with certificate verification so the on-path variant becomes impractical.

• Constrain which endpoints clients may contact and alert on deviations.

• Retain core dumps and crash metadata from consumers so a single failure can be analysed instead of retried into oblivion.

• Add a minimum-frame-size assertion in any in-house AMQP client and log violations.
  The window for detection is the handshake. Once the client crashes, the exchanged bytes are gone unless something recorded them, which is why egress capture or a proxy in front of the broker pays for itself here.