| Package | Affected versions | Patched versions |
|---|---|---|
| com.rabbitmq:amqp-client | < 5.35.0 | 5.35.0 |
| rabbitmq java client | < 5.35.0 | 5.35.0 |
When property-file/Map-based ConnectionFactory setup fails while parsing the uri key, the library wraps the underlying exception with the raw connection string — including the plaintext username and password — baked verbatim into the new exception's message.
ConnectionFactoryConfigurator.load(ConnectionFactory, Map<String,String>, String) (src/main/java/com/rabbitmq/client/ConnectionFactoryConfigurator.java, lines 142-155):
String uri = properties.get(prefix + "uri");
if (uri != null) {
try {
cf.setUri(uri);
} catch (URISyntaxException e) {
throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e);
} catch (NoSuchAlgorithmException e) {
throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e);
} catch (KeyManagementException e) {
throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e);
}
}
uri is the full AMQP URI — amqp(s)://username:password@host:port/vhost — concatenated verbatim into the exception message on any of the three catch branches. No masking/redaction exists anywhere in this class or in ConnectionFactory.setUri(). This is the library's documented Spring-Boot/ops-config entry point (ConnectionFactory.load(...), available since 4.4.0), not obscure internal code.
RabbitMQ's own AMQP URI spec (rabbitmq.com/docs/uri-spec) explicitly warns the password "should avoid leaking... the full URI should not appear in exception messages or log records." A sibling method twenty lines away (ConnectionFactory.setUri(URI)) already avoids this exact mistake for a different malformed-URI case — this path wasn't caught by that same care.
Note: KeyManagementException is declared in the throws clause but not actually reachable via the current setUri(String) → setUri(URI) call chain — the two real, reachable leak surfaces are the URISyntaxException branch (trivial, deterministic, scheme-independent) and the NoSuchAlgorithmException branch (real but narrower — amqps:// only, requires a restricted/FIPS-style default TLS provider).
Map<String, String> props = new HashMap<>();
props.put("uri", "amqp://svc-account:P@ssW0rd With [email protected]:5672/prod");
ConnectionFactory cf = new ConnectionFactory();
ConnectionFactoryConfigurator.load(cf, props, "");
Throws:
java.lang.IllegalArgumentException: Error while setting AMQP URI: amqp://svc-account:P@ssW0rd With [email protected]:5672/prod
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeA password containing a space is entirely ordinary under common corporate password policies, and java.net.URI rejects such input outright — this isn't a contrived edge case.
Default Spring Boot startup-failure logging, an APM/error tracker, a CI job log, or an engineer pasting a stack trace into an internal or public ticket now holds the plaintext broker password, in a system typically far less access-controlled than wherever the credential is normally stored. Note the underlying URISyntaxException also carries the same string in its own message, chained as the cause of RabbitMQ's IllegalArgumentException — so removing RabbitMQ's own + uri concatenation alone would not fully close this; the raw secret-bearing string also shouldn't be handed to new URI() for error-reporting purposes at all.
Suggested fix: don't include the raw uri string in the wrapped exception's message — redact the userinfo component (or omit the URI entirely) before including it in any exception text.