Most recent entries from all

BIT-rclone-2026-88013 — rclone: http backend forwards custom/auth headers to a different host on redirect

Affected: Bitnami: rclone

rclone is a command-line program to sync files and directories to and from different cloud storage providers. From 1.49.0 until 1.75.1, the HTTP backend attaches headers configured through --http-headers or headers= to requests in backend/http/http.go, while its fshttp.NewClient client follows redirects without a backend-specific http.Client.CheckRedirect policy. A configured remote that redirects to another host can therefore cause custom secrets such as X-Api-Key to be resent to that untrusted destination, and a same-host HTTPS-to-HTTP redirect can expose Authorization or Cookie headers in cleartext. Listing, stat, download, mount, and serve operations can trigger the leak during normal use. This issue is fixed in version 1.75.1.

EUVD-2026-366467

fkie_cve-2026-88013

GHSA-486v-q2wf-fp2r — rclone: http backend forwards custom/auth headers to a different host on redirect

Affected: Go: github.com/rclone/rclone

## Vulnerability Details

**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)

### Root Cause 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`/`75…

UBUNTU-CVE-2026-88013

Affected: Ubuntu:18.04:LTS: rclone, Ubuntu:Pro:20.04:LTS: rclone, Ubuntu:Pro:22.04:LTS: rclone, Ubuntu:Pro:24.04:LTS: rclone, Ubuntu:Pro:26.04:LTS: rclone