Spring AMQP EUVD-2026-35898

The vulnerability is triggered only when application code uses RabbitConnectionFactoryBean.setUri("amqps://...") - the TLS-signaling URI scheme - without also calling setUseSSL(true) on the same bean instance. Applications that explicitly call setUseSSL(true), use plain amqp:// (non-TLS) connections, configure TLS entirely through other means, or do not use RabbitConnectionFactoryBean at all are not affected. Beyond the code condition, exploitation is constrained by AC:H (CVSS): the attacker must hold an active man-in-the-middle network position on the path between the Spring AMQP client and the RabbitMQ broker at the time of connection establishment. This limits viable attackers to those with local network access to the broker path, compromised network infrastructure, or network-layer privileges in multi-tenant cloud environments. No authentication to the Spring application is required (PR:N), and no end-user interaction is involved (UI:N).

The CVSS 3.1 base score of 4.0 (Medium) with vector AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N reflects a nuanced risk profile. AV:N confirms the vulnerability is reachable over the network, but AC:H is the critical limiting factor - exploitation requires the attacker to have already achieved a man-in-the-middle network position between the Spring application and its RabbitMQ broker, which is not trivially accessible. PR:N and UI:N mean no authentication or victim interaction is needed once that position is held. The impact is limited to low confidentiality exposure (C:L) with no integrity or availability consequence, though S:C suggests message content from adjacent services processed through the queue may also be exposed. No EPSS score was provided in the source intelligence, preventing probabilistic exploitation assessment. This CVE is not listed in CISA KEV, and no POC is identified, so there is no confirmed or publicly demonstrated exploitation path. Real-world priority is moderate for organizations routing AMQP traffic over untrusted network segments (cloud multi-tenant VLANs, peered VPCs, hybrid environments); organizations with fully trusted, isolated broker network paths face substantially lower practical risk. This is primarily a code-correctness and secure-defaults issue rather than a broadly weaponizable vulnerability.

An attacker with a man-in-the-middle position on a shared cloud VLAN - achieved, for example, via ARP spoofing or by compromising a network appliance - intercepts the TLS handshake between a Spring AMQP application and its RabbitMQ broker, presenting a self-signed certificate for the broker's hostname. Because the application calls setUri("amqps://...") without setUseSSL(true), no certificate or hostname validation is performed and the handshake completes successfully against the rogue broker. The attacker then passively reads the decrypted AMQP message stream, potentially harvesting credentials, API tokens, or sensitive business data transiting the queue.