Attack Chain

1. An attacker crafts a malicious OCI artifact layer containing a hardlink entry (Typeflag=TypeLink, Linkname="victim.secret", where victim.secret is a relative path). The layer is specifically annotated for auto-extraction (io.deis.oras.content.unpack: "true").
2. The malicious artifact is published to an OCI-compliant registry controlled by the attacker or a compromised one.
3. A victim executes oras pull (or any Go code using oras-go/v2/content/file) to retrieve the artifact, with their current working directory (CWD) containing a sensitive file named victim.secret.
4. During extraction, oras-go's ensureLinkPath function validates the hardlink. Due to a logic flaw, it incorrectly returns the original relative Linkname (victim.secret), despite internally resolving a safe absolute path for validation.
5. The os.Link system call is then invoked with this relative victim.secret as the oldname parameter. Instead of resolving relative to the extraction base, os.Link resolves it against the process's CWD.
6. A hardlink is created inside the victim's artifact extraction directory (e.g., extract/payload.tar.gz/evil_cwd_link), pointing to the sensitive victim.secret file located in the victim's CWD.
7. The attacker, by subsequently accessing the extracted artifact (e.g., reading the evil_cwd_link file), can now read the contents of the sensitive victim.secret file from the victim's CWD or modify its contents through the shared inode.

Impact

This vulnerability presents an arbitrary file read primitive, allowing an attacker to access sensitive files from the victim's current working directory (CWD). If oras pull is run by a regular user, files like .env, .git/config, .aws/credentials, SSH configurations, project-local secrets, or CI workspace files are at risk. In high-severity scenarios, such as when oras pull is run as root (e.g., within Kubernetes operators, systemd services without User= isolation, or container entrypoints), the attacker gains the ability to read or tamper with virtually any file on the host filesystem, including /etc/shadow, /root/.ssh/id_rsa, or bind-mounted host paths, making it a critical threat to CI pipelines, container orchestration, and multi-tenant environments. The PoC demonstrated successful inode sharing on Ubuntu 24.04.4 LTS, confirming the ability to access CWD files through the created hardlink.

Recommendation

• Patch CVE-2026-50163 immediately: Upgrade oras-go/v2 to a version greater than 2.6.1. For oras CLI users, upgrade to the latest patched version when available.
• Implement fs.protected_hardlinks: Ensure fs.protected_hardlinks=1 is enabled on Linux systems. While not a full fix for user-owned files, this mitigates unauthorized hardlinking of root-owned files when the victim process runs as a regular user.
• Minimize oras pull CWD exposure: Restrict the environment where oras pull or oras-go library calls are executed. Do not run oras pull from directories containing sensitive files.
• Limit oras pull privileges: Avoid running oras pull as a privileged user (e.g., root) in production or CI/CD environments. Utilize user namespaces, unprivileged containers, or User= directives in systemd where applicable.