CVE-2026-47190: Metal3 IPAM Excessive Secret Permissions Vulnerability
IPAM (IP Address Manager) for Cluster API Provider Metal3 granted its controller pod excessive permissions to read, modify, and delete Kubernetes Secrets—a capability it never uses during normal operation. If an attacker compromised the controller pod through a supply chain attack or container escape, they could exploit these overly broad permissions to steal sensitive credentials and other secret data stored in the cluster. This permission misconfiguration has been corrected in patched versions.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 4.4 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N
- Weaknesses (CWE)
- CWE-250
- Affected products
- 3 configuration(s)
- Published / Modified
- 2026-06-12 / 2026-06-17
NVD description (verbatim)
IPAM is the IP address Manager for Cluster API Provider Metal3. Prior to versions 1.11.7, 1.12.4, and 1.13.0, the IPAM controller's ClusterRole granted full CRUD permissions (create, delete, get, list, patch, update, watch) on core/v1 Secrets. The controller never accesses Secrets during normal operation. If the controller pod were compromised (e.g. via supply chain attack or container escape), an attacker could leverage these excessive permissions to read, modify, or delete Secrets in the namespace, potentially exposing credentials and other sensitive data. This issue has been patched in versions 1.11.7, 1.12.4, and 1.13.0.
4 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
The IPAM controller's ClusterRole defined in Kubernetes configured with full CRUD permissions (create, delete, get, list, patch, update, watch) on core/v1 Secrets across the namespace. The controller's actual codebase does not require Secret access during normal operation, making these permissions unnecessary and a violation of the principle of least privilege. An attacker with control of the controller pod—achievable through container compromise or supply chain injection—could directly interact with the Kubernetes API to enumerate and exfiltrate all Secrets in the namespace.
Business impact
Cluster credentials, application API keys, TLS certificates, and other sensitive data stored as Kubernetes Secrets could be exposed if the controller pod is compromised. This creates a cascading risk: attackers gaining Secret access could move laterally across applications, impersonate services, or establish persistent footholds. Organizations relying on this IPAM for bare-metal cluster management face potential credential theft affecting their entire Metal3 infrastructure.
Affected systems
Metal3 IP Address Manager versions prior to 1.11.7, 1.12.4, and 1.13.0 are affected. Any Kubernetes cluster using IPAM with the vulnerable ClusterRole is at risk, particularly environments where container image supply chains or pod execution contexts are less strictly controlled.
Exploitability
Exploitation requires prior compromise of the IPAM controller pod itself—a non-trivial prerequisite. However, once a pod is compromised (via supply chain attack, container escape, or malicious image injection), the excessive ClusterRole permissions make Secret enumeration and theft trivial for an attacker with API access. The CVSS score of 4.4 reflects this: meaningful impact (confidentiality breach) but a high bar for initial access.
Remediation
Upgrade to IPAM version 1.11.7, 1.12.4, or 1.13.0 or later. These versions restrict the controller's ClusterRole to only the permissions actually required for IP address management. After patching, verify the controller pod's ServiceAccount role bindings and confirm no custom overrides re-grant unnecessary Secret permissions.
Patch guidance
Plan updates within your normal Kubernetes maintenance windows. Since IPAM is a control-plane component for Metal3 clusters, test patches in non-production environments first. Verify cluster stability after the upgrade, particularly DNS and IP allocation functionality. No cluster downtime is typically required for this update, but monitor controller logs during rollout.
Detection guidance
Audit your current IPAM ClusterRole bindings using `kubectl get clusterrole -o yaml | grep -i ipam` and inspect the `rules` section for Secret permissions. Enable Kubernetes API audit logging and search for Secret access patterns (get, list, watch on secrets.core) originating from the IPAM controller's ServiceAccount. Review image provenance and container registry pull policies to detect unexpected controller pod image updates.
Why prioritize this
Although the CVSS score is moderate, this represents a dangerous permission misconfiguration affecting a trusted infrastructure component. Bare-metal cluster managers should prioritize patching because: (1) controller pods are attractive targets for supply chain attacks; (2) Secret exfiltration from a cluster controller has broad blast radius; (3) patches are readily available and low-risk. Organizations not yet at vulnerable versions should ensure their configuration management prevents this anti-pattern.
Risk score, explained
The CVSS 3.1 score of 4.4 (MEDIUM) accounts for high confidentiality impact (H) if the pod is compromised, but requires high attacker effort (H for AC—Attack Complexity) to first compromise the pod. The high privilege requirement (H for PR) reflects that only a compromised controller process can abuse these permissions. The score appropriately captures the severity of the capability gap rather than the overall exploit chain difficulty.
Frequently asked questions
Does upgrading IPAM require cluster downtime or IP address redistribution?
No. The patch only modifies the ClusterRole permissions; it does not change how IPAM allocates or manages IP addresses. A rolling update of the controller deployment is sufficient and does not disrupt running workloads.
What if our IPAM pod is already compromised? How do we detect Secret theft?
Review Kubernetes API audit logs for Secret access (get, list, watch, patch) from the IPAM controller's ServiceAccount around the compromise timeframe. Rotate all Secrets in affected namespaces proactively. Check your cluster's network egress logs for bulk data transfers that might indicate exfiltration.
We use Metal3 but never directly instantiate IPAM—could we still be affected?
If your cluster provisioning or Operator installation included IPAM in its control-plane components, you likely have the vulnerable ClusterRole bound. Verify by listing ClusterRoles and checking your cluster's Operator deployment specs against the IPAM version.
Does this vulnerability affect non-Metal3 Kubernetes clusters?
No. This vulnerability is specific to Metal3's IPAM controller. Standard Kubernetes distributions do not include this component.
This analysis is based on the vulnerability description and CVE metadata as of the publish date. No public exploit code is known to exist for this vulnerability. Organizations should verify patch availability and compatibility with their specific IPAM version and cluster configuration before applying updates. Always test patches in non-production environments first. For the most current vendor guidance, consult the official Metal3 security advisories and release notes. Source: NVD (public-domain), retrieved 2026-07-20. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-50565MEDIUMFission Kubernetes Service Account Token Exposure
- CVE-2025-12694HIGHForcepoint VPN Client Local Privilege Escalation (CVSS 7.8 HIGH)
- CVE-2026-10843HIGHOpenShift Cloud Credential Operator AWS IAM Over-Permissioning Vulnerability
- CVE-2026-42061HIGHAcronis DeviceLock DLP Local Privilege Escalation (CVSS 7.3)
- CVE-2026-46748HIGHSINEC INS Privilege Escalation via Excessive Linux Capabilities
- CVE-2016-20064MEDIUMWP Vault 0.8.6.6 Arbitrary File Read via Directory Traversal
- CVE-2016-20067MEDIUMWordPress CP Polls CSRF Vulnerability
- CVE-2016-20070MEDIUMPrivilege Escalation & Stored XSS in WordPress Booking Calendar Contact Form 1.0.23