Bug 2558338 (CVE-2026-115424)

Summary: CVE-2026-115424 oc: oc: Symlink/hardlink target validation bypass in oc image extract allows file write outside destination
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, sghai, sidsharm, suppawar, vlaad
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the OpenShift client oc. When extracting container image layers with oc image extract, the application fails to properly sanitize symbolic and hard link targets pointing to absolute paths or to sibling directories of the extraction destination. An attacker who supplies a malicious container image can exploit this vulnerability by embedding links, and a chained file entry, that reference locations outside the intended extraction directory. This allows the attacker to write attacker-controlled content to arbitrary locations on the host filesystem with the privileges of the user running the command, potentially leading to file modification outside the destination directory.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-10-21 15:38:24 UTC 
A flaw was found in openshift/oc's local tar-extraction code used by oc image extract. The createTarFile() function in pkg/cli/image/archive/archive.go (oc's private fork of Docker/Moby's pkg/archive) validates that a symlink or hardlink target stays inside the extraction directory by computing targetPath := filepath.Join(filepath.Dir(path), hdr.Linkname) and testing strings.HasPrefix(targetPath, extractDir), but then creates the symlink using the raw, unvalidated hdr.Linkname via os.Symlink(hdr.Linkname, path). The check fails in two independent ways: for an absolute Linkname (e.g. /etc/passwd), Go's filepath.Join does not re-root, so the computed path folds under the extraction directory and passes, while the created symlink points to the attacker-specified absolute path; and for a relative Linkname sharing the destination's basename as a text prefix (e.g. ../safe-x/marker against a safe destination), strings.HasPrefix matches across the path boundary and the target resolves into a sibling directory outside the destination. The hardlink (TypeLink) branch is affected by the sibling-prefix variant. oc image extract reaches this code by calling archive.ApplyLayer() directly with a reader sourced from the remote image's layer blob, so the processed tar stream is attacker-controlled. The dangling-symlink primitive further chains into an arbitrary-content write outside the destination: a second tar entry whose name traverses the just-planted symlink is written with OpenFile(path, O_CREATE|O_WRONLY, …), which follows symlinks, because the per-entry name check inspects only the textual dest+Name join and never Lstats intermediate components. The general entry-name containment check in the same file is correct (it uses filepath.Rel); only the symlink/hardlink target check was left in the older, insufficient form.