AMQP defines a minimum frame size of 4096 bytes. rabbitmq-c before 0.16.0 did not enforce it when a server proposed a smaller value, and the result was a heap overflow during login. The bug is small and the fix is narrow. The failure pattern will be familiar to anyone who writes protocol code: a peer-supplied number becomes a memory size without a floor.

The specification and the code

The advisory for CVE-2026-44236 (GHSA-jh48-qjf5-fx5v) states the minimum plainly. The AMQP frame size must be at least 4096 bytes. In amqp_login_inner() in librabbitmq/amqp_socket.c, the client accepts the server's frame_max when it is below its own request. amqp_tune_connection() in librabbitmq/amqp_connection.c then uses the value as the outbound buffer size, and amqp_frame_to_bytes() writes a frame header into it.
With frame_max set to 1, the header write overruns the allocation by a byte at offset 1. NVD scores the issue 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) as CWE-122, and 0.16.0 fixes it.

Three design rules the case illustrates

A negotiated parameter needs both bounds, not one. Implementations usually cap a peer value at their own maximum and forget the minimum. The lower bound protects the receiver, and it is the bound a hostile peer will attack because legitimate peers rarely approach it.
A protocol constant belongs in code, not in a comment. The 4096-byte minimum existed in the documentation before the fix. Making it an assertion in the path that consumes the value is the difference between a described invariant and an enforced one.
An allocation size derived from a peer needs a sanity check adjacent to the allocation. The advisory shows a direct hand-off from the parsed value to buffer sizing. A guard at that point would have failed closed, logged the peer and kept the connection from being established.

Why small overruns are not trivial

A two-byte write looks harmless next to the large overflows that dominate vulnerability reporting. Heap allocations of a few bytes sit next to allocator metadata, so a write beyond the chunk can corrupt the structures that govern later allocations. In practice that produces a crash in an unrelated part of the process, which is harder to diagnose than a clean fault at the write site.
The severity assessment reflects that reality: high availability impact, low integrity impact, no confidentiality impact. Remote code execution is called possible in theory and was not demonstrated.

Who should act

Anyone maintaining a rabbitmq-c based client, a language binding or a fork should upgrade to 0.16.0 and read pull request 879 for the exact change. Teams with their own AMQP implementations should compare their frame-size handling against the same three rules, because the advisory describes a mistake that is easy to repeat.

Exposure context

ZoomEye's app="RabbitMQ" query returned 741,523 assets. The vul.cve="CVE-2026-44236" filter returned 0.
That outcome follows from where the code lives. Client libraries do not advertise themselves on a network, so no scanning query will enumerate them. The product figure describes deployment breadth, not victim count.

Practical mitigation

Upgrade to rabbitmq-c 0.16.0. Until that lands, TLS with certificate validation prevents on-path modification of the tune frame, endpoint allowlisting limits which servers a client will talk to, and a local assertion in any in-house client rejects a frame_max below the protocol minimum.
Protocol invariants are security controls. Treating the minimum frame size as a documented courtesy rather than an enforced boundary is what turned a specification detail into a heap overflow.