Vulnerability-Lookup

GHSA-GX4C-2HQX-CW2R

Vulnerability from github – Published: 2026-08-05 20:43 – Updated: 2026-08-05 20:43

Summary

rclone: S3 backend does not strip X-Amz-Security-Token on a same-host HTTPS->HTTP redirect

Details

Vulnerability Details

File: backend/s3/s3.go Lines: 1359-1380 (functions s3CheckRedirect / s3RedirectCrossesHost)

Root Cause

Commit e7b1eb774 (released in v1.74.3) added a CheckRedirect policy for the S3 HTTP client whose purpose is to strip the X-Amz-Security-Token header (the AWS STS session token) whenever a redirect chain "crosses a host", so the token isn't forwarded to an unintended origin.

s3RedirectCrossesHost decides this purely by comparing url.URL.Host (hostname[:port]); it never looks at url.URL.Scheme. A redirect that keeps the exact same host:port but changes the scheme from https:// to http:// therefore compares as "same host" and X-Amz-Security-Token is not stripped — it is sent again, this time over plaintext HTTP.

func s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {
    if len(via) == 0 {
        return false
    }
    host := via[0].URL.Host
    for _, redirect := range via[1:] {
        if redirect.URL.Host != host {
            return true
        }
    }
    return host != req.URL.Host
}

Attack Scenario

The user configures an s3 remote (or --s3-endpoint pointing at a self-hosted/third-party S3-compatible service) using temporary credentials that include an STS session_token (common for assumed-role / CI / Kubernetes IRSA setups).
The configured endpoint responds to a request with a 3xx redirect to the same host:port but with http:// instead of https:// (TLS-front misconfiguration, maintenance redirect, or a malicious/compromised storage provider trying to harvest the token).
rclone's S3 HTTP client follows the redirect and re-sends the request, including X-Amz-Security-Token, over the now-unencrypted connection to that same host.
Any passive observer on that now-plaintext network path can read the STS session token from the request headers.

Impact

Disclosure of the AWS STS session token (X-Amz-Security-Token) in cleartext for the remainder of its validity window. This is the exact class of leak that e7b1eb774 was written to close — it just doesn't cover the scheme-downgrade axis of "crossing a host".

Vulnerable Code

func s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {
    if len(via) == 0 {
        return false
    }
    host := via[0].URL.Host
    for _, redirect := range via[1:] {
        if redirect.URL.Host != host {
            return true
        }
    }
    return host != req.URL.Host
}

Recommended Fix

Also compare URL.Scheme, so a scheme downgrade on the same host is treated the same as a host change:

func s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {
    if len(via) == 0 {
        return false
    }
    scheme, host := via[0].URL.Scheme, via[0].URL.Host
    for _, redirect := range via[1:] {
        if redirect.URL.Host != host || redirect.URL.Scheme != scheme {
            return true
        }
    }
    return host != req.URL.Host || scheme != req.URL.Scheme
}

Verification

Added a unit test (backend/s3/redirect_scheme_test.go) that calls the real, unmodified s3RedirectCrossesHost / s3CheckRedirect with an https://bucket.example.com -> http://bucket.example.com redirect chain.

On unpatched code (commit 16091ce365, current master / v1.74.3): - s3RedirectCrossesHost returns false - s3CheckRedirect leaves X-Amz-Security-Token: SECRET-SESSION-TOKEN intact on the outgoing (plaintext) request.

=== RUN   TestSchemeDowngradeNotDetectedAsCrossHost
    redirect_scheme_test.go:23: initial=https://bucket.example.com final=http://bucket.example.com s3RedirectCrossesHost=false
--- PASS: TestSchemeDowngradeNotDetectedAsCrossHost (0.00s)

After applying the one-line fix above (also adding scheme comparison), the token is correctly stripped and all existing redirect tests (TestClientRemovesSecurityTokenOnCrossHostRedirect, TestClientDoesNotRestoreSecurityTokenAfterCrossHostRedirect, TestClientKeepsSecurityTokenOnSameHostRedirect, TestClientStopsAfterTenRedirects) continue to pass.

A minimal fix commit is ready and can be pushed to a private fork once this report is acknowledged.

Severity

