GHSA-8mxv-9xhp-86h4

## 1. Summary The S3 redirect callback strips `X-Amz-Security-Token` when a redirect changes scheme or host, but it does not strip IBM IAM bearer authorization or customer-provided encryption keys. Two independently validated paths remain: - a same-host HTTPS-to-HTTP redirect preserves `Authorization: Bearer ...` and exposes a reusable IBM IAM token to the plaintext network path; - a cross-origin redirect preserves SSE-C and copy-source SSE-C key headers. The High rating is driven by the reusable IBM IAM bearer token. The SSE-C cross-origin disclosure is a secondary confidentiality issue. The meaningful threat is a trusted endpoint, gateway, or accelerator that emits an unsafe redirect, followed by an adjacent/on-path observer; describing the originally configured endpoint itself as the attacker would be weak because that endpoint already receives the request secrets. ## 2. Affected Assets & Attack Surface - S3 redirect policy: `backend/s3/s3.go:1345-1379` - IBM IAM signer: `backend/s3/ibm_signer.go:28-40` - SSE-C key preparation: `backend/s3/s3.go:1821-1837` - Affected operations: requests carrying IBM IAM authorization, SSE-C keys, or copy-source SSE-C keys - Confirmed affected version: `<= v1.74.0-240-ga0c09f138` ## 3. Technical Root Cause Analysis `s3CheckRedirect` applies a one-header denylist: ```go if s3RedirectCrossesHost(req, via) { req.Header.Del("X-Amz-Security-Token") } ``` Go removes `Authorization` on some hostname changes, but preserves it for a same-host redirect and does not treat a scheme downgrade as sufficient reason to remove it. Go also has no generic knowledge that the SSE-C headers contain raw encryption keys. The rclone callback recognizes the STS token but not these additional origin-bound secrets. ## 4. Proof-of-Concept & Evidence Using the actual redirect callback: 1. An HTTPS endpoint redirected to HTTP on the same hostname. 2. The plaintext destination received the planted IBM bearer token and SSE-C headers. 3. A separat