CVE-2026-82976 in OpenShift Container Platform
Summary
by MITRE • 11/03/2026
A flaw was found in the image-customization-controller used in OpenShift's bare metal provisioning stack. The controller registers an HTTP file server on port 8084 with no authentication. The custom imageFileSystem implementation exposes a browsable HTML directory listing of all registered images at the root path. The only access control on per-host images is the random UUID filename; the directory listing discloses those UUIDs to any caller on the provisioning network. Each served image embeds an Ignition config containing the base64-encoded cluster pull secret, optional IRONIC_RAMDISK_SSH_KEY, proxy settings, and per-host NetworkManager keyfiles. An adjacent network attacker can enumerate all image UUIDs via directory listing, download any image, extract the embedded Ignition config, and recover the cluster pull secret and SSH key.
### Evidence **pkg/imagehandler/imagefilesystem.go — root directory is browsable and enumerates all UUID image names** ```go func (f *imageFileSystem) Readdir(n int) ([]fs.FileInfo, error) {
f.mu.Lock() defer f.mu.Unlock() result := []fs.FileInfo{}
for _, im := range f.images {
result = append(result, im) } return result, nil }
func (f *imageFileSystem) Open(name string) (http.File, error) {
f.log.Info("Open", "path", name) if name == "/" {
return f, nil } ... ```
**cmd/controller/main.go — file server bound on all interfaces without auth or TLS** ```go http.Handle("/", http.FileServer(imageServer.FileSystem()))
go func() {
server := &http.Server{
Addr: imagesBindAddr, // default ":8084" ReadHeaderTimeout: 5 * time.Second, } err := server.ListenAndServe() ```
**pkg/ignition/service_config.go:94-100 — pull secret is embedded in every served image** ```go func (b *ignitionBuilder) authFile() ignition_config_types_32.File {
source := "data:;base64," + strings.TrimSpace(b.ironicAgentPullSecret) return ignition_config_types_32.File{
Node: ignition_config_types_32.Node{Path: "/etc/authfile.json"},
... ```
### Attack Pattern Adjacent provisioning-network client → GET / lists UUID image names → download ISO/initramfs → extract embedded Ignition → recover cluster pull secret and SSH key.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in the OpenShift bare metal provisioning stack stems from a critical misconfiguration within the image-customization-controller, which serves as a central component for managing host images during infrastructure deployment. This controller inadvertently registers an HTTP file server on port 8084 that is bound to all network interfaces and operates without any form of authentication or transport layer security such as TLS. The core technical flaw lies in the implementation of the custom imageFileSystem, which exposes a browsable HTML directory listing at the root path for all registered images. This design choice allows any client capable of reaching port 8084 to enumerate every image identifier stored within the system by simply requesting the root URL.
The security implications are severe because the access control mechanism relies solely on the obscurity of random UUID filenames, which provides no actual protection against enumeration attacks. Once an attacker obtains these UUIDs through the directory listing, they can directly download specific ISO or initramfs images associated with individual hosts. These image files are not merely static binaries; they embed Ignition configuration data that contains sensitive operational secrets required for cluster initialization and host management. Specifically, each served image includes a base64-encoded copy of the cluster pull secret, which is essential for authenticating to container registries, along with optional SSH keys designated as IRONIC_RAMDISK_SSH_KEY, proxy settings, and per-host NetworkManager keyfiles used for network configuration during provisioning.
An adjacent attacker on the same provisioning network can exploit this flaw by first enumerating all available image UUIDs via a simple HTTP GET request to the root directory. Following enumeration, the attacker selects target images and downloads them locally. By extracting the embedded Ignition configuration from these downloaded files, the attacker can decode the base64-encoded cluster pull secret and retrieve any exposed SSH keys. This effectively compromises the integrity of the entire OpenShift cluster by granting unauthorized access to container registries and remote host management interfaces. The attack pattern aligns with CWE-200, which classifies this as an Information Exposure vulnerability, specifically involving sensitive information in a directory listing that is accessible without authentication.
From a tactical perspective, this exploitation path corresponds to the ATT&CK technique of Valid Accounts under Credential Access, as it involves harvesting credentials such as pull secrets and SSH keys from configuration files rather than cracking them directly. It also relates to CWE-538 regarding File and Directory Information Exposure. The lack of network segmentation or access control lists further exacerbates the risk, allowing any host on the provisioning subnet to participate in this data exfiltration without detection by standard perimeter defenses that do not inspect internal traffic for such specific patterns.
To mitigate this vulnerability, immediate remediation is required to restrict access to the image-customization-controller's HTTP service. The most effective solution involves binding the server to a loopback interface or implementing strict firewall rules that limit connectivity on port 8084 exclusively to trusted provisioning components rather than exposing it broadly across the network. Additionally, enabling TLS encryption for all communications involving sensitive configuration data is essential to prevent passive eavesdropping if access controls are bypassed. Implementing authentication mechanisms such as mutual TLS or token-based authorization would also ensure that only authorized services can request image files and directory listings. Finally, avoiding the embedding of high-privilege credentials like pull secrets directly within static image configurations should be considered for future architectural improvements to reduce the blast radius of any single configuration leak.