Summary
oras-go has file store write outside workingDir via symlink traversal
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 bypushFile())
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
- Attacker provides a blob title (via
ocispec.AnnotationTitle) that contains a path likeout/pwn.txt. - Victim uses
oras-gofile store withAllowPathTraversalOnWrite=falseand aworkingDirthat contains a symlink directoryout -> /some/outside/dir. - The lexical boundary check accepts
out/pwn.txtas being underworkingDir. - The write follows the symlink and creates
/some/outside/dir/pwn.txt.
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 outsideworkingDir - 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.
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.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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
Frequently Asked Questions
- What is CVE-2026-50162? CVE-2026-50162 is a medium-severity security vulnerability in oras.land/oras-go/v2 (go), affecting versions < 2.6.1. It is fixed in 2.6.1.
- Which versions of oras.land/oras-go/v2 are affected by CVE-2026-50162? oras.land/oras-go/v2 (go) versions < 2.6.1 is affected.
- Is there a fix for CVE-2026-50162? Yes. CVE-2026-50162 is fixed in 2.6.1. Upgrade to this version or later.
- Is CVE-2026-50162 exploitable, and should I be worried? Whether CVE-2026-50162 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-50162 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-50162? Upgrade
oras.land/oras-go/v2to 2.6.1 or later.