Restic WebDAV HTTPS to HTTP Redirect Credential Leakage

Vulnerability Overview WebDAV Credentials Persist After HTTPS to HTTP Redirect on the Same Host Vulnerability Description: The default redirect handling in WebDAV can replay Basic Authorization and configured Cookie headers over plaintext HTTP following an HTTPS-to-HTTP redirect to the same host. This effectively replays the original backend. Unlike low-impact STS tokens that were mitigated in cloned S3 redirect recommendations, Basic passwords and session cookies are fully reusable credentials, warranting a high severity rating when they grant standard WebDAV read/write access. Trust Boundaries: Requires a legitimate endpoint, gateway, or accelerator to issue an insecure redirect, and an adjacent or non-path-intermediary observer to capture the plaintext. The report must not rely on a malicious original WebDAV endpoint, as the endpoint already possesses the credentials. Scope of Impact Affected Versions: <= v1.74.0 Fixed Versions: v1.75.0 CVSS v3 Base Metrics: - Attack Vector: Adjacent - Attack Complexity: High - Privileges Required: None - User Interaction: None - Scope: Unchanged - Confidentiality: High - Integrity: None - Availability: None CVE ID: No known CVE Weaknesses: - CWE-319 - CWE-522 Remediation 1. Deny all HTTPS to HTTP redirects unless the scheme, hostname, and effective port remain unchanged. 2. By default, forward Authorization requests only if the scheme, hostname, and effective port remain unchanged. 3. Strip Authorization, Cookie, Proxy credentials, and configured Secret headers on all other redirects. 4. Place necessary exceptions behind an allow list of exact destinations. 5. Cover test cases 381, 382, 393, 397, and 398 in regression tests. Technical Root Cause Analysis limits the redirect count and restores the original method, but it does not deny transport downgrades or compare the complete original triplet (scheme, host, port). Consequently, the client relies on Go's header forwarding rules, which are sensitive to redirects. These rules can retain and headers for redirects to the same host, even when the new scheme is plaintext HTTP. Proof of Concept and Evidence 1. Configure an actual WebDAV backend with Basic credentials and a Cookie. 2. Have the TLS endpoint return a 397 Temporary Redirect to an HTTP listener on the same hostname but a different port. 3. The client ( ) follows the redirect while preserving the WebDAV credentials. 4. The plaintext listener receives both the Basic Authorization value and the Cookie. Impact Assessment An observer on the path can reuse captured passwords, bearer tokens, or session cookies to perform allowed WebDAV operations on the account. Confidentiality, Integrity, and Availability impacts depend on the permissions associated with the account. Remediation Guide Deny all HTTPS to HTTP redirects unless the scheme, hostname, and effective port remain unchanged. By default, forward Authorization requests only if the scheme, hostname, and effective port remain unchanged. Strip Authorization, Cookie, Proxy credentials, and configured Secret headers on all other redirects. Place necessary exceptions behind an allow list of exact destinations. Cover test cases 381, 393, 397, and 398 in regression tests. Code Block

Goal Reached Thanks to every supporter — we hit 100%!

Restic WebDAV HTTPS to HTTP Redirect Credential Leakage

More from this source