GHSA-FJ9W-C36G-H5X8
Vulnerability from github – Published: 2026-09-17 17:18 – Updated: 2026-09-17 17:18Impact
For SCRAM, and for Digest with mutual authentication, the client computes the server's verification value (the SCRAM ServerSignature, or the Digest rspauth) but does not act on the result. If the value is present and does not verify, the client only logs it and still delivers the response to the application as a successful, authenticated result. A server that never proved knowledge of the shared secret is accepted, so the client loses its ability to detect an impostor. Over TLS the real server always returns a valid value and the issue is inert; it matters over a non TLS transport, or when the transport is already compromised, where it removes the client's only signal that the peer does not know the secret.
Affected versions
- 3.x: 3.0.8 through 3.0.11
Earlier 3.0.x releases are not affected: neither SCRAM nor the Digest Authentication-Info handling existed before 3.0.8. The 2.x line is not affected either: it has no SCRAM support, and its interceptor chain does not implement Digest mutual authentication, so there is no verification result to act on.
Patches
Fixed in 3.0.12. A present ServerSignature (SCRAM) or rspauth (Digest) that does not verify now fails the request instead of being logged and ignored, on both the origin and proxy paths.
Known limitations
Verification is only enforced when the value is present and the parameters the client sent can be recovered. A response that omits the Authentication-Info header entirely, or that carries the header without a recognisable verification parameter, is still accepted: a well behaved server may send the value in chunked trailers, which the client does not read. An impostor that simply omits the value is therefore still accepted. The two schemes differ on malformed input: SCRAM aborts when the data parameter is present but is not valid base64, whereas Digest treats an unparseable rspauth (an unterminated quote, an empty unquoted value, or a bare rspauth token) as absent and accepts the response. Enforcing presence is tracked as a follow up.
Verification is also skipped when the parameters the client sent cannot be recovered from its own Authorization header, in which case the exchange is delivered rather than failed.
Details
In the auth interceptor, processScramAuthenticationInfo and processAuthenticationInfo computed the verification value and compared it, but did not stop the response from being delivered. Both now abort the exchange when the value is present and does not verify. The Digest expected value must be computed over the parameters actually sent on the wire, which the client recovers from its own Authorization header, because the realm carried on the response future is rebuilt for header emission and does not hold the values that were sent.
Note that 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. Upgrade to 3.0.13 to pick up both fixes.
Known limitation
This fix does not cover Digest exchanges negotiated with qop="auth-int". Under auth-int the rspauth signs the response entity-body, which has not been read when the header is processed, so the expected value cannot be derived at that point. The client logs a warning and delivers the response without enforcing mutual authentication.
A peer that controls the challenge can select this deliberately by offering qop="auth-int" alone, which switches mutual authentication off for the whole exchange. Offering auth,auth-int does not work, because the client prefers auth. Verification under auth-int needs to be deferred until the body has been read, which is tracked separately as GHSA-qhv6-3pmh-95q4.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.11"
},
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.8"
},
{
"fixed": "3.0.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-85716"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-390"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T17:18:39Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nFor SCRAM, and for Digest with mutual authentication, the client computes the server\u0027s verification value (the SCRAM ServerSignature, or the Digest rspauth) but does not act on the result. If the value is present and does not verify, the client only logs it and still delivers the response to the application as a successful, authenticated result. A server that never proved knowledge of the shared secret is accepted, so the client loses its ability to detect an impostor. Over TLS the real server always returns a valid value and the issue is inert; it matters over a non TLS transport, or when the transport is already compromised, where it removes the client\u0027s only signal that the peer does not know the secret.\n\n### Affected versions\n* 3.x: 3.0.8 through 3.0.11\n\nEarlier 3.0.x releases are not affected: neither SCRAM nor the Digest Authentication-Info handling existed before 3.0.8. The 2.x line is not affected either: it has no SCRAM support, and its interceptor chain does not implement Digest mutual authentication, so there is no verification result to act on.\n\n### Patches\nFixed in 3.0.12. A present ServerSignature (SCRAM) or rspauth (Digest) that does not verify now fails the request instead of being logged and ignored, on both the origin and proxy paths.\n\n### Known limitations\nVerification is only enforced when the value is present and the parameters the client sent can be recovered. A response that omits the Authentication-Info header entirely, or that carries the header without a recognisable verification parameter, is still accepted: a well behaved server may send the value in chunked trailers, which the client does not read. An impostor that simply omits the value is therefore still accepted. The two schemes differ on malformed input: SCRAM aborts when the data parameter is present but is not valid base64, whereas Digest treats an unparseable rspauth (an unterminated quote, an empty unquoted value, or a bare rspauth token) as absent and accepts the response. Enforcing presence is tracked as a follow up.\n\nVerification is also skipped when the parameters the client sent cannot be recovered from its own Authorization header, in which case the exchange is delivered rather than failed.\n\n### Details\nIn the auth interceptor, processScramAuthenticationInfo and processAuthenticationInfo computed the verification value and compared it, but did not stop the response from being delivered. Both now abort the exchange when the value is present and does not verify. The Digest expected value must be computed over the parameters actually sent on the wire, which the client recovers from its own Authorization header, because the realm carried on the response future is rebuilt for header emission and does not hold the values that were sent.\n\nNote that 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. Upgrade to 3.0.13 to pick up both fixes.\n\n### Known limitation\n\nThis fix does not cover Digest exchanges negotiated with `qop=\"auth-int\"`. Under auth-int the rspauth signs the response entity-body, which has not been read when the header is processed, so the expected value cannot be derived at that point. The client logs a warning and delivers the response without enforcing mutual authentication.\n\nA peer that controls the challenge can select this deliberately by offering `qop=\"auth-int\"` alone, which switches mutual authentication off for the whole exchange. Offering `auth,auth-int` does not work, because the client prefers auth. Verification under auth-int needs to be deferred until the body has been read, which is tracked separately as GHSA-qhv6-3pmh-95q4.",
"id": "GHSA-fj9w-c36g-h5x8",
"modified": "2026-09-17T17:18:39Z",
"published": "2026-09-17T17:18:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-fj9w-c36g-h5x8"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/pull/2235"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/10b3db9910f0bbad2ea3dc7c7553bae12bc4a5e4"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/685173afea07892462071d966ef6ce5c88cbc66f"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/7fe8700fd5b46c668cee7774624f36b87b9dd32a"
},
{
"type": "PACKAGE",
"url": "https://github.com/AsyncHttpClient/async-http-client"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "AsyncHttpClient doesn\u0027t verify SCRAM and Digest mutual-authentication responses"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.