Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
oras-go's pagination helper parseLink() in registry/remote/utils.go follows the Link response header from a registry without validating the URL's host or scheme. When a malicious registry returns a Link header containing an absolute URL pointing to an arbitrary host (e.g., a cloud metadata endpoint), the client makes GET requests to that host from the victim's network. This affects all pagination-based listing operations: Tags, Referrers, and Repositories (catalog). Root Cause parseLink() at registry/remote/utils.go:54 calls resp.Request.URL.Parse(link) which, for absolute URLs, returns the absolute URL unchanged. The result is passed directly to the next pagination loop iteration where http.NewRequestWithContext() creates a GET request to the attacker-specified URL. No host comparison, scheme validation, or IP filtering exists between parseLink output and the HTTP request. Affected Code Paths - registry/remote/repository.go:Tags() calls parseLink() for next page URL -…
Recommended action: Upgrade to 2.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The content/file.Store in oras-go v2 unpacks OCI layer tarballs when a descriptor carries io.deis.oras.content.unpack=true. The extraction routine validates symlink targets purely lexically (filepath.Join) and, for regular files placed directly at the extraction root, skips the parent-symlink Lstat walk. A malicious tarball can plant a chain of symlinks whose lexical target stays inside the extraction root but whose kernel-resolved target is any absolute path, then write through it with a follow-up regular-file entry. The result is arbitrary file create/overwrite outside the store's working directory under the default AllowPathTraversalOnWrite=false configuration — a canonical tar-slip → RCE primitive. Details Affected versions: <= v2.6.1 Entry point: content/file/file.go line 486, (Store).pushDir — reached from (Store).Push for any descriptor whose annotations include io.deis.oras.content.unpack: "true" (i.e. file.AnnotationUnpack) and an org.opencontainers.image.title.…
Recommended action: Upgrade to 2.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ORAS Go forwards registry credentials across registry redirects Reporter / public credit: JUNYI LIU Summary ORAS Go can forward registry credentials configured for one registry origin to a different HTTP origin during registry redirects. There are two related paths: 1. A manifest or metadata request authenticates to the origin registry, then the origin returns a redirect to another host or port. The redirected request can carry the origin Authorization header to the redirect target. 2. A blob upload POST authenticates to the origin registry, then the origin returns an upload Location on another host or port. The follow-up PUT can carry the origin Authorization header to the Location target. The upload Location issue appears related to the existing public fix in pull request #1152 / GHSA-jxpm-75mh-9fp7. The manifest redirect path is a residual adjacent route: the v2 branch after the upload Location fix still forwards Basic credentials on an authenticated manifest redirect. Impact A…
Recommended action: Upgrade to 2.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Root cause The tar-extraction helper ensureLinkPath at content/file/utils.go:262-275 validates that a hardlink's target resolves inside the extract base, but then returns the original unresolved target string back to the caller: The caller for TypeLink hardlinks then does: os.Link(oldname, newname) wraps the link(2) system call. From the link(2) man page: oldpath and newpath are interpreted relative to the current working directory of the calling process. So when target (i.e., header.Linkname) is a relative path, os.Link resolves it against the process's current working directory, not against filepath.Dir(link) as the validation assumed. Attack An attacker who controls an OCI-compliant registry (or any artifact source the victim consumes via oras pull) crafts a tarball layer with: - A regular file: payload.tar.gz/README.txt. - A hardlink entry: Typeflag=TypeLink, Name=payload.tar.gz/evilcwdlink, Linkname="victim.secret" (relative). and marks the layer descriptor with…
Recommended action: Upgrade to 2.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The file content store in oras-go attempts to confine writes to workingDir when AllowPathTraversalOnWrite=false, but the guard is lexical and does not account for symlink traversal. If workingDir contains a symlink path component and an attacker-controlled blob title (via ocispec.AnnotationTitle) targets a path under that symlink, pushFile() can create a file outside workingDir. relevant links - repository: https://github.com/oras-project/oras-go - commit: 03243809936cce826494b5506f724c6dc11115b1 - callsite: content/file/file.go:609 resolveWritePath() (used by pushFile()) vulnerability details pins: oras-project/oras-go@03243809936cce826494b5506f724c6dc11115b1 as-of: 2026-02-17 policy: GitHub Security Advisory (oras-project/oras-go) callsite: content/file/file.go:609 resolveWritePath() → pushFile() attacker control: Attacker controls the pushed name (ocispec.AnnotationTitle) and can select a path with a symlink path component under workingDir → resolveWritePath() blocks .. via…
Recommended action: Upgrade to 2.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Recommended Fix - validate Location before…
Recommended action: Upgrade to 2.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.