GHSA-h4mf-4v27-hggj: Medium severity go/github.com/rclone/rclone vulnerability

Published Aug 5, 2026
·
Updated

1. Summary

WebDAV's default redirect handling can replay Basic authorization and configured Cookie headers over plaintext HTTP after a same-host HTTPS-to-HTTP redirect. This was reproduced through the real backend. Unlike the low-impact STS token in rclone's published S3 redirect advisory, Basic passwords and session cookies are complete reusable credentials, supporting a High rating when they grant normal WebDAV read/write access.

The credible threat requires a legitimate endpoint, gateway, or accelerator to emit an unsafe redirect and an adjacent/on-path actor to observe the plaintext hop. A report should not rely on a malicious original WebDAV endpoint because that endpoint already receives the credentials.

2. Affected Assets & Attack Surface

- Backend configuration/authentication: backend/webdav/webdav.go:127-139, 170-206, 440-530 - Shared redirect callback: lib/rest/rest.go:218-231 - HTTP client: fs/fshttp/http.go:311-329 - Credentials: Basic passwords, bearer authorization, SharePoint/session cookies, and configured secret headers - Confirmed affected version: <= v1.74.0-240

3. Technical Root Cause Analysis

PreserveMethodRedirectFn limits redirect count and restores the original method, but it does not reject a transport downgrade or compare the full origin tuple. The client therefore relies on Go's hostname-oriented sensitive-header forwarding rules. Those rules can preserve Authorization and Cookie on a same-host redirect even when the new scheme is plaintext HTTP.

4. Proof-of-Concept & Evidence

1. Configure the actual WebDAV backend with Basic credentials and a Cookie. 2. Have the TLS endpoint return 307 Temporary Redirect to an HTTP listener on the same hostname and a different port. 3. rclone follows the redirect while preserving the WebDAV method. 4. The plaintext listener receives both the Basic Authorization value and Cookie.

5. Impact Assessment

An on-path observer can reuse the captured password, bearer token, or session cookie for the account's permitted WebDAV operations. Confidentiality, integrity, and availability impact depend on that account's permissions.

6. Remediation Guidance

- Reject every HTTPS-to-HTTP redirect before replay. - Forward authenticated requests by default only when scheme, hostname, and effective port are unchanged. - Strip authorization, cookies, proxy credentials, and configured secret headers on all other redirects. - Put necessary provider exceptions behind exact destination allowlists. - Cover 301, 302, 303, 307, and 308 in regression tests.

Affected Software

1 affected componentFixes available
go/github.com/rclone/rclone<=1.74.0
1.75.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/github.com/rclone/rclone to a version that resolves this vulnerability.

    Fixed in 1.75.0
  2. Configuration

    Ensure authenticated requests are forwarded by default only when the redirect does not change the scheme, hostname, and effective port (backend/webdav/webdav.go:127-139, 170-206, 440-530).

    WebDAV redirect handling (backend/webdav/webdav.go) ForwardAuthenticatedRequests by default = only when scheme, hostname, and effective port are unchanged
  3. Configuration

    Reject every HTTPS-to-HTTP redirect before replaying the request (lib/rest/rest.go:218-231; also covers shared redirect callback behavior).

    HTTP redirect handling (shared redirect callback lib/rest/rest.go) HTTPS-to-HTTP redirect policy = reject all HTTPS-to-HTTP redirects before replay
  4. Configuration

    On redirects other than the explicitly safe case, strip Authorization, cookies, proxy credentials, and configured secret headers before replay (fs/fshttp/http.go:311-329; shared callback lib/rest/rest.go:218-231).

    HTTP client (fs/fshttp/http.go) Authorization/Cookie forwarding on other redirects = strip on all other redirects
  5. Configuration

    Put necessary provider exceptions behind exact destination allowlists, rather than allowing broad authenticated forwarding (backend/webdav/webdav.go:127-139, 170-206, 440-530).

    WebDAV redirect handling (backend/webdav/webdav.go) Authenticated redirect allowlisting = provider exceptions behind exact destination allowlists
  6. Compensating control

    Configure the actual WebDAV backend to require Basic credentials and cookies on the legitimate TLS endpoint, and ensure the TLS endpoint returns 307 Temporary Redirect to an HTTP listener on the same hostname but a different port only if you can prevent replay of Authorization/Cookie across the redirect (as described: TLS endpoint -> 307 to HTTP listener on same hostname, different port).

  7. Operational

    Run regression tests to cover HTTP status codes 301, 302, 303, 307, and 308 for redirect behavior, ensuring the redirect handling does not preserve Authorization/Cookie across unsafe redirects.

Event History

Aug 5, 2026
Advisory Published
via GitHub·08:36 PM
Data Sourced
via GitHub·08:36 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203