CVE-2026-106122 is a high severity denial of service (CVSS 7.5) in the RabbitMQ Java client. A single AMQP message with malformed UTF-8 can repeatedly disable RPC consumers until someone purges the queue. The fix shipped in version 5.36.0 of com.rabbitmq:amqp-client, so upgrade to that version or later.
What's affected
The record says versions before 5.36.0 are affected. The GitHub advisory GHSA-7822-rcf6-97fx, published on 17 September 2026, gives affected versions up to and including 5.35.0 and a patched version of 5.36.0. Both sources agree. The advisory labels the issue Moderate, while the CVSS score in the record is 7.5 and rates as High. That is a difference between the maintainer label and the scored vector, so plan around the score if your RPC services face untrusted publishers.
The weaknesses listed are CWE-172 (an encoding error) and CWE-248 (an uncaught exception). The vector is network reachable with no privileges and no user interaction, with only availability affected.
The pattern at risk is any consumer that takes a short string property from an incoming message, such as the correlation id, and echoes it back in a reply. The advisory names RpcServer.mainloop() and the tutorial style consumer that publishes replies from a delivery callback.
How to check if you're exposed
Find the resolved version in your build. Maven:
mvn dependency:tree -Dincludes=com.rabbitmq:amqp-client
Gradle:
./gradlew dependencies --configuration runtimeClasspath | grep amqp-client
Versions up to 5.35.0 need the upgrade. Next, look in your code for RPC style consumers that read correlationId or replyTo from the incoming properties and use them when publishing a reply, and for any use of RpcServer. Those are the places where the advisory says a failure escapes.
On the broker side, watch for the symptom the advisory describes: a message that keeps coming back to the queue unacknowledged while consumers drop one after another.
What to do now
- Upgrade
com.rabbitmq:amqp-clientto 5.36.0 or later and redeploy every consumer. - Confirm the resolved version inside the built artifact.
- Wrap reply publication in your own consumers so an unexpected exception is handled and the message is rejected without requeue, rather than left unacknowledged.
- Consider a dead letter queue for RPC request queues, so a poison message is parked and does not circle forever.
- If an incident is already under way, the advisory says the broker keeps requeueing the message until the queue is purged, so isolate the offending message before restarting consumers.
Why it matters
The library decodes a short string from the wire by replacing bad bytes with a replacement character. That character takes three bytes when written back out, so a 255 byte property can grow to 765 bytes. AMQP limits this field type to 255 bytes, and the writer enforces the limit by throwing an unchecked exception. Put simply, the library can read a value that it later refuses to write.
What makes this a durable outage is the acknowledgement flow. Because the exception fires before the acknowledgement, the broker puts the message back on the queue and hands it to the next consumer, which fails the same way. The advisory describes this as a way for any client allowed to use an RPC service to disable it for everyone. The record does not mark the CVE as known exploited.
Try it yourself
See how this kind of finding shows up in a dependency workflow.
Click through it at your own pace, or open it full screen.
Quick check
Is upgrading enough, or do I also need to purge queues?
Upgrading fixes the decoding mismatch. If a poison message is already sitting in a queue, the advisory says it stays there until it is purged, so deal with that message as well.
Which versions are fixed?
Version 5.36.0 fixes this CVE. The related CVE-2026-106121 needs 5.37.0, so moving to 5.37.0 or later covers both.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.
