Summary
AsyncHttpClient: Digest challenge without a usable nonce downgrades to Basic and sends the password in cleartext
Affected versions
- 3.x: up to and including 3.0.12
- 2.x: up to and including 2.16.0
This is long-standing behaviour on both lines, not a recent regression. On 3.0.12 there is one additional way to reach it: a quoted parameter ending in an unescaped backslash, such as realm="C:\", makes the closing quote read as escaped so the nonce is never found. That trigger is specific to 3.0.12. The downgrade it led to is fixed, but the nonce is still lost on such a challenge: every conformant reader treats the closing quote as escaped. The exchange now fails instead of falling back to Basic.
Workarounds
No configuration prevents this. Until you can upgrade, do not use Digest authentication against a server you do not control, and do not use it over plaintext HTTP.
Details
Realm.Builder.parseWWWAuthenticateHeader and parseProxyAuthenticateHeader selected the scheme with isNonEmpty(nonce) ? AuthScheme.DIGEST : AuthScheme.BASIC, so any challenge that produced no nonce became a Basic challenge and Unauthorized401Interceptor resent the request using computeBasicAuthentication.
Impact
A Digest challenge that does not yield a usable nonce is treated as a Basic challenge. The client then answers it with Authorization: Basic, which carries the username and password base64 encoded and so recoverable by anyone who sees the request.
Any of these is enough, sent by whoever writes the 401 or 407:
WWW-Authenticate: Digest realm="protected"
WWW-Authenticate: Digest realm="protected", nonce=""
The challenge announces itself as Digest, so it passes the check that would otherwise reject a non-Digest challenge for a Digest realm. It then fails to produce a nonce, and the absence of a nonce is what selected Basic. A server offering plain Basic to a Digest realm gets nothing, so labelling the challenge Digest and leaving the nonce out is what makes the difference.
This is reachable by anyone who can write the challenge: a malicious or compromised origin, a proxy, or an attacker on a plaintext hop. Digest exists precisely to keep the password off those hops. A server that stores only HA1, and anyone impersonating the real origin, does not otherwise learn the password itself, so the disclosure enables reuse against other services.
Both the target and the proxy paths are affected, through parseWWWAuthenticateHeader and parseProxyAuthenticateHeader.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in 3.0.13 on the 3.x line and in 2.16.1 on the 2.x line. The scheme now comes from the challenge itself instead of being inferred from whether a nonce was found, so a Digest challenge stays Digest even when it cannot be read. With no nonce it produces no Authorization header at all, which fails the exchange rather than downgrading it.
The 3.x fix also corrects quoted-pair handling so that a backslash before any character other than a quote or another backslash is kept as written, matching Apache HttpComponents. That repairs a 3.0.12 regression where an unescaped realm such as DOMAIN\Users was corrupted to DOMAINUsers and failed every digest comparison. This is a deliberate deviation from a strict reading of RFC 9110 Section 5.6.4, under which a backslash before any character is a quoted-pair. Reading it strictly is what corrupts the unescaped spelling that servers actually send, and the decoding is not reversible either way, so the client follows the same rule as Apache HttpComponents.
Frequently Asked Questions
- What is CVE-2026-107231? CVE-2026-107231 is a high-severity security vulnerability in org.asynchttpclient:async-http-client (maven), affecting versions >= 3.0.0.Beta1, <= 3.0.12. It is fixed in 3.0.13, 2.16.1.
- Which versions of org.asynchttpclient:async-http-client are affected by CVE-2026-107231? org.asynchttpclient:async-http-client (maven) versions >= 3.0.0.Beta1, <= 3.0.12 is affected.
- Is there a fix for CVE-2026-107231? Yes. CVE-2026-107231 is fixed in 3.0.13, 2.16.1. Upgrade to this version or later.
- Is CVE-2026-107231 exploitable, and should I be worried? Whether CVE-2026-107231 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-107231 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-107231?
- Upgrade
org.asynchttpclient:async-http-clientto 3.0.13 or later - Upgrade
org.asynchttpclient:async-http-clientto 2.16.1 or later
- Upgrade