Improper Hostname Verification in Java Client and Proxy can expose authentication data via MITM

Vulnerability

Description

The vulnerability stems from a race condition in the Apache Pulsar Java Client and Pulsar Proxy where TLS hostname verification is performed after authentication data is sent over the connection. This means a client begins sending authentication tokens or credentials before confirming that the server's TLS certificate matches the expected hostname, violating the standard security sequence expected in TLS connections [1].

Exploitation

Conditions

An attacker must achieve a man-in-the-middle position on the network path between the Pulsar client and the legitimate broker or proxy. The attacker must then present a valid, cryptographically signed TLS certificate for an unrelated host to intercept the traffic. Because hostname verification occurs only after the client has already transmitted its authentication payload, the attacker can capture this sensitive data before the client detects the mismatch and closes the connection [1].

Impact on

Authentication

Both token-based and username/password authentication methods are affected, as the intercepted authentication material can be replayed to impersonate the client in a separate session. The exposure window is limited to the short period between authentication transmission and hostname verification, but the leaked credentials remain usable until they expire or are revoked [1].

Mitigation

The vulnerability affects Apache Pulsar Java Client versions 2.7.0 through 2.7.4, 2.8.0 through 2.8.3, 2.9.0 through 2.9.2, 2.10.0, and all 2.6.4 and earlier releases. Organizations should upgrade to a patched version that ensures TLS hostname verification occurs before any authentication data is sent. No workarounds are described beyond following the official upgrade guidance [1].