CVE-2026-85716: AsyncHttpClient: SCRAM and Digest mutual-authentication responses are not verified

Published Sep 17, 2026
·
Updated

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 3.0.8 until 3.0.12, processScramAuthenticationInfo and processAuthenticationInfo compute the SCRAM ServerSignature or Digest rspauth verification result but log a mismatch and still deliver the response as authenticated. On a non-TLS or compromised transport, a peer that has not proved knowledge of the shared secret can therefore be accepted as the server. The fix rejects a present invalid value and computes Digest rspauth from the Authorization parameters actually sent, but verification remains unenforced when the value is absent, the sent parameters cannot be recovered, or Digest uses qop=auth-int. This issue is fixed in version 3.0.12.

Affected Software

2 affected components
AsyncHttpClient>=3.0.8<3.0.12
AsyncHttpClient=3.0.12

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade AsyncHttpClient to a version that resolves this vulnerability.

    Fixed in 3.0.12

Event History

Sep 17, 2026
CVE Published
via MITRE·04:23 PM
Data Sourced
via MITRE·04:23 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are realistically exposed?

Java applications using AsyncHttpClient releases from 3.0.8 until the 3.0.12 fix are exposed when they use SCRAM or Digest mutual-authentication and communicate over a non-TLS or compromised transport.

2

What does an attacker need to exploit this?

The attacker must be able to act as or interfere with the peer on the transport and provide a mutual-authentication response without proving knowledge of the shared secret. The vulnerable client logs a SCRAM ServerSignature or Digest rspauth mismatch but still treats the response as authenticated.

3

What should teams do if they use an affected release?

Upgrade to AsyncHttpClient 3.0.12. Until then, avoid non-TLS transport and treat the server-authentication result from affected SCRAM and Digest exchanges as unreliable.

4

Does version 3.0.12 enforce verification in every case?

No. Verification remains unenforced when the authentication value is absent, when the sent Digest Authorization parameters cannot be recovered, or when Digest uses qop=auth-int.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203