CVE-2024-7387: OpenShift Builder RCE Vulnerability

CVE-2024-7387 Overview

CVE-2024-7387 is a command injection vulnerability via path traversal in openshift/builder. The flaw allows a user with permission to create BuildConfig resources to override executable files inside the privileged build container. When the Docker build strategy is used, the spec.source.secrets.secret.destinationDir attribute can be manipulated to write files outside the intended target directory. An attacker exploiting this issue can execute arbitrary commands on the OpenShift node hosting the builder container and escalate privileges on the underlying host. The weakness is classified under CWE-250: Execution with Unnecessary Privileges.

Critical Impact

An authenticated user with build permissions can break out of the builder container and execute arbitrary commands on the OpenShift node, leading to cluster-level privilege escalation.

Affected Products

• Red Hat OpenShift Container Platform (openshift/builder component)
• OpenShift builds using the Docker build strategy
• Container images shipping the vulnerable openshift/builder binary prior to the patch

Discovery Timeline

• 2024-09-17 - CVE-2024-7387 published to the National Vulnerability Database
• 2024-10-02 - Public technical advisory released describing the privilege escalation path
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-7387

Vulnerability Analysis

The vulnerability resides in the copyLocalObject function within pkg/build/builder/docker.go in openshift/builder. During a build, the builder copies user-supplied secrets and config maps into the build container. The destination path is derived from the spec.source.secrets.secret.destinationDir field of the BuildConfig. The builder concatenates this attacker-controlled value with a target directory using filepath.Join without validating that the resulting path remains within the intended root.

Because the Docker build strategy runs the builder pod in a privileged context, files written through this path are effectively executed with elevated privileges. An attacker can supply a relative path containing .. segments, or rely on symlinks under their control, to redirect writes to arbitrary locations inside the privileged container, including locations on the host that are bind-mounted into the pod.

Root Cause

The root cause is missing path containment checks combined with execution under unnecessary privileges [CWE-250]. The builder accepted a user-supplied destinationDir and constructed the final destination without resolving symbolic links or verifying that the cleaned absolute path remained a subdirectory of the target. This "Zip-Slip" style flaw allowed file overwrites outside the secrets directory, including binaries invoked later in the build pipeline.

Attack Vector

Exploitation requires an account with permission to create or modify BuildConfig resources using the Docker strategy. The attacker crafts a BuildConfig whose secret destinationDir traverses out of the intended path, then triggers a build. When the builder copies the secret payload, it overwrites an executable that the privileged container later invokes, yielding command execution on the node. The patch adds absolute-path enforcement, symlink resolution via filepath.EvalSymlinks, and a strings.HasPrefix check that rejects destinations outside the target directory.

func (d *DockerBuilder) copyLocalObject(s localObjectBuildSource, sourceDir, targetDir string) error {
	if !filepath.IsAbs(sourceDir) {
		return fmt.Errorf("cannot copy local object - source directory %q must be an absolute path", sourceDir)

	}
	if !filepath.IsAbs(targetDir) {
		return fmt.Errorf("cannot copy local object - target directory %q must be an absolute path", targetDir)
	}
	dstDir := filepath.Join(targetDir, s.DestinationPath())
	if err := os.MkdirAll(dstDir, 0777); err != nil {
		return err
	}
	// Evaluate symlinks at the destination dir. EvalSymlinks calls filepath.Clean, ensuring the
	// returned path is an absolute path (we checked targetDir and thus dstDir is absolute above).
	dstDir, err := filepath.EvalSymlinks(dstDir)
	if err != nil {
		return err
	}
	// sourceDir and targetDir should always be absolute paths, therefore HasPrefix can verify if
	// dstDir is a subdirectory of targetDir.
	if !strings.HasPrefix(dstDir, targetDir) {
		return fmt.Errorf("destination path %q is outside of the target directory %q", dstDir, targetDir)
	}

Source: GitHub OpenShift Builder commit 0b62633 - this is the upstream patch that introduces absolute path validation, symlink evaluation, and the prefix check to prevent the traversal.

Detection Methods for CVE-2024-7387

Indicators of Compromise

• BuildConfig objects containing spec.source.secrets[*].destinationDir values with .. sequences, absolute paths, or symlink-bait entries pointing outside the build context.
• Unexpected modifications to executables inside builder containers, such as /usr/bin/* or /tmp/build/* binaries being overwritten during a build run.
• Builder pods spawning processes that are not part of the normal docker build workflow, particularly shells or network utilities executed as root on the node.
• Audit log entries showing build creation by service accounts or users without an established history of triggering Docker-strategy builds.

Detection Strategies

• Inspect Kubernetes audit logs for create and update operations on BuildConfig and Build resources, alerting on destinationDir values that fail path-traversal validation.
• Use admission controllers (OPA/Gatekeeper, Kyverno) to reject BuildConfig objects whose secret or config map destinationDir is not a simple relative path without .. segments.
• Correlate container runtime events on OpenShift nodes with the lifecycle of builder pods to identify privileged file writes outside expected directories.
• Monitor for process executions inside builder containers whose parent is the builder binary but whose image path does not match a known build toolchain component.

Monitoring Recommendations

• Forward OpenShift API server audit logs and node-level container telemetry to a centralized analytics platform for retention and querying.
• Establish a baseline of normal builder pod behavior (processes, file writes, outbound connections) and alert on deviations.
• Track which identities can create BuildConfig resources with the Docker strategy and review that list against least-privilege requirements on a recurring basis.

How to Mitigate CVE-2024-7387

Immediate Actions Required

• Apply the Red Hat security errata for openshift/builder referenced in RHSA-2024:3718, RHSA-2024:6685, RHSA-2024:6687, RHSA-2024:6689, RHSA-2024:6691, and RHSA-2024:6705.
• Audit RBAC bindings that grant create/update on builds.build.openshift.io and buildconfigs.build.openshift.io and remove unnecessary access.
• Review existing BuildConfig resources for suspicious destinationDir values and disable any that contain path traversal sequences.
• Rotate cluster credentials and service account tokens if there is evidence that builder pods executed unauthorized commands on a node.

Patch Information

Red Hat addressed the issue across OpenShift Container Platform versions through the advisories listed above. The upstream fix is committed in openshift/builder commit 0b62633, which enforces absolute paths, resolves symlinks with filepath.EvalSymlinks, and verifies that the resolved destination remains within the target directory. Additional context is available in the Red Hat CVE page and Red Hat Bugzilla #2302259.

Workarounds

• Prefer the Source build strategy over the Docker build strategy where feasible, since the privileged execution model is the prerequisite for exploitation.
• Restrict the system:build-strategy-docker cluster role binding to a minimal set of trusted users and service accounts.
• Use an admission policy to reject BuildConfig resources whose secret or config map destinationDir is absolute or contains ...
• Isolate build nodes from production workloads so that a successful node compromise does not extend to sensitive tenants.

# Remove the cluster-wide ability to use the Docker build strategy
oc adm policy remove-cluster-role-from-group \
  system:build-strategy-docker system:authenticated

# Review which subjects can still launch Docker-strategy builds
oc get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="system:build-strategy-docker") | {name: .metadata.name, subjects: .subjects}'

# Audit existing BuildConfigs for suspicious destinationDir values
oc get buildconfigs --all-namespaces -o json | \
  jq '.items[] | {ns: .metadata.namespace, name: .metadata.name,
      dirs: [.spec.source.secrets[]?.destinationDir]} |
      select(.dirs[]? | test("\\.\\.|^/"))'