9.8
/ 10
CRITICAL
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Description
## Summary
I found a bug where curl's Alt-Svc implementation fails to strip sensitive authentication headers (Authorization and Cookies) when remapping a connection to a different host or port. This essentially bypasses the security fix for CVE-2018-1000007.
While auditing the code, I noticed that Alt-Svc remappings in `lib/url.c` update `conn->conn_to_host.name` and `conn->conn_to_port`, but the authentication guard in `lib/vauth/vauth.c` (the `Curl_auth_allowed_to_host` function) only checks the original `conn->host.name` and `conn->remote_port`.
Additionally, Alt-Svc remappings do not set the `data->state.this_is_a_follow` flag. Since the auth guard only activates when this flag is TRUE, the entire credential protection logic is skipped for Alt-Svc "redirects."
## Affected version
curl 8.17.0 (x86_64-pc-linux-gnu) libcurl/8.17.0 OpenSSL/3.5.4
(Tested on Kali Linux, but affects all versions with Alt-Svc enabled)
## Steps To Reproduce
I've attached a reproduction script `final_comparison_poc.py` that demonstrates the issue by comparing a standard 302 redirect (which is secure) against an Alt-Svc remapping (which leaks credentials).
1. Set up a listener on port 8443 (Production) and port 9443 (Attacker).
2. Request `https://localhost:8443/` with credentials and an Alt-Svc header pointing to `localhost:9443`.
3. Make a second request to the same URL using the Alt-Svc cache.
4. Observe that the credentials are sent to port 9443.
## Supporting Material/References
I've verified the code mismatch in the source:
In `lib/vauth/vauth.c`:
```c
return !data->state.this_is_a_follow ||
data->set.allow_auth_to_other_hosts ||
(data->state.first_host &&
curl_strequal(data->state.first_host, conn->host.name) &&
(data->state.first_remote_port == conn->remote_port) ...
```
The fix should involve checking the effective host/port handled by Alt-Svc, similar to the pattern in `url.c:3235`:
```c
const char *check_host = conn->bits.conn_to_host ?
conn->conn_to_host.name : conn->host.name;
int check_port = conn->bits.conn_to_port ?
conn->conn_to_port : conn->remote_port;
```
---
## Impact
## Summary
An attacker controlling an HTTPS server can steal sensitive `Authorization` headers and session `Cookies` from clients by serving a malicious `Alt-Svc` header. Since curl caches Alt-Svc entries, this leak is persistent and will affect future requests to the same origin, even if they would otherwise be secure. This is a direct functional bypass of the security boundary established in CVE-2018-1000007.
I found a bug where curl's Alt-Svc implementation fails to strip sensitive authentication headers (Authorization and Cookies) when remapping a connection to a different host or port. This essentially bypasses the security fix for CVE-2018-1000007.
While auditing the code, I noticed that Alt-Svc remappings in `lib/url.c` update `conn->conn_to_host.name` and `conn->conn_to_port`, but the authentication guard in `lib/vauth/vauth.c` (the `Curl_auth_allowed_to_host` function) only checks the original `conn->host.name` and `conn->remote_port`.
Additionally, Alt-Svc remappings do not set the `data->state.this_is_a_follow` flag. Since the auth guard only activates when this flag is TRUE, the entire credential protection logic is skipped for Alt-Svc "redirects."
## Affected version
curl 8.17.0 (x86_64-pc-linux-gnu) libcurl/8.17.0 OpenSSL/3.5.4
(Tested on Kali Linux, but affects all versions with Alt-Svc enabled)
## Steps To Reproduce
I've attached a reproduction script `final_comparison_poc.py` that demonstrates the issue by comparing a standard 302 redirect (which is secure) against an Alt-Svc remapping (which leaks credentials).
1. Set up a listener on port 8443 (Production) and port 9443 (Attacker).
2. Request `https://localhost:8443/` with credentials and an Alt-Svc header pointing to `localhost:9443`.
3. Make a second request to the same URL using the Alt-Svc cache.
4. Observe that the credentials are sent to port 9443.
## Supporting Material/References
I've verified the code mismatch in the source:
In `lib/vauth/vauth.c`:
```c
return !data->state.this_is_a_follow ||
data->set.allow_auth_to_other_hosts ||
(data->state.first_host &&
curl_strequal(data->state.first_host, conn->host.name) &&
(data->state.first_remote_port == conn->remote_port) ...
```
The fix should involve checking the effective host/port handled by Alt-Svc, similar to the pattern in `url.c:3235`:
```c
const char *check_host = conn->bits.conn_to_host ?
conn->conn_to_host.name : conn->host.name;
int check_port = conn->bits.conn_to_port ?
conn->conn_to_port : conn->remote_port;
```
---
## Impact
## Summary
An attacker controlling an HTTPS server can steal sensitive `Authorization` headers and session `Cookies` from clients by serving a malicious `Alt-Svc` header. Since curl caches Alt-Svc entries, this leak is persistent and will affect future requests to the same origin, even if they would otherwise be secure. This is a direct functional bypass of the security boundary established in CVE-2018-1000007.
Basic Information
ID
H1:3485826
Published
Jan 3, 2026 at 16:31
Modified
Jan 4, 2026 at 10:34