CVE-2026-115424 in OpenShift Container Platform
Summary
by MITRE • 10/23/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in the OpenShift client oc tool represents a critical path traversal and symbolic link following flaw within the image extraction functionality. Specifically, when an administrator or developer utilizes the oc image extract command to retrieve container image layers for local inspection or deployment preparation, the application fails to adequately sanitize file paths contained within those images. The core technical defect lies in the insufficient validation of symbolic links and hard links embedded in the container filesystem metadata. Instead of restricting extraction strictly to the designated destination directory, the tool processes link targets that point to absolute system paths or directories outside the intended sandboxed environment. This lack of strict path canonicalization allows an attacker who controls a malicious container image to craft file entries where symlinks resolve to arbitrary locations on the host operating system rather than remaining within the extraction root.
From an operational perspective, this vulnerability enables a severe privilege escalation scenario relative to the user executing the command. Since oc is typically run by developers or CI/CD pipeline agents with standard user privileges but often possessing access to sensitive configuration files and keys, writing arbitrary content outside the intended directory can lead to significant compromise of host integrity. An attacker could overwrite critical system binaries, modify shell initialization scripts such as .bashrc or .profile to inject persistent backdoors, or alter Kubernetes configuration files like kubeconfig to hijack cluster authentication tokens. The impact is not limited to simple file modification; it extends to the potential for remote code execution if the overwritten files are subsequently executed by privileged processes or other users on the system. This effectively breaks the isolation guarantees expected when handling untrusted container images, turning a routine administrative task into a vector for host compromise.
This flaw aligns with Common Weakness Enumeration (CWE) categories such as CWE-22: Improper Limitation of a Pathname to a Restricted Directory and CWE-59: Improper Link Resolution Before File Access. The attack pattern is consistent with techniques documented in the MITRE ATT&CK framework, particularly T1036: Masquerading or T1486: Data Encrypted for Impact if the written files are used to disrupt operations, but more directly relates to file system manipulation tactics where an adversary writes malicious content to arbitrary locations. The vulnerability exploits the trust placed in container image metadata by assuming that extraction tools will inherently prevent escape from the target directory, a assumption proven false by this implementation flaw.
Mitigation strategies must address both immediate remediation and long-term security hygiene. Users should immediately upgrade to a patched version of the OpenShift client oc tool where the path sanitization logic has been corrected to strictly validate all link targets against the extraction root before processing. In environments where upgrading is not instantly feasible, administrators should enforce strict policies regarding which container images are permitted for local extraction, ensuring that only trusted and signed images from verified registries are processed with this command. Additionally, running oc commands within restricted containers or using user namespaces can limit the blast radius of such a vulnerability by isolating file system access. Regular auditing of cron jobs and startup scripts on developer workstations is also recommended to detect any unauthorized modifications resulting from prior exploitation attempts.