GHSA-8MXV-9XHP-86H4

Vulnerability from github – Published: 2026-08-05 20:27 – Updated: 2026-08-05 20:27
VLAI
Summary
rclone: S3 Redirect Sanitization Omits IBM IAM Bearer Tokens and SSE-C Keys
Details

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:

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 separate redirect to an unrelated hostname caused Go to remove Authorization, but the destination still received both SSE-C key headers.
  4. In both cases, rclone removed the planted STS token, proving that the S3-specific callback executed while omitting the other secret classes.

The related GHSA-gx4c-2hqx-cw2r covers the STS downgrade path and confirms that rclone treats scheme changes as a credential boundary. It does not cover the IBM bearer or SSE-C variants retained here.

5. Impact Assessment

A captured IBM bearer token can authorize reads, writes, and deletes within its IAM scope. A disclosed SSE-C key can expose corresponding ciphertext available to the recipient; copy-source keys can expose protected source objects. The exact impact is limited by token policy and the attacker's access to encrypted objects.

6. Remediation Guidance

  • Reject every HTTPS-to-HTTP redirect before replay.
  • Do not automatically follow secret-bearing cross-origin redirects.
  • On any scheme, host, or effective-port change, remove all authorization, cookies, session tokens, SSE-C fields, copy-source SSE-C fields, and provider-specific credentials.
  • Where redirects are required, allowlist exact destinations and reconstruct/re-sign a new request.
  • Add redirect tests for every secret header class and for scheme, hostname, subdomain, and port changes.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.74.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rclone/rclone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.75.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-319",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-05T20:27:50Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## 1. Summary\n\nThe 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:\n\n- a same-host HTTPS-to-HTTP redirect preserves `Authorization: Bearer ...` and exposes a reusable IBM IAM token to the plaintext network path;\n- a cross-origin redirect preserves SSE-C and copy-source SSE-C key headers.\n\nThe 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.\n\n## 2. Affected Assets \u0026 Attack Surface\n\n- S3 redirect policy: `backend/s3/s3.go:1345-1379`\n- IBM IAM signer: `backend/s3/ibm_signer.go:28-40`\n- SSE-C key preparation: `backend/s3/s3.go:1821-1837`\n- Affected operations: requests carrying IBM IAM authorization, SSE-C keys, or copy-source SSE-C keys\n- Confirmed affected version: `\u003c= v1.74.0-240-ga0c09f138`\n\n## 3. Technical Root Cause Analysis\n\n`s3CheckRedirect` applies a one-header denylist:\n\n```go\nif s3RedirectCrossesHost(req, via) {\n    req.Header.Del(\"X-Amz-Security-Token\")\n}\n```\n\nGo 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.\n\n## 4. Proof-of-Concept \u0026 Evidence\n\nUsing the actual redirect callback:\n\n1. An HTTPS endpoint redirected to HTTP on the same hostname.\n2. The plaintext destination received the planted IBM bearer token and SSE-C headers.\n3. A separate redirect to an unrelated hostname caused Go to remove `Authorization`, but the destination still received both SSE-C key headers.\n4. In both cases, rclone removed the planted STS token, proving that the S3-specific callback executed while omitting the other secret classes.\n\nThe related [GHSA-gx4c-2hqx-cw2r](https://github.com/rclone/rclone/security/advisories/GHSA-gx4c-2hqx-cw2r) covers the STS downgrade path and confirms that rclone treats scheme changes as a credential boundary. It does not cover the IBM bearer or SSE-C variants retained here.\n\n## 5. Impact Assessment\n\nA captured IBM bearer token can authorize reads, writes, and deletes within its IAM scope. A disclosed SSE-C key can expose corresponding ciphertext available to the recipient; copy-source keys can expose protected source objects. The exact impact is limited by token policy and the attacker\u0027s access to encrypted objects.\n\n## 6. Remediation Guidance\n\n- Reject every HTTPS-to-HTTP redirect before replay.\n- Do not automatically follow secret-bearing cross-origin redirects.\n- On any scheme, host, or effective-port change, remove all authorization, cookies, session tokens, SSE-C fields, copy-source SSE-C fields, and provider-specific credentials.\n- Where redirects are required, allowlist exact destinations and reconstruct/re-sign a new request.\n- Add redirect tests for every secret header class and for scheme, hostname, subdomain, and port changes.",
  "id": "GHSA-8mxv-9xhp-86h4",
  "modified": "2026-08-05T20:27:50Z",
  "published": "2026-08-05T20:27:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/security/advisories/GHSA-8mxv-9xhp-86h4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/7543a7a87884aca957590b20b0714078d51af87b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/9328763d1b73db71e97c0332b19e3747abeb9191"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rclone/rclone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/releases/tag/v1.75.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "rclone: S3 Redirect Sanitization Omits IBM IAM Bearer Tokens and SSE-C Keys"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…