RabbitMQ Java CVE-2026-106121: truncated JSON can stop an RPC service

CVE-2026-106121, published on October 6, describes denial of service in the RabbitMQ Java client’s JSON parser. Truncated input can exhaust heap memory or leave a thread consuming CPU indefinitely. The record’s description identifies a fix in 5.37.0.

Breachroad recommends checking whether your applications use JSON-RPC-over-AMQP tooling with the default mapper. RabbitMQ’s presence in the infrastructure does not establish that the affected path is used. The application owner should assess the client-side dependency, while the queue administrator reviews access to messages.

The scope is narrower than every RabbitMQ deployment

The project advisory lists com.rabbitmq:amqp-client through 5.36.0. The issue affects com.rabbitmq.tools.jsonrpc with DefaultJsonRpcMapper, also selected when no custom mapper is supplied. An attacker needs to deliver a message to the RPC request queue or control an RPC service’s reply to a client.

Our proposal for developers is to inspect RPC client and server construction and the mapper selected in code and configuration. Do not assume that an absent explicit mapper name means no mapper is used. Identify deployments sharing the same application artefact and where the loaded library version can be confirmed.

The review result should connect the service name, dependency, parsing path and responsible person. If an application does not use the advisory’s tooling, record the basis for that assessment. If it does, include it in the update plan alongside the business owner who needs the service to remain available.

Use the project’s release as the patch reference

Release 5.37.0, available since October 1, includes a fix to the deprecated JSON reader. It is also the version identified by the project advisory. We use it as our update reference; assess another build using vendor confirmation that it includes the change.

We recommend checking the artefact deployed in the service and then the running replicas. Updating a dependency declaration does not prove that production is using the corrected library. Keep the release identifier and verification result with the update task so that the deployed change can be traced.

When planning the update, consider compatibility with supported messages and the application’s behaviour after invalid data is rejected. The team should know who decides whether to retry work, how failure is detected and when a missing response is escalated. These decisions help prevent uncontrolled repetition of work after a failure.

Restrict senders and observe consumers

Breachroad proposes reviewing permission to publish to RPC queues and the identities of services supplying replies. Every sender should have a justified access scope. Identify an owner for permissions left behind by a retired integration or an old test environment as well.

Connect memory and CPU monitoring with evidence that consumers are making progress. Stalled consumption, growing backlogs and repeated restarts need investigation. They are operational signals rather than independent proof that this CVE has been exploited. Preserve enough information to distinguish malformed input from a capacity problem or an unrelated application fault.

Assess time, size and request-count limits as parts of service resilience. We do not present them as substitutes for a parser fix: an availability review also needs to establish what happens after a message has been accepted. Document temporary measures separately from confirmed remediation so that remaining update work stays visible.

A scenario for an operations team

Imagine a billing service invoked through internal RPC. In an illustrative process, a developer confirms default-mapper usage, the administrator checks senders and the service owner plans the update and a check of behaviour after invalid input. The team documents the result rather than stopping at news that the queue infrastructure has been updated.

This is an example from Breachroad, rather than a reported incident. Our cybersecurity training for organisations can help IT teams practise assessing vulnerability scope, assigning dependency ownership and reporting service-availability problems.