CVE-2026-50162

What it actually does

oras-go before 2.6.1 can write files outside its intended working directory when handling attacker-controlled OCI artifact metadata. The vulnerable path validation in resolveWritePath() uses a lexical filepath.Rel-style check to decide whether a requested output path is inside the working directory, but it does not safely account for symlinks already present under that directory. If an attacker can influence the blob title through ocispec.AnnotationTitle and can cause or rely on a symlink inside the working directory that points elsewhere, pushFile() may create or overwrite a file at the symlink target outside the intended directory. The primary impact is unauthorized file creation or modification on the host running software that embeds the vulnerable library.

Why it matters to the business

Applications, registries, CI/CD tooling, artifact-processing services, or developer workflows that use affected oras-go versions to process untrusted OCI artifacts may allow a malicious artifact to place files outside the expected extraction or write location. In practical terms, this can corrupt local files, tamper with build or deployment inputs, poison generated artifacts, or create foothold files for later abuse. The issue is not currently listed in CISA KEV, has low EPSS probability, and has no known public exploit maturity in the provided data, but it should still be prioritized anywhere untrusted OCI artifacts are processed automatically.

How an attack unfolds

An attacker prepares an OCI artifact with a controlled blob title, such as a title that appears lexically safe relative to the configured working directory. The vulnerable application uses oras-go before 2.6.1 to write that blob to disk while AllowPathTraversalOnWrite is false, expecting the library to keep output inside the working directory. If a path component under the working directory is a symlink to a location outside that directory, the lexical containment check can be bypassed because it validates the string path rather than the fully resolved filesystem destination. During the write operation, the operating system follows the symlink and creates or overwrites the attacker-named file outside the intended boundary. Successful exploitation depends on the application processing attacker-controlled artifact titles and the presence or creation of a useful symlink path in the working directory.

How to fix it

Upgrade oras-go to version 2.6.1 or later in all applications, tools, services, and build pipelines that embed the library. Because this is a library vulnerability, remediation usually requires updating the Go module dependency, rebuilding affected binaries, and redeploying the consuming application rather than only patching an operating system package. If immediate upgrade is not possible, avoid processing untrusted OCI artifacts, disable or tightly constrain workflows that write blob titles to disk, use isolated temporary working directories with no attacker-controllable symlinks, run artifact processing under a least-privilege account, mount workspaces with restrictive permissions, and cleanly recreate working directories before each operation. Do not rely only on AllowPathTraversalOnWrite=false as a mitigation in affected versions.

How to confirm the fix worked

Confirm that all built and deployed binaries use oras-go version 2.6.1 or later, for example by reviewing go.mod/go.sum, software bill of materials output, dependency scanner results, or build metadata. Rebuild and redeploy binaries after dependency updates, then verify the running artifact-processing component is the rebuilt version. Where safe, perform a controlled regression test using a temporary working directory containing a symlink to another temporary directory and an OCI artifact title that writes through that symlink; patched behavior should reject or prevent writing outside the intended working directory. Also validate that artifact-processing workspaces are recreated or sanitized between runs and do not contain unexpected symlinks.

Typical attack path

1. Identify a service, tool, or pipeline that uses oras-go before version 2.6.1 to pull, copy, unpack, or otherwise write OCI artifact blobs to the local filesystem.
2. Ensure the target workflow processes attacker-controlled OCI artifacts or artifact metadata, especially blob titles from OCI annotations.
3. Arrange for a symlink inside the configured working directory to point to a sensitive or attacker-useful location outside that directory, or exploit an existing symlink created by the workflow.
4. Publish or submit a malicious OCI artifact whose blob title routes the write through the symlink path while still appearing lexically contained within the working directory.
5. Trigger the vulnerable artifact-processing operation.
6. The vulnerable code validates the path lexically, follows the symlink during the actual write, and creates or modifies a file outside the intended working directory.
7. Use the unauthorized file write to tamper with downstream build inputs, configuration, generated artifacts, or other files writable by the vulnerable process.

How to detect it

Look for evidence that OCI artifact processing wrote files outside its configured workspace. Useful sources include application logs from tools embedding oras-go, CI/CD job logs, artifact mirroring or registry automation logs, filesystem audit logs, endpoint detection telemetry, and Linux auditd or eBPF file-write events. Focus on time windows when untrusted OCI artifacts were pulled, copied, exported, or written to disk. Investigate writes by artifact-processing processes that target paths outside their configured working directory, especially where the written path traverses through a symlink located inside the workspace. Review workspaces for symlinks that point outside the workspace and were present before or during artifact processing. Also inspect suspicious OCI artifacts for blob titles using the OCI title annotation that reference symlinked subpaths. Because the attacker controls the file name and destination depends on local symlink layout, there are no reliable universal network or file IOCs; behavioral detection is more dependable.

What your security team should do

• Inventory all internally developed and third-party tools that use oras-go, especially OCI artifact pull, copy, mirror, unpack, registry, and CI/CD components.
• Prioritize upgrades to oras-go 2.6.1 or later for systems that process untrusted or externally supplied OCI artifacts automatically.
• Rebuild and redeploy affected Go binaries; dependency updates are not effective until consuming applications are rebuilt.
• Temporarily restrict untrusted artifact ingestion where upgrade cannot be completed quickly.
• Run vulnerable artifact-processing jobs with least privilege and in isolated disposable workspaces to reduce the impact of unauthorized writes.
• Search recent artifact-processing workspaces for unexpected symlinks and files written outside intended output directories around artifact pull/copy/write times.
• Add dependency scanning or SBOM checks that flag oras-go versions earlier than 2.6.1.