- The RabbitMQ Java client can copy a full connection string, password included, into an error message when the connection URI fails to parse, per a GitHub advisory (CVE-2026-106123).
- Error messages land in logs, monitoring tools, CI output and support tickets, which the advisory describes as typically far less access-controlled than where the credential is normally stored.
- Search logs for broker credentials, rotate any exposed password, and ask which systems pass connection strings through the affected loading method.
The leak is not a theft. It is a courtesy.
Secrets often escape not through a broken vault but through a system trying to be helpful. This advisory is a clean example.
A new advisory covers the RabbitMQ Java client. When the connection address fails to parse, the library writes a detailed error. The detail includes the password.
The lesson here is simple. An error message is a copy of your data that nobody put on the inventory. It travels to places the original secret was never meant to go.
What the advisory describes
The GitHub Advisory Database published the finding on October 7, 2026. It is tracked as CVE-2026-106123.
The affected code is the method ConnectionFactoryConfigurator.load(). Teams use it to set up a RabbitMQ connection from a property file or a map of settings. The advisory calls it the library's documented entry point for Spring Boot and operations configuration.
The setting in question is the connection address, called the URI. It has the form amqp://username:password@host:port/vhost. The username and password sit inside the address itself.
If parsing that address fails, the library builds a new error. It pastes the raw address into the error text. No masking happens anywhere in the class, the advisory says.
How an ordinary password becomes an exposed one
The advisory names two paths that can actually be reached.
The first is a syntax error in the address. The advisory describes it as trivial, deterministic and independent of the connection scheme. It gives a common example. A password containing a space is ordinary under many corporate password policies, and Java's URI parser rejects it outright.
The second path is narrower. It applies only to encrypted amqps:// connections. It needs a restricted, FIPS-style default TLS provider, which means a locked-down cryptography setup.
A third error type is declared in the code but cannot be reached through the current call chain, the advisory says.
Once the error exists, it moves. The advisory lists where it can end up: default Spring Boot startup-failure logging, an error tracker, a CI job log, or a stack trace pasted into a ticket. Some of those tickets may be public.
That matters because of what the password leaves behind. It moves out of its guarded home and into tools the advisory judges to be far less locked down.
Why a simple fix is not enough
The obvious repair is to stop adding the address to the message. The advisory says that alone would not close the problem.
Java raises its own parsing error first, and that error holds the same address in its text. RabbitMQ attaches it to its error as the cause. A logging tool that prints the whole chain of errors would still show the password.
The advisory notes that ConnectionFactory.load(...) has been available since 4.4.0. That tells you how long the entry point has existed. It does not tell you which versions are affected.
The suggested fix is to remove the username and password section, or drop the address entirely, before any text is built. The advisory adds that the raw string should not be handed to the parser for error-reporting purposes at all.
There is a pointed detail for governance. RabbitMQ's own URI documentation says the full address "should not appear in exception messages or log records." A sibling method about twenty lines away already avoids this mistake for a different bad-address case. This path was missed.
What we do not know
The advisory text does not give a severity score. It does not report exploitation in the wild. It links to the v5.35.0 release of the Java client but does not spell out in the text provided which versions are affected.
Treat those as questions for your engineers and for the project's release notes.
What to ask your team this week
Start with exposure. Ask which services use the RabbitMQ Java client and whether any load their connection address from a property file or settings map.
Then check the evidence. Ask someone to search application logs, error trackers and CI output for connection strings that contain a password. Include old support tickets.
If a password turns up, rotate it. Removing the log line does not undo copies already stored in other tools.
Finally, ask the policy question. Does your log pipeline strip credentials from text before storing it? Fixing one library helps once. Redaction in the pipeline helps for every library.
A password is only as private as the least-guarded place it gets written down, and error messages write it down without asking.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
