CAPM3: cross-namespace auth bypass exposes K8s secrets — MEDIUM (GHSA-rf84-wr5g-m3rp)

Q: Is GHSA-rf84-wr5g-m3rp actively exploited?

No confirmed active exploitation of GHSA-rf84-wr5g-m3rp has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-rf84-wr5g-m3rp?

1. Patch: Upgrade to v1.13.0 (all four fixes), v1.12.5 (all four fixes backported), or v1.11.8 (three of four fixes — Metal3DataClaim template restriction not applicable). 2. RBAC audit: Identify all principals with create/update rights on Metal3Machine and Metal3DataClaim; restrict to trusted infrastructure operators only. 3. Admission policies: Deploy OPA/Gatekeeper or Kyverno constraints that reject CAPM3 resources specifying secret references or BareMetalHost annotations pointing outside their own namespace. 4. Detection: Enumerate existing Metal3Machine and Metal3DataClaim resources across all namespaces for cross-namespace references (check secretRef.namespace fields and host annotations in namespace/name format). 5. Defence-in-depth: Apply network policies to limit egress from CAPM3 controller pods as blast-radius containment.

Q: What systems are affected by GHSA-rf84-wr5g-m3rp?

This vulnerability affects the following AI/ML architecture patterns: Kubernetes bare-metal provisioning, Multi-tenant Kubernetes management clusters, AI/ML compute infrastructure provisioning.

Q: What is the CVSS score for GHSA-rf84-wr5g-m3rp?

GHSA-rf84-wr5g-m3rp has a CVSS v3.1 base score of 5.5 (MEDIUM).

CISO Take

Four authorization flaws in Cluster API Provider Metal3 allow any user with infrastructure-admin RBAC rights in one Kubernetes namespace to read bootstrap secrets, claim BareMetalHost resources, and access data templates belonging to other namespaces on the same management cluster. The CVSS is 5.5 (Medium), high privileges are required, there is no public exploit code, and the vulnerability is absent from CISA KEV — meaning opportunistic external exploitation is unlikely and the real risk is insider threat or lateral movement after initial compromise of an operator account. In multi-tenant environments where separate teams or customers share a single CAPM3 management cluster (MSP or platform-team scenarios), the blast radius extends to cross-tenant credential disclosure including bootstrap and network provisioning secrets. Upgrade to v1.13.0, v1.12.5, or v1.11.8; as an immediate workaround, deploy OPA/Gatekeeper or Kyverno policies that reject Metal3Machine and Metal3DataClaim resources containing cross-namespace references.

Sources: GitHub Advisory ATLAS NVD

What is the risk?

Medium risk overall, elevated in multi-tenant Kubernetes infrastructure deployments. Exploitation is constrained by the requirement for existing RBAC create/modify rights on Metal3Machine or Metal3DataClaim — effectively infrastructure-operator privileges — which limits the attack surface to insiders or accounts already compromised at operator level. Single-tenant environments (the predominant CAPM3 deployment model) face a defence-in-depth gap rather than a directly exploitable escalation path. The highest-risk configuration is an MSP or shared-platform scenario where namespaces represent different customers or teams with different trust levels, where these flaws collapse namespace isolation entirely.

Attack Kill Chain

Initial Access

Attacker holds or acquires RBAC permissions to create or modify Metal3Machine or Metal3DataClaim resources in at least one namespace on the shared CAPM3 management cluster.

AML.T0012

Exploitation

Attacker crafts a malicious Metal3Machine with cross-namespace secret references (userData/metaData/networkData) or a host annotation in namespace/name format pointing to a BareMetalHost in a target tenant namespace.

Unauthorized Resource Access

The CAPM3 controller reconciles the crafted resource and fetches secrets and BareMetalHost objects from the target namespace without validating that the reference stays within the originating namespace.

AML.T0055

Impact

Attacker obtains cross-tenant bootstrap credentials, network provisioning metadata, and BareMetalHost control, enabling lateral movement to AI compute nodes provisioned for other tenants.

AML.T0025

Initial Access

Attacker holds or acquires RBAC permissions to create or modify Metal3Machine or Metal3DataClaim resources in at least one namespace on the shared CAPM3 management cluster.

AML.T0012

Exploitation

Attacker crafts a malicious Metal3Machine with cross-namespace secret references (userData/metaData/networkData) or a host annotation in namespace/name format pointing to a BareMetalHost in a target tenant namespace.

Unauthorized Resource Access

The CAPM3 controller reconciles the crafted resource and fetches secrets and BareMetalHost objects from the target namespace without validating that the reference stays within the originating namespace.

AML.T0055

Impact

Attacker obtains cross-tenant bootstrap credentials, network provisioning metadata, and BareMetalHost control, enabling lateral movement to AI compute nodes provisioned for other tenants.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
github.com/metal3-io/cluster-api-provider-metal3	go	<= 1.11.7	`1.11.8`
2.5K Pushed 6d ago 100% patched ~1d to patch Full package profile →

