Crash During Connect: Triaging a Suspected CVE-2026-44236 Incident

A message consumer dies while opening its connection. The service manager restarts it, it dies again, then it stabilises and everyone moves on. Under CVE-2026-44236 that pattern can be the only trace of an attack, because the exploit completes inside the login handshake and leaves the client, not the broker, holding the damage.

The underlying bug

rabbitmq-c before 0.16.0 accepts a server-supplied connection.tune.frame_max below the AMQP minimum of 4096 bytes. amqp_tune_connection() in librabbitmq/amqp_connection.c sizes the outbound buffer from that value, and the reply path through amqp_frame_to_bytes() writes past it. The issue is CVE-2026-44236, CWE-122, CVSS 3.1 7.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H), fixed in 0.16.0.

What the evidence looks like

Three artefact types are worth collecting before a restart wipes them.
The first is the core dump or crash report. A heap-buffer-overflow in amqp_e16 reached from amqp_frame_to_bytes() and amqp_send_method_inner() is the signature the vendor advisory reproduces with AddressSanitizer. A build without sanitizers may only show a segmentation fault, so the stack and the faulting address matter.
The second is the connection metadata. Which hostname, IP address and port was the client dialling, and was TLS in use. A client that normally talks to a broker behind a valid certificate but crashed while connecting elsewhere deserves a different investigation than a routine restart.
The third is timing. A single crash at deploy time is noise. A cluster of crashes across consumers that share an endpoint, especially after a DNS or configuration change, suggests something upstream changed the traffic.

Why the broker looks fine

The broker is not the vulnerable component, so broker-side logs show a normal connection attempt that ended early. The client crashed before negotiation finished, which means no publish, no consume and no error frame that a broker operator would recognise.
Misattribution usually starts here. Broker metrics stay healthy, the client restarts, the error surfaces as a generic consumer failure, and the incident closes without anyone asking what the peer sent.

Exposure context

ZoomEye reported 741,523 assets for app="RabbitMQ" and 0 for vul.cve="CVE-2026-44236".
The second figure is not a signal of safety. Client libraries do not expose the banner that a CVE-mapped scanning query depends on, so the useful takeaway is the size of the deployed ecosystem, not an absence of vulnerable code.

Containment and response

While the upgrade to rabbitmq-c 0.16.0 is scheduled, four steps limit damage and preserve evidence.

• Require TLS with certificate validation so that an on-path attacker cannot rewrite the tune frame.

• Pin the broker endpoints each client may reach and alert when a connection targets anything else.

• Keep crash dumps and connection metadata long enough to compare several failures instead of discarding them at restart.

• Add a handshake check in custom clients that rejects any frame_max below 4096 and logs the peer address when it does.

Closing the loop

The permanent fix is the library upgrade, verified inside the running artefact rather than in the build log. The investigative work is what turns a recurring consumer crash into a defensible finding, and that work has to happen before the process restarts for the third time.