CVE-2026-50163

What it actually does

CVE-2026-50163 is a path traversal / unsafe hardlink handling flaw in oras-go before 2.6.2, a Go library used to manage OCI artifacts. During extraction of an OCI artifact marked for unpacking, the library validates a hardlink target relative to the extraction base but then returns and uses the unresolved link target. For tar hardlink entries, this can cause os.Link to resolve the link target relative to the process current working directory rather than the intended extraction directory. A malicious OCI artifact can therefore cause the extracting process to create hardlinks to files outside the artifact extraction tree, potentially exposing or modifying sensitive local files accessible to the process, such as environment files, Git configuration, cloud credentials, or SSH configuration. The CVSS vector indicates network-reachable delivery, low attack complexity, no attacker authentication required, but some user or automated workflow interaction is required to fetch or unpack the malicious artifact.

Why it matters to the business

Organizations that use oras-go-based tooling or applications to fetch and unpack untrusted OCI artifacts may risk credential exposure, source control configuration leakage, or unintended modification of local files used by build, deployment, or developer workflows. The most likely business consequences are compromise of secrets on developer workstations, CI/CD runners, artifact-processing services, or automation hosts, which can lead to downstream repository access, cloud account misuse, supply-chain compromise, and incident response disruption. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS at the time provided, and has no reported mature public exploit, but it is straightforward to weaponize in malicious artifacts and affects a supply-chain-adjacent component, so environments that process third-party OCI artifacts should prioritize remediation.

How an attack unfolds

An attacker publishes or sends a crafted OCI artifact that will be processed by software using a vulnerable version of oras-go. The artifact includes metadata requesting unpack behavior, such as io.deis.oras.content.unpack set to true, and contains a tar hardlink entry whose name is inside the extraction directory but whose Linkname references a file outside the extracted artifact context or relative to the current working directory of the vulnerable process. When a victim user, CI job, artifact scanner, deployment tool, or automation pipeline pulls and unpacks the artifact, oras-go validates the hardlink target as though it is constrained to the extraction base, but later passes the unresolved target to os.Link. The operating system resolves that hardlink target relative to the process current working directory, allowing the artifact extraction operation to create a link to an unintended local file. Depending on permissions and subsequent processing, the attacker can cause sensitive files to become accessible through the extracted artifact tree or enable tampering with files that the process can write to. Practical exploitation depends on where the vulnerable process runs, what its current working directory is, which local files are present, and whether the attacker can induce the victim workflow to unpack the malicious artifact.

How to fix it

Upgrade all direct and transitive uses of oras-go to version 2.6.2 or later. Rebuild and redeploy binaries, containers, CLIs, CI helpers, scanners, and internal services that vendor or statically compile oras-go, because Go dependencies are commonly embedded at build time. If immediate upgrade is not possible, avoid unpacking untrusted OCI artifacts, disable or reject artifacts that request automatic unpacking, and block or sanitize tar hardlink entries during extraction. Run artifact-processing workloads with least privilege, in isolated ephemeral directories, with a controlled current working directory, and without access to sensitive files such as cloud credentials, SSH keys, repository secrets, or production configuration. Treat CI/CD runners and developer tooling that process external artifacts as higher priority for patching.

How to confirm the fix worked

Confirm the installed or compiled dependency version is oras-go 2.6.2 or later using dependency manifests, SBOMs, Go module metadata, or build provenance. Check go.mod, go.sum, vendor manifests, container SBOMs, and binary dependency reports for github.com/oras-project/oras-go versions earlier than 2.6.2. For products that embed oras-go, verify the vendor has released and you have deployed a build that incorporates the fixed library. In test environments only, validate that crafted OCI artifacts containing tar hardlink entries cannot create hardlinks to files outside the extraction base or relative to the process current working directory. Also confirm artifact-processing services run in restricted workspaces and that unpacking untrusted artifacts is disabled or guarded where business logic allows.

Typical attack path

1. Identify a target workflow, tool, or service that uses oras-go before version 2.6.2 and unpacks OCI artifacts from external or semi-trusted sources.
2. Create an OCI artifact containing unpack metadata, such as io.deis.oras.content.unpack=true.
3. Embed a tar hardlink entry with a path under the extraction directory and a Linkname that resolves against the vulnerable process current working directory to a sensitive or useful local file.
4. Publish the artifact to a registry, submit it to a build/deployment workflow, or otherwise persuade an automated process or user to fetch and unpack it.
5. Wait for the vulnerable oras-go extraction path to validate the hardlink incorrectly and invoke os.Link with the unresolved target.
6. Access the resulting hardlink inside the extracted artifact tree, or rely on later pipeline steps to archive, upload, scan, or expose the linked sensitive file.
7. Use any obtained credentials, configuration, or repository/cloud access to expand impact.

How to detect it

To determine whether exploitation already occurred, review OCI artifact registry events, CI/CD logs, artifact-processing service logs, and endpoint telemetry for untrusted artifacts that were pulled and unpacked by tools using vulnerable oras-go versions. Focus on artifacts with the annotation io.deis.oras.content.unpack set to true and tar entries of type hardlink, especially where the hardlink target is a relative filename, contains parent-directory traversal, references dotfiles, or names credential/configuration files. Examine build workspaces, extraction directories, caches, and archived job artifacts for hardlinks to sensitive files by comparing inode numbers and link counts where supported. On Linux and Unix-like systems, use filesystem forensic tools or find/stat to identify files in extraction directories with link counts greater than one and shared inodes with files outside the extraction base. Review whether extracted artifact outputs were uploaded to logs, build artifacts, cache storage, registry layers, or external scanners after the unpack step. Endpoint detection should look for artifact-processing processes creating hardlinks from unusual current working directories or linking to files such as .env, .git/config, .aws/credentials, SSH config files, or other local secrets. Because this flaw primarily abuses legitimate filesystem link behavior during artifact extraction, there may be no network IOC beyond the malicious artifact reference; detection depends heavily on artifact metadata, tar contents, process/file telemetry, and post-extraction exposure paths.

• io.deis.oras.content.unpack
• io.deis.oras.content.unpack: true
• Typeflag=TypeLink
• payload.tar.gz/evil_cwd_link
• victim.secret
• .env
• .git/config
• .aws/credentials
• ~/.ssh/config
• github.com/oras-project/oras-go v2.6.1
• github.com/oras-project/oras-go v2.6.0

What your security team should do

• Inventory applications, developer tools, CI/CD jobs, artifact scanners, and internal services that use oras-go or ORAS-based OCI artifact handling.
• Upgrade or rebuild all affected components with oras-go 2.6.2 or later, prioritizing internet-facing artifact processors, CI/CD runners, and systems that process third-party OCI artifacts.
• Temporarily block or quarantine OCI artifacts that request automatic unpacking from untrusted sources until vulnerable consumers are patched.
• Add registry and pipeline controls to inspect unpacked artifact tar layers for hardlink entries and reject suspicious hardlinks that target relative paths, parent directories, home-directory paths, or sensitive filenames.
• Run artifact extraction in ephemeral sandboxes with no mounted secrets, no persistent workspace reuse, and a known safe current working directory.
• Rotate credentials if logs or artifacts indicate that sensitive files such as .env, .aws/credentials, .git/config, or SSH configuration may have been linked, archived, uploaded, or exposed after processing an untrusted artifact.
• Review build and deployment logs for recently processed external OCI artifacts since publication, especially artifacts containing unpack annotations or unusual tar hardlink entries.