Do you use github.com/metal3-io/cluster-api-provider-metal3? You're affected.

Severity & Risk

CVSS 3.1

5.5 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

Attack Surface

AV Network

AC Low

PR High

UI None

S Changed

C Low

I Low

A None

What should I do?

5 steps

Patch: Upgrade to v1.13.0 (all four fixes), v1.12.5 (all four fixes backported), or v1.11.8 (three of four fixes — Metal3DataClaim template restriction not applicable).
RBAC audit: Identify all principals with create/update rights on Metal3Machine and Metal3DataClaim; restrict to trusted infrastructure operators only.
Admission policies: Deploy OPA/Gatekeeper or Kyverno constraints that reject CAPM3 resources specifying secret references or BareMetalHost annotations pointing outside their own namespace.
Detection: Enumerate existing Metal3Machine and Metal3DataClaim resources across all namespaces for cross-namespace references (check secretRef.namespace fields and host annotations in namespace/name format).
Defence-in-depth: Apply network policies to limit egress from CAPM3 controller pods as blast-radius containment.

Classification

Auth Bypass Data Leakage Framework AML.T0012 - Valid Accounts AML.T0025 - Exfiltration via Cyber Means AML.T0055 - Unsecured Credentials

Compliance Impact

This CVE is relevant to:

EU AI Act

Art.15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2 - Access control for AI systems

NIST AI RMF

GOVERN-6.1 - Organizational risk policies and procedures

Frequently Asked Questions

What is GHSA-rf84-wr5g-m3rp?

Four authorization flaws in Cluster API Provider Metal3 allow any user with infrastructure-admin RBAC rights in one Kubernetes namespace to read bootstrap secrets, claim BareMetalHost resources, and access data templates belonging to other namespaces on the same management cluster. The CVSS is 5.5 (Medium), high privileges are required, there is no public exploit code, and the vulnerability is absent from CISA KEV — meaning opportunistic external exploitation is unlikely and the real risk is insider threat or lateral movement after initial compromise of an operator account. In multi-tenant environments where separate teams or customers share a single CAPM3 management cluster (MSP or platform-team scenarios), the blast radius extends to cross-tenant credential disclosure including bootstrap and network provisioning secrets. Upgrade to v1.13.0, v1.12.5, or v1.11.8; as an immediate workaround, deploy OPA/Gatekeeper or Kyverno policies that reject Metal3Machine and Metal3DataClaim resources containing cross-namespace references.

Is GHSA-rf84-wr5g-m3rp actively exploited?

No confirmed active exploitation of GHSA-rf84-wr5g-m3rp has been reported, but organizations should still patch proactively.

How to fix GHSA-rf84-wr5g-m3rp?

1. Patch: Upgrade to v1.13.0 (all four fixes), v1.12.5 (all four fixes backported), or v1.11.8 (three of four fixes — Metal3DataClaim template restriction not applicable). 2. RBAC audit: Identify all principals with create/update rights on Metal3Machine and Metal3DataClaim; restrict to trusted infrastructure operators only. 3. Admission policies: Deploy OPA/Gatekeeper or Kyverno constraints that reject CAPM3 resources specifying secret references or BareMetalHost annotations pointing outside their own namespace. 4. Detection: Enumerate existing Metal3Machine and Metal3DataClaim resources across all namespaces for cross-namespace references (check secretRef.namespace fields and host annotations in namespace/name format). 5. Defence-in-depth: Apply network policies to limit egress from CAPM3 controller pods as blast-radius containment.

What systems are affected by GHSA-rf84-wr5g-m3rp?

This vulnerability affects the following AI/ML architecture patterns: Kubernetes bare-metal provisioning, Multi-tenant Kubernetes management clusters, AI/ML compute infrastructure provisioning.

What is the CVSS score for GHSA-rf84-wr5g-m3rp?

GHSA-rf84-wr5g-m3rp has a CVSS v3.1 base score of 5.5 (MEDIUM).

AI Security Impact

Affected AI Architectures

Kubernetes bare-metal provisioningMulti-tenant Kubernetes management clustersAI/ML compute infrastructure provisioning

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0025 Exfiltration via Cyber Means

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Art.15

ISO 42001: A.6.2

NIST AI RMF: GOVERN-6.1

Technical Details

Original Advisory

