The async fast lane skipped the bouncer — TLS hostname checks silently vanish in HttpClient 5.4+ async mode
Apache HttpComponents Client versions 5.4 through 5.6.3 contain a bug where the HostnameVerificationPolicy#BUILTIN setting is silently ignored on the async transport (CloseableHttpAsyncClient). The classic (blocking) CloseableHttpClient is not affected. In practice, any Java application using the async API over HTTPS will accept a TLS certificate issued for *any* domain, enabling a man-in-the-middle attacker with network position to intercept or modify traffic. The fix landed in version 5.6.4.
Apache scored this CVSS 9.1 CRITICAL with AV:N/AC:L/PR:N/UI:N, which overstates the real-world risk. The vector treats the attack as though a remote unauthenticated adversary can exploit it directly — but the prerequisite is a man-in-the-middle position on the network path between client and server, which implies prior network compromise, DNS hijacking, or a privileged vantage point. Additionally, only applications using the *async* API are vulnerable; the majority of enterprise Java code still relies on the classic blocking API. The vendor severity does not account for either friction point.
4 steps from start to impact.
Identify target application using async HttpClient 5.4–5.6.3
CloseableHttpAsyncClient from httpcomponents-client5 in the affected version range. This can be inferred from dependency manifests (pom.xml, gradle lockfiles) exposed in repos, or from behavioral fingerprinting of HTTP/2 negotiation patterns.- Target application uses async HttpClient 5.4–5.6.3
- Application makes outbound HTTPS calls via the async API
- Most Java applications still use the classic (blocking) HttpClient API
- Version must be ≥5.4 and <5.6.4 — a roughly two-year window but many orgs still run 4.x
Obtain man-in-the-middle network position
- Network-level access on the path between client and target server
- Ability to intercept and modify TCP streams
- Enterprise networks with 802.1X, DHCP snooping, and dynamic ARP inspection block ARP-based MITM
- Cloud VPCs with security groups and private endpoints limit lateral interception
- DNS-over-HTTPS and DNSSEC reduce DNS poisoning surface
Present a valid certificate for a different domain
evil.example.com via a free CA like Let's Encrypt. The vulnerable async client will complete the TLS handshake without checking whether the certificate's CN/SAN matches the intended server hostname.- A valid TLS certificate for any domain (trivially obtainable via Let's Encrypt)
- Certificate Transparency logs record certificate issuance, enabling post-hoc detection
- Some applications pin certificates or use custom
TrustStrategyimplementations that are unaffected
Intercept or tamper with application traffic
- Sustained MITM position for the duration of the session
- Short-lived connections and connection pooling limit the window
- Application-layer integrity checks (signed responses, checksums) may detect tampering
The supporting signals.
| In-the-Wild Exploitation | No known exploitation in the wild as of 2026-08-19. Not listed on CISA KEV. |
|---|---|
| Proof of Concept | No public PoC exploit code identified. The bug is a configuration regression, not a memory corruption — exploitation is conceptually trivial (standard MITM tooling like mitmproxy or bettercap) once network position is achieved. |
| EPSS Score | 0.00187 (9th percentile) — very low predicted exploitation probability. |
| KEV Status | Not listed. No CISA deadline applies. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — 9.1 CRITICAL. The AV:N/AC:L scoring is questionable for a MITM-prerequisite vulnerability; AC:H would be more appropriate, which would drop the score to ~7.4. |
| Affected Versions | Apache HttpComponents Client 5.4 through 5.6.3 (async API only). Classic/blocking API unaffected. HttpClient 4.x unaffected. |
| Fixed Version | 5.6.4 (Apache advisory) |
| Downstream Impact | Confirmed affected: Apache Iceberg #15598 (REST catalog client). Likely transitive exposure in Spring ecosystem, Elasticsearch Java client, and other consumers of httpclient5 async APIs. |
| Scanning / Exposure | No Shodan/GreyNoise/Censys exposure data applicable — this is a client-side library vulnerability, not an exposed service. Detection requires SBOM/SCA analysis of application dependencies. |
| Disclosure | 2026-08-11 via Apache security mailing list. Reported by unknown researcher. GHSA: GHSA-72q8-9rgw-5g6j. |
noisgate verdict.
Downgraded from CRITICAL because the single most decisive factor is the man-in-the-middle prerequisite, which transforms this from an unauthenticated remote exploit into a post-positioning attack requiring prior network compromise or privileged vantage. The async-only scope further narrows the reachable population to a minority of HttpComponents Client deployments.
Why this verdict
- MITM prerequisite compounds attack complexity: The CVSS vector scores AV:N/AC:L, but real-world exploitation requires the attacker to already hold a network interception position (ARP spoof, DNS hijack, compromised proxy). This is effectively AC:H, which alone drops the score from 9.1 to ~7.4.
- Async-only scope narrows the vulnerable population: The classic (blocking)
CloseableHttpClient— which is the dominant usage pattern in enterprise Java — is unaffected. Only applications explicitly usingCloseableHttpAsyncClientare vulnerable, estimated at <30% of httpclient5 consumers. - No exploitation evidence or weaponized tooling: EPSS is 0.00187 (9th percentile), no KEV listing, no public PoC, no campaigns observed. The bug is a silent regression, not a weaponizable primitive that scales.
- Role multiplier: Apache HttpComponents Client 5.x is a general-purpose Java HTTP library, not a canonically high-value-role component. However, it appears as a transitive dependency in CI/CD tooling (Maven/Gradle plugin HTTP transports), data platform clients (Apache Iceberg REST catalog), and microservice frameworks. In CI/CD contexts, MITM on artifact fetches could enable supply-chain poisoning — this keeps the floor at HIGH. In typical application-server roles, the blast radius is limited to the data transiting that single service's outbound connections (host-level, not fleet-level).
Why not higher?
CRITICAL would require either active exploitation, a directly reachable attack surface without prerequisites, or a canonically high-value-role component where ≥10% of installs occupy that role. This CVE has none of those: the MITM prerequisite is a hard gate, no exploitation exists, and the library is general-purpose with only incidental high-value-role exposure via transitive dependencies.
Why not lower?
MEDIUM would undercount the supply-chain risk surface. Apache HttpComponents Client 5.x is one of the most widely used Java HTTP libraries, and the async API is gaining adoption with HTTP/2 and reactive frameworks. A successful MITM against a CI/CD pipeline or artifact-fetching service using the async client could yield fleet-scale compromise via poisoned builds. The complete absence of hostname verification (not a partial bypass) also means exploitation, once positioned, is trivial.
What to do — in priority order.
- Audit your SBOM for httpclient5 async API usage — Run SCA tooling (Snyk, Trivy, Dependabot) across all Java services to identify which applications import
CloseableHttpAsyncClientfrom httpclient5 5.4–5.6.3. Prioritize CI/CD pipelines and data platform clients. Complete within the noisgate mitigation SLA of 30 days. - Pin or upgrade httpclient5 to ≥5.6.4 — The simplest fix is a dependency version bump. For Maven: update
<version>in your POM; for Gradle: update the dependency declaration. Test for behavioral changes in TLS handling. Deploy within 30 days per noisgate mitigation SLA. - Enforce network segmentation and ARP protections — Enable DHCP snooping, dynamic ARP inspection, and 802.1X on segments hosting affected services to prevent the MITM prerequisite. In cloud, use private endpoints and VPC service endpoints to eliminate network-path interception opportunities.
- Switch affected services to classic HttpClient API as an interim measure — If upgrading the library is blocked by compatibility testing, refactor the HTTP call sites from
CloseableHttpAsyncClienttoCloseableHttpClient(blocking). The classic API is unaffected by this CVE. This is a code change, so scope it to the most critical services first.
- WAF / reverse proxy in front of the application — this is a *client-side outbound* TLS issue. A WAF protects inbound traffic to the server; it does nothing to validate the certificates the client accepts on its outbound connections.
- Certificate pinning at the load balancer — pinning at the LB only protects the LB-to-backend leg. The vulnerable client's outbound calls to *other* services bypass the LB entirely.
- Upgrading only the classic HttpClient dependency — the async and classic APIs share the same Maven artifact (
httpclient5). You must upgrade the artifact to 5.6.4+; you cannot patch them independently.
Crowdsourced verification payload.
Run this on any host where your Java application is deployed, or in your CI pipeline. It scans the application's classpath JARs for the affected httpclient5 version. Requires read access to the application's lib directory. Example: bash check_cve_2026_71290.sh /opt/myapp/lib
#!/usr/bin/env bash
# check_cve_2026_71290.sh — Detect CVE-2026-71290 (Apache HttpComponents Client async TLS bypass)
# Usage: bash check_cve_2026_71290.sh <path-to-lib-directory>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
LIB_DIR="${1:-}"
if [[ -z "$LIB_DIR" ]]; then
echo "Usage: $0 <path-to-lib-directory>"
exit 2
fi
if [[ ! -d "$LIB_DIR" ]]; then
echo "UNKNOWN — directory $LIB_DIR does not exist"
exit 2
fi
# Look for httpclient5 JARs
FOUND=0
VULN=0
for jar in "$LIB_DIR"/httpclient5-5.*.jar; do
[[ -e "$jar" ]] || continue
FOUND=1
# Extract version from filename
VERSION=$(basename "$jar" | sed -n 's/httpclient5-\([0-9.]*\)\.jar/\1/p')
if [[ -z "$VERSION" ]]; then
continue
fi
# Compare version: affected is 5.4 <= ver < 5.6.4
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)
PATCH=${PATCH:-0}
if [[ "$MAJOR" -eq 5 ]]; then
if [[ "$MINOR" -ge 4 ]] && [[ "$MINOR" -lt 6 ]]; then
echo "VULNERABLE — httpclient5-$VERSION (affected: 5.4 <= v < 5.6.4)"
VULN=1
elif [[ "$MINOR" -eq 6 ]] && [[ "$PATCH" -lt 4 ]]; then
echo "VULNERABLE — httpclient5-$VERSION (affected: 5.4 <= v < 5.6.4)"
VULN=1
else
echo "PATCHED — httpclient5-$VERSION (>= 5.6.4)"
fi
fi
done
if [[ "$FOUND" -eq 0 ]]; then
# Also check Maven local repo or Gradle cache
echo "UNKNOWN — no httpclient5-5.x JARs found in $LIB_DIR"
echo "Tip: also check ~/.m2/repository/org/apache/httpcomponents/client5/httpclient5/"
exit 2
fi
if [[ "$VULN" -eq 1 ]]; then
exit 1
else
exit 0
fiIf you remember one thing.
httpclient5 5.4–5.6.3 usage, then flag services that use the *async* API (CloseableHttpAsyncClient). Prioritize CI/CD pipelines and data platform clients (e.g., Apache Iceberg) for immediate library upgrade to 5.6.4. Per the noisgate mitigation SLA, deploy compensating controls (network segmentation hardening or API swap to classic HttpClient) within 30 days. Per the noisgate remediation SLA, complete the library upgrade across all affected services within 180 days. There is no active exploitation and no KEV listing, so this is a planned patch cycle — not an emergency.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.