Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

oras-go has file store write outside workingDir via symlink traversalGHSA-8xwf-rjm4-xvhv

Fix: oras-project/oras-go@cc323e5

GHSA-8xwf-rjm4-xvhv is a CWE-73 vulnerability in oras.land/oras-go/v2. A fix is available for oras.land/oras-go/v2 — see the affected versions and patch details below.

Also known asCVE-2026-50162GO-2026-5879
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 24, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-8xwf-rjm4-xvhv.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs42th percentile — riskier than 42% of all scored CVEsHighest risk
0.00%0.34%0.67%1.01%0.4%0.5%0.5%0.5%Aug 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐹oras.land/oras-go/v2

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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

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 filepath.Rel but does not prevent symlink traversal → pushFile() opens/creates the final path and follows the symlink → a file is created outside workingDir

root cause

resolveWritePath() enforces the write boundary using a filepath.Rel-style check against workingDir. This prevents ../ escapes but is purely lexical and does not resolve symlinks. If a path component under workingDir is a symlink to an external location, the subsequent filesystem operation in pushFile() follows that symlink and performs the write outside workingDir while still passing the lexical boundary check.

attack path

  1. Attacker provides a blob title (via ocispec.AnnotationTitle) that contains a path like out/pwn.txt.
  2. Victim uses oras-go file store with AllowPathTraversalOnWrite=false and a workingDir that contains a symlink directory out -> /some/outside/dir.
  3. The lexical boundary check accepts out/pwn.txt as being under workingDir.
  4. The write follows the symlink and creates /some/outside/dir/pwn.txt.

impact

This is a filesystem boundary bypass that permits writes outside workingDir when a symlink path component exists under workingDir. The concrete security impact depends on the runtime environment (what filesystem locations are writable by the process and what downstream consumers do with the written file), but the intended confinement guarantee is violated.

proof of concept

the attached poc.zip contains a small, self-contained go harness that demonstrates:

  • canonical (vulnerable): prints [CALLSITE_HIT] and [PROOF_MARKER] and shows the file is created outside workingDir
  • control (no symlink component): prints [NC_MARKER] and confirms no outside write occurs

run:

unzip -q -o poc.zip -d /tmp
cd /tmp/poc-F-ORAS-SYMLINK-WRITE-001
make test

expected: when AllowPathTraversalOnWrite=false, file store writes should not be able to escape workingDir, including via symlink traversal.

actual: A symlink path component under workingDir allows writes to escape workingDir even when AllowPathTraversalOnWrite=false.

recommended fix

ensure confinement checks account for symlink traversal. Options include rejecting symlinks in any path component (walk components with os.Lstat), validating the resolved parent directory via EvalSymlinks and enforcing it remains under the resolved workingDir, or using an openat()-style approach so the check and open happen relative to a trusted directory file descriptor.

fix accepted when: The canonical PoC no longer prints [PROOF_MARKER] for the same attacker-controlled inputs.

cheers, Oleh

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gooras.land/oras-go/v2all versions2.6.1go get oras.land/oras-go/v2@v2.6.1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for oras.land/oras-go/v2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update oras.land/oras-go/v2 to 2.6.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8xwf-rjm4-xvhv is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate
ProductFixed inAdvisory
Migration Toolkit for Virtualization 2.10migration-toolkit-virtualization/mtv-validation-rhel9:1791228247RHSA-2026:83663
Migration Toolkit for Virtualization 2.11migration-toolkit-virtualization/mtv-validation-rhel9:1791229031RHSA-2026:83662
OpenShift Security Profiles Operator 1compliance/openshift-security-profiles-operator-bundle:1790626888RHSA-2026:76752
Red Hat Edge Manager 1.1rhem/flightctl-alert-exporter-rhel10:1789485396RHSA-2026:68044
Red Hat Edge Manager 1.1rhem/flightctl-alert-exporter-rhel9:1789488080RHSA-2026:68253
Red Hat Edge Manager 1.2rhem/flightctl-alert-exporter-rhel10:1789485358RHSA-2026:68006
Red Hat Edge Manager 1.2rhem/flightctl-alert-exporter-rhel9:1789485374RHSA-2026:68254
Red Hat Hardened Imageshelm4-main-4.2.3-0.1.2.hum1RHSA-2026:42230

Frequently Asked Questions

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()`
O3 Security · Impact-Aware SCA

Is GHSA-8xwf-rjm4-xvhv in your dependencies?

Find it across Go, including transitive dependencies.

oras-go has file store write outside workingDir via symlink…