CVE-2026-50163: `oras-go` tar extraction: Hardlink entry with relative Linkname escapes extract dir via process CWD resolution

Primary: arbitrary-CWD-file read primitive. An attacker-controlled OCI artifact, when pulled by a victim using the oras CLI or any Go program using oras-go/v2/content/file, can create a hardlink inside the victim’s extract tree pointing to an arbitrary file in the victim’s process CWD (that the invoker UID is permitted to read). Reading the extract-tree hardlink yields that file’s contents verbatim.

Secondary: inode-sharing tampering primitive. Any tool that later modifies the extract-tree hardlink (write, chmod, truncate, etc.) modifies the CWD file through the shared inode. This violates the “writes inside the extract dir are confined” invariant that downstream tooling (CI systems, container-image builders, artifact scanners) typically depends on.

High-severity chains:

• CI pipelines where oras pull runs from a project workspace containing secrets/credentials (.env, .git/config, service-account tokens). The pulled artifact can hardlink those secrets into a location later archived/mounted/published.
• Container orchestration where the extract dir is bind-mounted into a lower-trust container while the pull-invoker’s CWD is higher-trust. Hardlinks created in the extract tree expose invoker-CWD files across the trust boundary.
• Kubernetes operators / Flux source-controller using oras-go to fetch artifacts; their CWD is typically / or /root — very sensitive.
• Multi-tenant registry proxies that use oras-go to fetch and re-serve artifacts; each proxy process has a CWD with configuration, keys, or per-tenant state.

Not affected:

• oras push (tarball creation side): tarDirectory in the same file explicitly skips hardlink generation (line 65 comment: "We don't support hard links and treat it as regular files"), so pushed content cannot trigger this on the server.
• Symlink extraction path (TypeSymlink): os.Symlink stores the target string verbatim and does not CWD-resolve at creation time. The current ensureLinkPath return-of-target is correct for symlinks (the existing validation correctly models the symlink-follow path).