CVE-2026-106123

Ein Angreifer kann mehrere Schwachstellen im RabbitMQ Java Client ausnutzen, um einen Denial of Service Angriff durchzuführen und um Informationen offenzulegen.

### Summary 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. ### Details `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). ### PoC Map<String, String> props = new HashMap<>(); props.put("uri", "amqp://svc-account:P@ssW0rd With Space!@broker.internal: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 Space!@broker.internal:5672/prod A 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. ### Impact 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.