3.1 (Low)


                  
                    CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.74.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rclone/rclone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.74.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-319",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-05T20:43:11Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Vulnerability Details\n\n**File**: `backend/s3/s3.go`\n**Lines**: 1359-1380 (functions `s3CheckRedirect` / `s3RedirectCrossesHost`)\n\n### Root Cause\nCommit `e7b1eb774` (released in v1.74.3) added a `CheckRedirect` policy for\nthe S3 HTTP client whose purpose is to strip the `X-Amz-Security-Token`\nheader (the AWS STS session token) whenever a redirect chain \"crosses a\nhost\", so the token isn\u0027t forwarded to an unintended origin.\n\n`s3RedirectCrossesHost` decides this purely by comparing `url.URL.Host`\n(hostname[:port]); it never looks at `url.URL.Scheme`. A redirect that keeps\nthe exact same host:port but changes the scheme from `https://` to `http://`\ntherefore compares as \"same host\" and `X-Amz-Security-Token` is *not*\nstripped \u2014 it is sent again, this time over plaintext HTTP.\n\n```go\nfunc s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {\n\tif len(via) == 0 {\n\t\treturn false\n\t}\n\thost := via[0].URL.Host\n\tfor _, redirect := range via[1:] {\n\t\tif redirect.URL.Host != host {\n\t\t\treturn true\n\t\t}\n\t}\n\treturn host != req.URL.Host\n}\n```\n\n### Attack Scenario\n1. The user configures an `s3` remote (or `--s3-endpoint` pointing at a\n   self-hosted/third-party S3-compatible service) using temporary\n   credentials that include an STS `session_token` (common for assumed-role\n   / CI / Kubernetes IRSA setups).\n2. The configured endpoint responds to a request with a 3xx redirect to the\n   *same* host:port but with `http://` instead of `https://` (TLS-front\n   misconfiguration, maintenance redirect, or a malicious/compromised\n   storage provider trying to harvest the token).\n3. rclone\u0027s S3 HTTP client follows the redirect and re-sends the request,\n   including `X-Amz-Security-Token`, over the now-unencrypted connection to\n   that same host.\n4. Any passive observer on that now-plaintext network path can read the STS\n   session token from the request headers.\n\n### Impact\nDisclosure of the AWS STS session token (`X-Amz-Security-Token`) in\ncleartext for the remainder of its validity window. This is the exact class\nof leak that `e7b1eb774` was written to close \u2014 it just doesn\u0027t cover the\nscheme-downgrade axis of \"crossing a host\".\n\n### Vulnerable Code\n```go\nfunc s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {\n\tif len(via) == 0 {\n\t\treturn false\n\t}\n\thost := via[0].URL.Host\n\tfor _, redirect := range via[1:] {\n\t\tif redirect.URL.Host != host {\n\t\t\treturn true\n\t\t}\n\t}\n\treturn host != req.URL.Host\n}\n```\n\n### Recommended Fix\nAlso compare `URL.Scheme`, so a scheme downgrade on the same host is treated\nthe same as a host change:\n\n```go\nfunc s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {\n\tif len(via) == 0 {\n\t\treturn false\n\t}\n\tscheme, host := via[0].URL.Scheme, via[0].URL.Host\n\tfor _, redirect := range via[1:] {\n\t\tif redirect.URL.Host != host || redirect.URL.Scheme != scheme {\n\t\t\treturn true\n\t\t}\n\t}\n\treturn host != req.URL.Host || scheme != req.URL.Scheme\n}\n```\n\n### Verification\nAdded a unit test (`backend/s3/redirect_scheme_test.go`) that calls the real,\nunmodified `s3RedirectCrossesHost` / `s3CheckRedirect` with an\n`https://bucket.example.com` -\u003e `http://bucket.example.com` redirect chain.\n\nOn unpatched code (commit 16091ce365, current master / v1.74.3):\n- `s3RedirectCrossesHost` returns `false`\n- `s3CheckRedirect` leaves `X-Amz-Security-Token: SECRET-SESSION-TOKEN`\n  intact on the outgoing (plaintext) request.\n\n```\n=== RUN   TestSchemeDowngradeNotDetectedAsCrossHost\n    redirect_scheme_test.go:23: initial=https://bucket.example.com final=http://bucket.example.com s3RedirectCrossesHost=false\n--- PASS: TestSchemeDowngradeNotDetectedAsCrossHost (0.00s)\n```\n\nAfter applying the one-line fix above (also adding scheme comparison), the\ntoken is correctly stripped and all existing redirect tests\n(`TestClientRemovesSecurityTokenOnCrossHostRedirect`,\n`TestClientDoesNotRestoreSecurityTokenAfterCrossHostRedirect`,\n`TestClientKeepsSecurityTokenOnSameHostRedirect`,\n`TestClientStopsAfterTenRedirects`) continue to pass.\n\nA minimal fix commit is ready and can be pushed to a private fork once this\nreport is acknowledged.",
  "id": "GHSA-gx4c-2hqx-cw2r",
  "modified": "2026-08-05T20:43:11Z",
  "published": "2026-08-05T20:43:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/security/advisories/GHSA-gx4c-2hqx-cw2r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/1a28451ea6fc8ac1806b0e9923dcb5b3f543f7fa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rclone/rclone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/releases/tag/v1.74.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "rclone: S3 backend does not strip X-Amz-Security-Token on a same-host HTTPS-\u003eHTTP redirect"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.