GHSA-f8m2-889x-vw4x

### 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.