oras-go CVE-2026-50151
HIGH
GHSA-jxpm-75mh-9fp7
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
AC:H because the attacker must control or MITM the registry the client uploads to; PR:N/UI:N as no victim privilege or interaction beyond a normal push; C:H for credential leak, I/A:N.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Lifecycle Timeline
2DescriptionGitHub Advisory
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 controlRecommended Fix
- validate
Locationbefore uploading (scheme + hostname + effective port) against the original request, or require an explicit opt-in allowlist for cross-host upload urls - never forward
Authorizationwhen 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(seeblobStore.completePushAfterInitialPost)
AnalysisAI
Credential leakage in oras-go v2 (oras.land/oras-go) lets a malicious or compromised OCI registry steal a client's Authorization credentials by returning a cross-host Location header during monolithic blob upload; oras-go follows the redirect and reuses the original bearer/basic credentials on the PUT to the attacker-controlled host, also yielding client-side SSRF to an arbitrary cross-host target. Any Go application that pushes artifacts using oras-go v2.6.0 (and likely earlier v2.x) is affected. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires the victim's oras-go v2 client to perform a monolithic blob upload (push) where the responding registry is attacker-controlled, compromised, or on-path (MITM), because the malicious Location header returned to the POST is the exploitation primitive. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The signals are moderately but not uniformly high. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker stands up (or compromises, or MITMs) an OCI registry and waits for a victim tool built on oras-go to push an artifact; the registry accepts the initial POST and returns a Location header pointing at an attacker-controlled host. oras-go follows that cross-host URL and replays the caller's Authorization credentials on the PUT, delivering the bearer/basic token - and the blob payload - to the attacker, who can then reuse the token against the legitimate registry. … |
| Remediation | Vendor-released patch: v2.6.1 - upgrade the oras.land/oras-go/v2 dependency to v2.6.1 or later (go get oras.land/oras-go/v2@v2.6.1 and rebuild), per GHSA-jxpm-75mh-9fp7, PR https://github.com/oras-project/oras-go/pull/1152, and commit https://github.com/oras-project/oras-go/commit/4683c46ef078091544f5f55fd25102f002806991. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: Identify all services and applications using oras-go v2.6.0 or earlier versions. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
The x86-64 kernel system-call functionality in Xen 4.1.2 and earlier, as used in Citrix XenServer 6.0.2 and earlier and
An authenticated path traversal vulnerability in Langflow's file upload functionality allows attackers to write arbitrar
Canonical snapd before version 2.37.1 incorrectly performed socket owner validation, allowing an attacker to run arbitra
An authorization bypass vulnerability in gRPC-Go allows attackers to circumvent path-based access control by sending HTT
Arbitrary file read in Langroid's SQLChatAgent (<= 0.63.0) lets an attacker who can influence the LLM-generated SQL exfi
An issue was discovered in the jsrsasign package through 8.0.18 for Node.js. Rated high severity (CVSS 7.5), this vulner
The Elliptic package 6.5.2 for Node.js allows ECDSA signature malleability via variations in encoding, leading '\0' byte
Resource exhaustion in OpenTelemetry Go propagation library (v1.41.0 and earlier) enables remote attackers to trigger se
A vulnerability in the seccomp filters of Canonical snapd before version 2.37.4 allows a strict mode snap to insert char
The Linux kernel before 3.15.4 on Intel processors does not properly restrict use of a non-canonical value for the saved
concrete5 8.1.0 places incorrect trust in the HTTP Host header during caching, if the administrator did not define a "ca
Timestamp forgery in sigstore-js allows an attacker supplying a crafted bundle v0.2 to manipulate certificate validity w
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today