AsyncHttpClient re-sends client-wide realm credentials to a cross-origin redirect target

Impact

A client configured with a client-wide realm (a Realm set on the config builder rather than on an individual request) and following redirects could re-send those credentials to a redirect target on a different origin. The redirect code strips the per-exchange realm, but when the target answered 401 the credentials were re-derived from the client config, handing Basic or Digest credentials, or a Negotiate or NTLM token, to an attacker controlled origin. This is a residual of the earlier cross-origin credential leak advisories, whose strip this bypassed.

Affected versions

• 3.x: 3.0.9 through 3.0.11
• 2.x: 2.14.5 through 2.16.0

Releases below those floors are covered by the earlier advisories GHSA-cmxv-58fp-fm3g and GHSA-fmxf-pm6p-7xgm: the cross-origin strip that this issue bypasses did not exist yet, so the leak there is the original one rather than this residual.

Patches

Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The realm is taken from the per-exchange state that the redirect already cleared, rather than being re-derived from the client configuration.

Workarounds

Set the Realm on the individual request instead of on the client configuration. A per-request realm is stripped correctly on a cross-origin redirect while still authenticating same-origin, so this is a complete workaround with no loss of function. Turning off follow-redirects also avoids it. Note that setStripAuthorizationOnRedirect(true) is not a workaround: it forces the strip, but the configuration fallback re-derived the realm regardless.

Details

The interceptor read the realm as the request's realm or, failing that, the client configuration's realm, which re-attached the config realm after the redirect strip had cleared it. It now reads the realm held on the response future. See also GHSA-cmxv-58fp-fm3g and GHSA-fmxf-pm6p-7xgm.