CVE-2026-106123 in Java Client
Summary
by MITRE • 10/06/2026
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.35.0, ConnectionFactoryConfigurator.load() includes the raw uri value in wrapped exceptions when AMQP URI parsing fails. Because the URI may contain a plaintext username and password, startup logs, application performance monitoring systems, CI logs, and copied stack traces can disclose broker credentials to users who should not have access to them. This issue is fixed in version 5.35.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The RabbitMQ Java client library serves as a critical component for enabling Java and JVM-based applications to establish connections with RabbitMQ message brokers, facilitating robust asynchronous communication patterns within distributed systems. A significant security vulnerability was identified in versions of this library prior to 5.35.0, specifically residing within the ConnectionFactoryConfigurator.load() method. This flaw pertains to improper handling of sensitive data during the initialization phase when parsing AMQP URIs that contain embedded credentials. The core technical issue arises because the exception wrapping mechanism inadvertently includes the raw URI string in the resulting error messages when parsing fails due to malformed input or connectivity issues. Since standard AMQP URIs often embed plaintext usernames and passwords directly within the scheme-specific part of the URL, this design flaw results in the direct exposure of these credentials whenever an initialization failure occurs.
The operational impact of this vulnerability is substantial because it leads to credential leakage through multiple common logging and monitoring channels. When a connection attempt fails, the application typically logs the exception stack trace for debugging purposes or forwards it to centralized log aggregation systems such as ELK Stack, Splunk, or Datadog. Additionally, application performance monitoring tools often capture these exceptions to track error rates and latency. Consequently, any user with access to these logs, including CI/CD pipeline outputs, development team members reviewing build artifacts, or potentially external observers if the logs are misconfigured for public visibility, can extract the plaintext broker credentials from the stack traces. This exposure violates fundamental security principles regarding the protection of authentication secrets and undermines the confidentiality aspect of the CIA triad.
From a classification perspective, this vulnerability aligns with CWE-209: Generation of Error Message Containing Sensitive Information, as it involves the creation of an error message that discloses sensitive data to unauthorized actors. It also relates to CWE-532: Information Exposure Through Log Files, given that the primary vector for exploitation is through log aggregation systems where such information might be retained indefinitely or accessed by a broader audience than intended. In terms of adversary tactics, this scenario maps to ATT&CK technique T1078: Valid Accounts, as an attacker could leverage these leaked credentials to authenticate against the RabbitMQ broker and potentially gain unauthorized access to message queues, leading further into techniques like T1530: Data from Cloud Storage or T1046: Network Service Discovery if they proceed to enumerate resources within the messaging infrastructure.
To mitigate this risk, organizations must immediately upgrade the RabbitMQ Java client library to version 5.35.0 or later, where the ConnectionFactoryConfigurator.load() method has been patched to exclude raw URIs from wrapped exceptions. For environments that cannot update immediately due to dependency constraints, a temporary mitigation involves implementing custom exception handling logic to sanitize any stack traces before they are logged or transmitted to monitoring systems. This includes stripping out URI components and replacing sensitive parameters with masked placeholders such as asterisks. Furthermore, it is advisable to audit existing log files for historical instances of this vulnerability if the affected library version was previously deployed in production, ensuring that no plaintext credentials remain stored in persistent log storage. Implementing strict access controls on logging infrastructure and employing secret management solutions like HashiCorp Vault or AWS Secrets Manager can also reduce the blast radius should such exposures occur again by decoupling credential handling from application startup logic.