Withdrawn by the publisher.

Affected: CleanStart: rancher-agent

Package rancher-agent version 2.13.7-r2 fixes 7 vulnerabilities: CVE-2026-50163, CVE-2026-48978, CVE-2026-50151, CVE-2026-50162, ghsa-vh4v-2xq2-g5cg...

oras-go is a Go library for managing OCI artifacts. Prior to 2.6.2, ensureLinkPath in content/file/utils.go:262-275 validates a hardlink target relative to the extract base but returns the unresolved target, causing os.Link("victim.secret", "<extract_base>/payload.tar.gz/evil_cwd_link") to resolve header.Linkname against the process current working directory for a Typeflag=TypeLink entry such as Name=payload.tar.gz/evil_cwd_link and Linkname="victim.secret" with io.deis.oras.content.unpack: "true", which can expose or tamper with files such as .env, .git/config, .aws/credentials, and ~/.ssh/config. This issue is fixed in version 2.6.2.

Affected: Go: oras.land/oras-go/v2

### Root cause

The tar-extraction helper `ensureLinkPath` at [`content/file/utils.go:262-275`](https://github.com/oras-project/oras-go/blob/main/content/file/utils.go#L262-L275) validates that a hardlink's target resolves inside the extract base, but then returns the original unresolved `target` string back to the caller:

```go func ensureLinkPath(baseAbs, baseRel, link, target string) (string, error) { path := target if !filepath.IsAbs(target) { path = filepath.Join(filepath.Dir(link), target) // resolved FOR VALIDATION } if _, err := resolveRelToBase(baseAbs, baseRel, path); err != nil { return "", err } return target, nil // <-- returns the ORIGINAL target, not the validated path } ```

The caller for `TypeLink` hardlinks then does:

```go case tar.TypeLink: var target string if target, err = ensureLinkPath(dirPath, dirName, filePath, header.Linkname); err == nil { err = os.Link(target, filePath) } ```

`os.Link(oldname, newname)` wraps the `link(2)` system call. From the `link(2)` man page:

> oldpath and newpath are interpreted relative to the current working directory of the calling process.

So when `target` (i.e., `header.Linkname`) is a **relative** path, `os.Link` resolves it against the process's **current working directory**, not against `filepath.Dir(link)` as the validation assumed.

### Attack

An attacker who controls an OCI-compliant registry (or any artifact source the victim consumes via `ora…

oras-1.3.3-2.1 on GA media

brace-expansion: Brace-expansion: Denial of Service due to exponential-time complexity github.com/jackc/pgx: golang: pgx: SQL injection via specific SQL query conditions github.com/sigstore/fulcio: Fulcio: Server-Side Request Forgery and Kubernetes ServiceAccount token leakage dompurify: DOMPurify: Cross-site scripting vulnerability allows code execution oras-go: Oras-go: Information disclosure and arbitrary file access via crafted tarball hardlinks github.com/containerd/containerd: containerd: Host-root command execution via unvalidated image config labels in CRI plugin github.com/containerd/containerd: containerd: Security bypass via Container Device Interface (CDI) annotation smuggling during checkpoint restoration. js-yaml: js-yaml: Denial of Service via crafted YAML documents

Affected: Ubuntu:24.04:LTS: golang-oras-oras-go, Ubuntu:26.04:LTS: golang-oras-oras-go

oras-go is a Go library for managing OCI artifacts. Prior to 2.6.2, ensureLinkPath in content/file/utils.go:262-275 validates a hardlink target relative to the extract base but returns the unresolved target, causing os.Link("victim.secret", "<extract_base>/payload.tar.gz/evil_cwd_link") to resolve header.Linkname against the process current working directory for a Typeflag=TypeLink entry such as Name=payload.tar.gz/evil_cwd_link and Linkname="victim.secret" with io.deis.oras.content.unpack: "true", which can expose or tamper with files such as .env, .git/config, .aws/credentials, and ~/.ssh/config. This issue is fixed in version 2.6.2.