Apache HttpComponents TLS Hostname Verification Bypass

Executive Summary

A critical TLS hostname verification bypass has been discovered in Apache HttpComponents Client 5.4 and newer. Tracked as CVE-2026-71290 with a CVSS score of 9.1, the vulnerability causes the HostnameVerificationPolicy#BUILTIN setting to have no effect when using the asynchronous version of the HTTP client. An attacker positioned to intercept and modify traffic between client and server can impersonate any TLS endpoint, undermining the foundational security guarantee of HTTPS.

Any application that uses the async HttpClient API with explicit hostname verification configuration on HttpComponents 5.4+ is potentially vulnerable.

Vulnerability Details

Technical Analysis

How TLS Hostname Verification Works

When a TLS connection is established, the client must verify that the server's certificate matches the hostname being connected to. This step prevents man-in-the-middle (MITM) attacks where an adversary presents a valid certificate for a different domain. The HostnameVerificationPolicy#BUILTIN setting in Apache HttpComponents is designed to enforce this check using the JDK's built-in hostname verifier.

The Defect

Starting in Apache HttpComponents Client 5.4, a code path regression causes HostnameVerificationPolicy#BUILTIN to be silently ignored in the async (non-blocking) version of the client. The result: TLS connections made through the async API proceed without hostname validation, regardless of the developer's configuration.

An attacker who can intercept traffic on the network path — such as via ARP spoofing on a local network, a compromised router, or a rogue Wi-Fi access point — can present an arbitrary TLS certificate and successfully impersonate the target server.

Impact Scope

The vulnerability specifically affects:

• Applications using CloseableHttpAsyncClient (async API) on HttpComponents 5.4+
• Any configuration that explicitly sets HostnameVerificationPolicy#BUILTIN expecting it to be honoured
• Environments where TLS connections traverse untrusted network segments

The synchronous (CloseableHttpClient) API is not affected by this regression.

Why CVSS 9.1?

Despite requiring a network-adjacent position for exploitation, the impact is rated critical because:

1. The bypass is silent — no error is thrown, no log entry produced
2. Applications believe they are protected; developers see no indication the setting is being ignored
3. The consequence is full TLS authentication bypass, allowing credential theft, session hijacking, and data exfiltration

Affected Products

Recommended Actions

Immediate Steps

1. Inventory usage: Identify any applications or services in your environment that depend on Apache HttpComponents Client 5.4+
2. Check async usage: Determine whether affected applications use CloseableHttpAsyncClient or the async builder API
3. Apply patch: Upgrade to the patched version of HttpComponents Client once released by the Apache Software Foundation
4. Workaround (temporary): If immediate patching is not possible, switch affected async clients to use custom HostnameVerifier implementations that explicitly call SSLParameters.setEndpointIdentificationAlgorithm("HTTPS"), bypassing the broken policy constant

Build Pipeline Checks

Add version checks to your dependency scanning pipeline to flag any transitive pull of HttpComponents 5.4+ until a patched release is available. This vulnerability may also be present in libraries that bundle HttpComponents as a transitive dependency.

Context for Java Developers

Apache HttpComponents Client is one of the most widely used HTTP client libraries in the Java/JVM ecosystem. It serves as a dependency for dozens of popular frameworks and SDKs. Organizations should scan their full dependency tree — not just direct dependencies — for exposure.

Tools like mvn dependency:tree, gradle dependencies, or commercial SCA tools can identify transitive pulls.

References

• NVD Entry: CVE-2026-71290
• Apache HttpComponents Project
• Apache Security Team