## Summary CAPM3 is Metal3's Cluster API (CAPI) provider for baremetal provisioning in Kubernetes. Multiple cross-namespace access control vulnerabilities in Cluster API Provider Metal3 allow users with permissions to create or modify CAPM3 resources in one namespace to reference, read, or claim resources belonging to other namespaces. ## Patched In - **v1.13.0** (main branch — all fixes included) - **v1.12.5** (all four fixes backported) - **v1.11.8** (three of four fixes backported; Metal3DataClaim template restriction not applicable due to missing v1beta2 webhook infrastructure) ## Description Four related vulnerabilities were identified and fixed: ### 1. Cross-namespace Secret references in Metal3Machine Metal3Machine resources accepted userData, metaData, and networkData secret references pointing to arbitrary namespaces. A user could configure a Metal3Machine to reference secrets in namespaces they do not have access to, and the controller would fetch and use those secrets. ### 2. Cross-namespace BareMetalHost lookups The host annotation on Metal3Machine could include a namespace/name format, causing the controller to look up BareMetalHost resources in arbitrary namespaces. This allowed a user to claim or associate with BareMetalHosts belonging to other tenants. ### 3. Incorrect logical operator in ConsumerRef validation The Metal3LabelSync controller used AND logic (&&) when validating BareMetalHost ConsumerRef Kind and Group, meaning it only rejected a ConsumerRef when both Kind and Group were wrong. If only one was incorrect (e.g., wrong Kind but correct Group), the validation passed, potentially allowing unauthorized resources to associate with a BareMetalHost. ### 4. Cross-namespace Metal3DataTemplate references Metal3DataClaim resources could reference Metal3DataTemplate resources in other namespaces. The controller would reconcile using the referenced template regardless of namespace, allowing data leakage across namespace boundaries. ## Impact These vulnerabilities allow cross-namespace resource access within the CAPM3 management cluster. A user with permissions to create or modify Metal3Machine or Metal3DataClaim resources in one namespace could reference secrets, BareMetalHosts, or data templates in other namespaces. Practical impact is limited because: - CAPM3 management clusters are typically single-tenant, operated by a single infrastructure/platform team. Namespace boundaries serve as organizational separation (e.g., per workload cluster), not as security isolation between mutually untrusted parties. - Exploiting these issues requires RBAC permissions to create or modify CAPM3 infrastructure resources (Metal3Machine, Metal3DataClaim), which are infrastructure-admin privileges not granted to application developers or end users. - The accessible resources are limited to Metal3 operational artifacts (bootstrap secrets, network metadata, BareMetalHost associations), not arbitrary cluster secrets. Environments with elevated risk: - Management clusters where namespace-scoped RBAC is used to delegate infrastructure provisioning to separate teams with different trust levels. - Managed service providers using a shared management cluster across multiple customer namespaces. In the common single-team deployment model, these issues represent a defense-in-depth gap rather than a directly exploitable privilege escalation. ### Prerequisites for exploitation - Attacker must have RBAC permissions to create or modify Metal3Machine or Metal3DataClaim resources in at least one namespace. - Target resources (secrets, BareMetalHosts, templates) must exist in other namespaces on the same management cluster. ## Workarounds If upgrading is not immediately possible: 1. Restrict RBAC: Limit who can create/modify Metal3Machine and Metal3DataClaim resources to trusted operators only. 2. Admission policies: Deploy OPA/Gatekeeper or Kyverno policies that reject CAPM3 resources with cross-namespace references. 3. Network policies: While not a direct mitigation, network policies can limit the blast radius of compromised credentials. ## Resources - https://github.com/metal3-io/cluster-api-provider-metal3/pull/3288, https://github.com/metal3-io/cluster-api-provider-metal3/pull/3294 - https://github.com/metal3-io/cluster-api-provider-metal3/pull/3317, https://github.com/metal3-io/cluster-api-provider-metal3/pull/3319, https://github.com/metal3-io/cluster-api-provider-metal3/pull/3323 - https://github.com/metal3-io/cluster-api-provider-metal3/pull/3322, https://github.com/metal3-io/cluster-api-provider-metal3/pull/3325 - https://github.com/metal3-io/cluster-api-provider-metal3/pull/3327, https://github.com/metal3-io/cluster-api-provider-metal3/pull/3343, https://github.com/metal3-io/cluster-api-provider-metal3/pull/3344

Exploitation Scenario

An attacker who has compromised an infrastructure operator account with RBAC rights to create Metal3Machine objects in namespace 'team-a' crafts a malicious Metal3Machine: the host annotation is set to 'team-b/gpu-node-01' and the userData secretRef namespace is set to 'team-b/bootstrap-creds'. When the CAPM3 controller reconciles this resource it fetches the bootstrap secret from namespace 'team-b' and associates with 'team-b's BareMetalHost — all without the attacker holding any direct RBAC rights in 'team-b'. In a parallel step the attacker creates a Metal3DataClaim referencing a Metal3DataTemplate in 'team-b', extracting network provisioning metadata. Combined, this provides credentials and network access for infrastructure belonging to a separate tenant, enabling lateral movement to AI compute nodes provisioned for that tenant.