HTTP/1.1 and HTTP/2 redirects resend basic_auth and cookie to a different scheme or port in hackney
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 4.9.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The hackney Erlang HTTP client library is affected. When following redirects, it could resend Basic authentication and cookie credentials to a redirect target that differed only in scheme or port on the same host, such as an HTTPS-to-HTTP downgrade, which exposed those credentials to network eavesdroppers or to a different service on that host.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Insufficiently Protected Credentials vulnerability in hackney in benoitc hackney allows a redirecting server to obtain the basic_auth and cookie credentials of a request via a same-host redirect to another scheme or port. With follow_redirect enabled, hackney:follow_redirect/10 in src/hackney.erl reissues the request to the Location target after hackney:maybe_strip_auth_on_redirect/3, which compared only the hostname of the current and the redirect URL. A redirect from https to http on the same host resent the Authorization and Cookie headers in cleartext, where an on-path attacker can read them, and a redirect to another port on the same host handed them to a different service. location_trusted forwards credentials to any target by design and is unchanged. This issue affects hackney: from 2.0.0 before 4.9.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- hackney
From 2.0.0 · fixed in 4.9.0
- benoitc/hackney
From 8f944559bdb83da60b5c06f6cf6d842591278364 · fixed in 6548384b22ea196023a1963e2967d5715b6d9564