Metal3 IPAM EUVD-2026-36463

Exploitation requires the attacker to have already achieved code execution within the metal3-ipam-controller-manager pod - for example via a supply chain compromise of the ip-address-manager binary or a container escape from an adjacent pod on the same node. No special configuration of the IPAM controller is required beyond the default deployment, since the overly permissive ClusterRole is shipped as the default in all affected versions. Exploitation is bounded by Kubernetes namespace scope: the attacker can access Secrets only within the namespace where the controller is deployed, not cluster-wide across all namespaces. CVSS PR:H confirms authentication-equivalent access (service account token) is a prerequisite; CVSS AC:H confirms the prior compromise step adds meaningful complexity. Defenders can assess realistic exposure by auditing how many sensitive Secrets co-exist in the IPAM controller's namespace.

The CVSS 4.4 Medium score is appropriate for the vulnerability's nature as a privilege-amplification risk rather than a direct-exploitation path. The CVSS vector AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N reflects that exploitation requires high privilege (PR:H - the attacker must already control the controller pod) and high complexity (AC:H - container escape or supply chain compromise is a prerequisite). The C:H impact score is well-justified: full read access to cluster Secrets can expose service account tokens, TLS certificates, and other credentials. No EPSS data is provided, no CISA KEV listing, and no public exploit code has been identified, placing this in a realistic 'low urgency but meaningful blast-radius risk' category. The primary threat model is defense-in-depth failure: this vulnerability does not enable initial access but meaningfully expands attacker capability post-compromise. Teams running IPAM in high-value clusters alongside sensitive Secrets should treat this as higher priority than the raw CVSS score suggests.

An attacker compromises the IPAM controller pod - for example, by injecting a malicious dependency via a supply chain attack against the Go module, or by escaping a co-located container on the same Kubernetes node. Once code execution is achieved within the controller pod, the attacker uses the mounted service account token to call the Kubernetes API, invoking list and get on Secrets in the namespace to harvest credentials, certificates, and tokens used by other cluster components. No public proof-of-concept code exists for this specific CVE; exploitation relies on the attacker first achieving pod-level code execution through a separate vector.