Most vulnerability response assumes the server is the thing to defend. CVE-2026-44236 inverts that assumption: the server supplies a malformed value, the client trusts it, and the client heap breaks. Any team that treats AMQP traffic as internal and therefore safe should look closely at how the tune frame travels.

The flaw

CVE-2026-44236 is a heap-based buffer overflow in rabbitmq-c before 0.16.0, classified CWE-122 and scored 7.1 on CVSS 3.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H). The vendor advisory is GHSA-jh48-qjf5-fx5v, and the fix is in 0.16.0.

How the handshake breaks

The AMQP connection opens with a protocol header, then connection.start, then the server's connection.tune, which carries frame_max. That field is meant to describe the largest frame the peer will accept, bounded below by the AMQP minimum frame size of 4096 bytes.
amqp_login_inner() in librabbitmq/amqp_socket.c accepts the server value when it is lower than the client's request. amqp_tune_connection() in librabbitmq/amqp_connection.c adopts it as the outbound buffer size and enforces no floor. A tune frame claiming frame_max of 1 leaves a one-byte buffer, and serialising connection.tune-ok writes the two-byte frame header beyond it.

Why the on-path variant deserves attention

An attacker who controls the broker endpoint can send that frame directly. The harder case is the attacker who does not control the broker: on plaintext AMQP, a position on the network path can rewrite connection.tune in flight, shrinking frame_max before the client parses it. The client has no way to tell the frame was edited.
This matters because plaintext AMQP inside a trusted network segment is common. Service meshes terminate TLS at a sidecar and forward clear text locally; legacy integrations never enabled TLS; test environments mirror production without the certificates. Each of those is a place where an on-path position exists, whether or not anyone calls it a risk.

Impact

The advisory expects memory corruption and likely denial of service. Availability impact is high, confidentiality is untouched and integrity impact is low. Remote code execution is described as possible in theory and not demonstrated.
A crashed consumer is the visible symptom. The invisible part is that the crash was induced by traffic the client believed came from its own broker, which means the retry path reconnects and may be hit again.

Exposure context

Two ZoomEye queries inform the picture. app="RabbitMQ" returned 741,523 assets, while vul.cve="CVE-2026-44236" returned 0.
The asymmetry is expected: the affected code is a client library, not a listening service. The product count tells you how widely the ecosystem is deployed, not how many clients are vulnerable, and the zero filter result is not a clean bill of health.

Controls that change the calculus

Transport security is the decisive control. Requiring TLS with certificate validation on every AMQP connection removes the on-path variant and leaves only the case where an attacker controls the server itself.
Endpoint allowlisting narrows the second case. A client that will only connect to a fixed set of broker addresses cannot be redirected to an attacker endpoint by a poisoned DNS answer or a tampered configuration file.
Monitoring adds the remaining value. A consumer crash during connect, paired with an unexpected broker address or a self-signed certificate, is worth investigating rather than restarting on schedule.
Upgrade to rabbitmq-c 0.16.0 remains the fix. The transport controls decide how much exposure exists between now and the completion of that rollout.