CVE-2026-47190: Metal3 IPAM Privilege Escalation Issue

CVE-2026-47190 Overview

CVE-2026-47190 is an excessive privilege vulnerability in the Metal3 IP Address Manager (IPAM), the IP address management controller for Cluster API Provider Metal3. The IPAM controller's ClusterRole was configured with full CRUD permissions (create, delete, get, list, patch, update, watch) on core/v1 Secrets, even though the controller never accesses Secrets during normal operation. An attacker who compromises the controller pod through a supply chain attack or container escape can abuse these unnecessary permissions to read, modify, or delete Secrets in the namespace. The flaw is tracked under CWE-250: Execution with Unnecessary Privileges and is fixed in versions 1.11.7, 1.12.4, and 1.13.0.

Critical Impact
A compromised IPAM controller pod can read, modify, or delete Kubernetes Secrets in its namespace, exposing credentials and other sensitive workload data.

Affected Products

Metal3 ip-address-manager versions prior to 1.11.7
Metal3 ip-address-manager versions prior to 1.12.4 in the 1.12.x branch
Metal3 ip-address-manager 1.13.0 pre-releases (1.13.0-beta0, 1.13.0-rc0)

Discovery Timeline

2026-06-12 - CVE-2026-47190 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-47190

Vulnerability Analysis

The Metal3 IPAM controller runs inside a Kubernetes cluster and reconciles IP address claims for bare-metal nodes provisioned through Cluster API Provider Metal3. Controllers in Kubernetes operate under a ServiceAccount bound to a ClusterRole that defines API permissions. The IPAM controller's bundled ClusterRole granted unrestricted access to core/v1 Secrets across its operating namespace.

This configuration violates the principle of least privilege. The controller's reconciliation logic does not read, write, or watch Secret objects during normal operation. The permissions were therefore reachable only by an adversary who first obtained execution inside the controller pod.

An attacker leveraging a supply chain compromise or container escape inherits the pod's ServiceAccount token. With that token, the attacker can call the Kubernetes API to enumerate Secrets, exfiltrate credentials such as cloud provider keys or BMC passwords, and tamper with or delete Secret objects to disrupt other workloads.

Root Cause

The root cause is an over-broad RBAC grant in the IPAM controller manifest. The generated ClusterRole included all verbs on the secrets resource without a corresponding code path that required the access. This is a classic CWE-250 execution-with-unnecessary-privileges weakness in a Kubernetes operator.

Attack Vector

Exploitation requires the attacker to first achieve code execution inside the IPAM controller pod. Plausible primitives include a malicious or backdoored container image pulled through a supply chain attack, exploitation of a separate vulnerability in the controller process, or a container breakout from a co-located workload. Once inside the pod, the attacker reads the mounted ServiceAccount token at /var/run/secrets/kubernetes.io/serviceaccount/token and authenticates to the API server to invoke verbs such as get, list, patch, and delete on Secrets.

The vulnerability does not provide an initial access primitive on its own. It functions as a post-compromise privilege amplifier that converts pod-level execution into namespace-wide Secret access. See the GitHub Security Advisory GHSA-49pm-43hf-6xfq for additional details.

Detection Methods for CVE-2026-47190

Indicators of Compromise

Kubernetes audit log entries showing the IPAM controller ServiceAccount performing get, list, watch, patch, update, create, or delete actions on the secrets resource.
Unexpected API requests originating from the IPAM controller pod IP that target endpoints outside the IPAM custom resource group.
Modifications or deletions of Secret objects in namespaces hosting the Metal3 IPAM controller without a corresponding change-management record.

Detection Strategies

Enable Kubernetes audit logging at Metadata level or higher for the secrets resource and alert on access by the IPAM controller ServiceAccount.
Run RBAC posture tools such as kubectl-who-can, rakkess, or kubescape to flag any ClusterRole or Role that grants Secret verbs to controllers that do not require them.
Correlate pod-level process telemetry with API server activity to identify token reuse from unexpected processes inside the controller pod.

Monitoring Recommendations

Forward Kubernetes audit logs and kube-apiserver events into a centralized SIEM or data lake for retention and behavioral analytics.
Baseline the IPAM controller's normal API verbs and resources, then alert on deviations such as any Secret access.
Monitor container runtime events for shell spawns, package installs, or outbound network connections originating from the IPAM controller container.

How to Mitigate CVE-2026-47190

Immediate Actions Required

Upgrade the Metal3 ip-address-manager to version 1.11.7, 1.12.4, or 1.13.0, matching the release branch in use.
Rotate any Kubernetes Secrets that resided in namespaces where a vulnerable IPAM controller was deployed if compromise is suspected.
Audit Kubernetes audit logs retroactively for Secret access by the IPAM controller ServiceAccount since deployment.

Patch Information

The Metal3 project removed the unnecessary Secret permissions from the IPAM controller's ClusterRole in pull requests #1355, #1356, and #1357. Patched versions are 1.11.7, 1.12.4, and 1.13.0. Refer to GHSA-49pm-43hf-6xfq for the full advisory.

Workarounds

Apply an out-of-band ClusterRole patch that removes the secrets resource entry from the IPAM controller role until the upgrade can be scheduled.
Enforce a Kubernetes admission policy using ValidatingAdmissionPolicy, OPA Gatekeeper, or Kyverno to deny Secret operations from the IPAM controller ServiceAccount.
Restrict the controller to a dedicated namespace and apply a NetworkPolicy plus pod security standards to limit lateral movement after any container compromise.

bash

# Configuration example: remove Secret permissions from the IPAM controller ClusterRole
kubectl patch clusterrole ipam-manager-role --type=json \
  -p='[{"op": "remove", "path": "/rules", "value": [{"apiGroups": [""], "resources": ["secrets"]}]}]'

# Verify the controller ServiceAccount no longer has Secret verbs
kubectl auth can-i --list \
  --as=system:serviceaccount:metal3-system:ipam-manager | grep secrets