Source: golang-oras-oras-go Version: 2.6.0-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for golang-oras-oras-go. CVE-2026-48978[0]: | oras-go is a Go library for managing OCI artifacts. Prior to 2.6.1, | auth.Client follows the realm URL from a registry's WWW- | Authenticate: Bearer challenge without validating the scheme or | host, allowing a malicious or compromised registry to cause SSRF to | internal networks such as http://169.254.169.254/, http://10.0.0.x/, | and http://127.0.0.1/, or to downgrade a registry contacted over | https:// to an http:// token endpoint in | registry/remote/auth/client.go through Client.Do(), | Client.fetchBearerToken(), fetchDistributionToken, and | fetchOAuth2Token. This issue is fixed in version 2.6.1. CVE-2026-50151[1]: | oras-go is a Go library for managing OCI artifacts. Prior to 2.6.1, | registry/remote/repository.go in | blobStore.completePushAfterInitialPost follows a registry-controlled | Location header during monolithic blob upload and reuses the | Authorization header from the initial POST request for the | subsequent PUT request, allowing a malicious registry to return a | cross-host Location and receive the caller's credentials at an | attacker-controlled endpoint. This issue is fixed in version 2.6.1. CVE-2026-50162[2]: | oras-go is a Go library for managing OCI artifacts. Prior to 2.6.1, | resolveWritePath() in content/file/file.go uses a lexical | filepath.Rel check for workingDir and does not account for symlink | traversal, so when AllowPathTraversalOnWrite=false an attacker- | controlled blob title through ocispec.AnnotationTitle such as | out/pwn.txt can follow a workingDir symlink out -> /some/outside/dir | and cause pushFile() to create /some/outside/dir/pwn.txt outside | workingDir. This issue is fixed in version 2.6.1. CVE-2026-50163[3]: | 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. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-48978 https://www.cve.org/CVERecord?id=CVE-2026-48978 [1] https://security-tracker.debian.org/tracker/CVE-2026-50151 https://www.cve.org/CVERecord?id=CVE-2026-50151 [2] https://security-tracker.debian.org/tracker/CVE-2026-50162 https://www.cve.org/CVERecord?id=CVE-2026-50162 [3] https://security-tracker.debian.org/tracker/CVE-2026-50163 https://www.cve.org/CVERecord?id=CVE-2026-50163 Regards, Salvatore
