Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.8
Hubuum Client Library (Rust): Unauthorized Access via Redirects
published 3 months ago
Summary
If an attacker can influence a redirect from a Hubuum endpoint, they may be able to access sensitive data outside the intended path. To fix this, update to version 0.6.1 or configure your client to not follow redirects. You can also reduce exposure by keeping the Hubuum origin separate from other applications and trusted infrastructure.
What to do
- Update terjekv hubuum_client to version 0.6.1.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| crates.io | terjekv | hubuum_client |
>= 0.0.1, < 0.6.1 Fix: upgrade to 0.6.1
|
Original advisory text
Hubuum client library (Rust): Authenticated requests may escape the configured base path through redirects
## Impact
The built-in async and blocking clients used reqwest's default redirect policy. `BaseUrl` constrains the initial request to the configured origin and path prefix, but redirect processing occurs after that validation. reqwest retains sensitive headers when a redirect changes only the path on the same scheme, host, and port. A redirect from a Hubuum endpoint to another path on a shared origin could therefore carry the bearer `Authorization` header outside the configured Hubuum path prefix.
Exploitation requires an attacker, compromised server, or intermediary to influence a 3xx response. Cross-origin redirects are not affected because reqwest strips sensitive headers when scheme, host, or port changes.
## Patches
Version 0.6.1 configures both built-in HTTP clients with `reqwest::redirect::Policy::none()`. Redirect responses are returned as 3xx API errors instead of being followed. Supplying a preconfigured reqwest client remains an explicit opt-in to that client's redirect policy.
## Workarounds
On affected versions, construct a reqwest client with `reqwest::redirect::Policy::none()` and pass it through `with_http_client`. Deployments can also reduce exposure by ensuring the Hubuum origin is not shared with other applications and that trusted infrastructure never redirects API requests outside the configured path prefix.
The built-in async and blocking clients used reqwest's default redirect policy. `BaseUrl` constrains the initial request to the configured origin and path prefix, but redirect processing occurs after that validation. reqwest retains sensitive headers when a redirect changes only the path on the same scheme, host, and port. A redirect from a Hubuum endpoint to another path on a shared origin could therefore carry the bearer `Authorization` header outside the configured Hubuum path prefix.
Exploitation requires an attacker, compromised server, or intermediary to influence a 3xx response. Cross-origin redirects are not affected because reqwest strips sensitive headers when scheme, host, or port changes.
## Patches
Version 0.6.1 configures both built-in HTTP clients with `reqwest::redirect::Policy::none()`. Redirect responses are returned as 3xx API errors instead of being followed. Supplying a preconfigured reqwest client remains an explicit opt-in to that client's redirect policy.
## Workarounds
On affected versions, construct a reqwest client with `reqwest::redirect::Policy::none()` and pass it through `with_http_client`. Deployments can also reduce exposure by ensuring the Hubuum origin is not shared with other applications and that trusted infrastructure never redirects API requests outside the configured path prefix.
Internet-facing
60 days
Internal
At next upgrade
- Not known to be exploited
- Needs hands-on effort to exploit (estimated)
- Gives an attacker partial control (estimated)
Type
CWE-200Information Exposure
Timeline
Published24 Jul 2026
Updated24 Jul 2026
First seen24 Jul 2026
Sources
GHSA-f45q-w629-wr25 · OSV
Track software like this
Free during beta