A RabbitMQ operator can read the CVE-2026-44236 advisory, confirm the broker is patched and still be exposed. The vulnerable code is the C client library that talks to the broker, and in most organisations that library is a transitive dependency nobody tracks directly.

What the advisory actually covers

CVE-2026-44236 is a heap-based buffer overflow, CWE-122, in rabbitmq-c before 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, and the fix ships in rabbitmq-c 0.16.0. The record was published on 17 September 2026.

Why the usual inventory misses it

Broker inventories start from listening services. Something scans port 5672, 15672 or the TLS equivalent, the asset appears in the CMDB with a broker owner, and the patch process follows the service. The client library never answers a scan. It sits inside a consumer, a batch job, an integration service or a CLI tool, and its only network behaviour is outbound.
That difference creates a gap in coverage. An asset marked patched because the broker runs a current release says nothing about whether the application connecting to it links librabbitmq 0.14 or 0.15. Two separate patch streams carry the same product name.

Questions worth answering this week

The first is technical: which applications link rabbitmq-c or librabbitmq below 0.16.0. Package manifests, SBOM exports, container image layers and language lock files can answer it, though bindings may hide the library behind a differently named package.
The second is organisational: who owns the answer. If the broker team owns RabbitMQ and the application teams own their dependencies, the vulnerable middle ground has no owner until an incident assigns one.
The third is about rebuild policy. Even after the dependency list exists, a rebuild is required for images that vendor the library statically. A rebuilt base image does not help if an application layer still carries an old compiled copy.

Mechanism in brief

During the AMQP login handshake, the server sends connection.tune with a frame_max value. amqp_login_inner() in librabbitmq/amqp_socket.c accepts a server value below the client request, and amqp_tune_connection() in librabbitmq/amqp_connection.c uses it as the outbound buffer size without enforcing the AMQP minimum of 4096 bytes. Replying with connection.tune-ok through amqp_frame_to_bytes() then writes past that buffer.
Exploitation needs the client to connect to a malicious or impersonated endpoint, and the on-path variant needs plaintext AMQP. The advisory's AddressSanitizer reproduction reports a two-byte heap write.

Exposure context

ZoomEye's product query app="RabbitMQ" returned 741,523 assets. The CVE filter vul.cve="CVE-2026-44236" returned 0.
Neither number inventories clients. The product count describes internet-facing RabbitMQ services, and the zero filter result reflects that a client library exposes no banner to match. Use the query as context for how widely the ecosystem is deployed, and treat internal dependency scanning as the actual discovery method.

Remediation and verification

Upgrade to rabbitmq-c 0.16.0, which the release notes describe as fixing frame sizes negotiated below the AMQP protocol minimum. Pull request 879 holds the code change.
Verification carries extra weight here. Rebuilding an image, redeploying and closing the ticket does not prove the new library is present, because a stale layer or a cached wheel can survive the pipeline. Confirm the linked library version inside the running container, not only in the build log.
Where the upgrade waits, force TLS with certificate validation and restrict which endpoints clients may reach, which removes the on-path variant and narrows the hostile-endpoint case.