GHSA-JXPM-75MH-9FP7

Vulnerability from github – Published: 2026-07-01 21:35 – Updated: 2026-07-01 21:35
VLAI
Summary
oras-go blob upload vulnerable to credential forwarding via unvalidated Location header
Details

Summary

oras-go follows a registry-controlled Location header during the monolithic blob upload flow and reuses the Authorization header from the initial POST request for the subsequent PUT request. If a malicious registry returns a cross-host Location, oras-go can send the caller's credentials to an attacker-controlled endpoint.

Affected Versions

tested: v2.6.0 (commit 03243809936cce826494b5506f724c6dc11115b1, as-of 2026-01-24) range: unknown; likely affects earlier v2.x releases that include the same upload flow

Impact

Credential leak to an attacker-controlled endpoint and client-side ssrf to a cross-host target.

Affected Component

  • registry/remote/repository.go:878-916 (blobStore.completePushAfterInitialPost)

Reproduction

Attachments include poc.zip with a local-only harness (no real registry required). It runs a fake registry server that returns a cross-host Location and a second server that records whether it received Authorization.

unzip -q -o poc.zip -d /tmp/poc
cd /tmp/poc/poc-F-ORAS-LOCATION-UPLOAD-001
make canonical
make control

Recommended Fix

  • validate Location before uploading (scheme + hostname + effective port) against the original request, or require an explicit opt-in allowlist for cross-host upload urls
  • never forward Authorization when the upload target changes host or scheme

references

  • security policy: https://github.com/oras-project/oras-go/security/policy
  • vulnerable code: registry/remote/repository.go (see blobStore.completePushAfterInitialPost)
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "oras.land/oras-go/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T21:35:45Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\noras-go follows a registry-controlled `Location` header during the monolithic blob upload flow and reuses the `Authorization` header from the initial `POST` request for the subsequent `PUT` request. If a malicious registry returns a cross-host `Location`, oras-go can send the caller\u0027s credentials to an attacker-controlled endpoint.\n\n## Affected Versions\n\ntested: v2.6.0 (commit 03243809936cce826494b5506f724c6dc11115b1, as-of 2026-01-24)\nrange: unknown; likely affects earlier v2.x releases that include the same upload flow\n\n## Impact\n\nCredential leak to an attacker-controlled endpoint and client-side ssrf to a cross-host target.\n\n## Affected Component\n\n- `registry/remote/repository.go:878-916` (`blobStore.completePushAfterInitialPost`)\n\n## Reproduction\n\nAttachments include `poc.zip` with a local-only harness (no real registry required). It runs a fake registry server that returns a cross-host `Location` and a second server that records whether it received `Authorization`.\n\n```bash\nunzip -q -o poc.zip -d /tmp/poc\ncd /tmp/poc/poc-F-ORAS-LOCATION-UPLOAD-001\nmake canonical\nmake control\n```\n\n## Recommended Fix\n\n- validate `Location` before uploading (scheme + hostname + effective port) against the original request, or require an explicit opt-in allowlist for cross-host upload urls\n- never forward `Authorization` when the upload target changes host or scheme\n\n## references\n\n- security policy: https://github.com/oras-project/oras-go/security/policy\n- vulnerable code: `registry/remote/repository.go` (see `blobStore.completePushAfterInitialPost`)",
  "id": "GHSA-jxpm-75mh-9fp7",
  "modified": "2026-07-01T21:35:45Z",
  "published": "2026-07-01T21:35:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oras-project/oras-go/security/advisories/GHSA-jxpm-75mh-9fp7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oras-project/oras-go/pull/1152"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oras-project/oras-go/commit/4683c46ef078091544f5f55fd25102f002806991"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oras-project/oras-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oras-project/oras-go/releases/tag/v2.6.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "oras-go blob upload vulnerable to credential forwarding via unvalidated Location header"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.



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.