| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| github.com/rclone/rclone | ≥ 1.49.0, < 1.75.1 | 1.75.1 |
| rclone | ≥ 1.49.0, < 1.75.1 | 1.75.1 |
File: backend/http/http.go
Lines: 285 (client construction — no CheckRedirect), 505-510 (addHeaders, writes configured secret headers onto every request), 533-534 / 700-701 / 782-785 (f.httpClient.Do(req) used by List/stat/download)
The http backend lets a user attach arbitrary secret headers to every request via --http-headers/headers= (documented for authentication: '"Cookie","name=value","Authorization","xxx"'). The backend's HTTP client is built with fshttp.NewClient(ctx), which never sets http.Client.CheckRedirect, so it falls back to Go's stdlib default redirect policy.
Go's default policy only strips four header names (Authorization, Www-Authenticate, Cookie, Cookie2), and only when the redirect target's host differs from the original — every other configured header is copied to the redirect target unconditionally, regardless of host or scheme. Even the four protected names survive a same-host https:// → http:// downgrade, since Go only checks host equality, not scheme.
Any redirect response from the configured remote — whether from server compromise, an open redirect, a CDN/mirror failover to a different domain, or a malicious server from the start — causes rclone to resend every configured secret header (and, for a scheme downgrade, Authorization/Cookie in cleartext) to the new destination.
This is the exact vulnerability class already fixed for the s3 backend (9328763/7543a7a, GHSA-8mxv-9xhp-86h4 and the webdav backend (59b513b, GHSA-h4mf-4v27-hggj, wiring rest.RefuseHTTPSDowngradeRedirectFn). backend/http was not touched by either fix.
// backend/http/http.go:285
client := fshttp.NewClient(ctx) // no CheckRedirect set
...
f.httpClient = client // used by readDir / NewObject / Object.Open
// backend/http/http.go:505-510
func addHeaders(req *http.Request, opt *Options) {
for i := 0; i < len(opt.Headers); i += 2 {
key := opt.Headers[i]
value := opt.Headers[i+1]
req.Header.Add(key, value)
}
}
これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャンhttpurl=https://good.example.com/files/headers=X-Api-Key,SECRET-TOKENgood.example.com returns a redirect whose Location points at a different host (compromise, open redirect, CDN change, or malice from the start).ls, cat, copy, mount, serve) against the remote.X-Api-Key: SECRET-TOKEN to the new, untrusted destination.Exfiltration of API keys / bearer tokens / session cookies configured for one host, to any host the (trusted-at-configuration-time) remote later redirects to. All operations on the http backend (list, stat, download, mount, serve) are affected. No special rclone privileges or unusual user interaction are needed beyond a normal sync/list/copy once the redirect exists.
Built rclone from source at cfdc9d0 (current master, v1.76.0-DEV) and configured:
[testhttp]
type = http
url = http://127.0.0.1:9090/
headers = X-Api-Key,SUPER-SECRET-TOKEN-abc123
Server A (port 9090, the "configured" host) 302-redirects every request to Server B (port 9091, a different host). Running rclone cat testhttp:file.txt caused Server B — which was never configured with any credential — to receive:
Header: X-Api-Key: SUPER-SECRET-TOKEN-abc123
Header: Referer: http://127.0.0.1:9090/file.txt
rclone printed Server B's response body as if it were the real file, confirming the full stat→redirect→download round trip leaks the header and trusts the redirect target.
A minimal fix (implemented, tested, and verified to close the leak while preserving redirect functionality) wires the client to rest.RefuseHTTPSDowngradeRedirectFn (already used by webdav) and strips the configured opt.Headers on any cross-host redirect:
client := fshttp.NewClient(ctx)
client.CheckRedirect = redirectCheckFn(opt)
...
func redirectCheckFn(opt *Options) func(req *http.Request, via []*http.Request) error {
return func(req *http.Request, via []*http.Request) error {
if err := rest.RefuseHTTPSDowngradeRedirectFn(req, via); err != nil {
return err
}
if len(via) > 0 && req.URL.Host != via[0].URL.Host {
for i := 0; i < len(opt.Headers); i += 2 {
req.Header.Del(opt.Headers[i])
}
}
return nil
}
}
A regression test (TestRedirectStripsHeadersOnHostChange) was added to backend/http/http_internal_test.go, confirmed to fail without the fix and pass with it. Full backend/http and lib/rest test suites pass with the fix applied. I have a fix branch ready to push to a private fork once this report is acknowledged.
Dynamically confirmed on rclone master @ cfdc9d0 (post v1.75.0) in a local test harness — see "Dynamic Confirmation" above. Fix verified to eliminate the leak via the same harness (secret header absent from Server B after the fix; functionality — file download via redirect — unaffected).