CVE-2025-29781 in baremetal-operator
Summary
by MITRE • 03/18/2025
The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. Baremetal Operator enables users to load Secret from arbitrary namespaces upon deployment of the namespace scoped Custom Resource `BMCEventSubscription`. Prior to versions 0.8.1 and 0.9.1, an adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a `BMCEventSubscription` in his authorized namespace and then load Secrets from his unauthorized namespaces to his authorized namespace via the Baremetal Operator, causing Secret Leakage. The patch makes BMO refuse to read Secrets from other namespace than where the corresponding BMH resource is. The patch does not change the `BMCEventSubscription` API in BMO, but stricter validation will fail the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES CR has already been deployed. The issue exists for all versions of BMO, and is patched in BMO releases v0.9.1 and v0.8.1. Prior upgrading to patched BMO version, duplicate any existing Secret pointed to by `BMCEventSubscription`'s `httpHeadersRef` to the same namespace where the corresponding BMH exists. After upgrade, remove the old Secrets. As a workaround, the operator can configure BMO RBAC to be namespace scoped, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces, and/or use `WATCH_NAMESPACE` configuration option to limit BMO to single namespace.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/18/2025
The Bare Metal Operator BMO presents a critical privilege escalation vulnerability through improper secret access controls within its BMCEventSubscription custom resource implementation. This vulnerability affects the Metal3 bare metal management framework where BMO serves as a Kubernetes API controller for managing physical hardware resources. The flaw exists in how the operator handles secret references within the BMCEventSubscription resource, allowing unauthorized namespace access patterns that bypass standard Kubernetes RBAC controls. The vulnerability stems from the operator's failure to validate namespace boundaries when processing secret references, creating an avenue for tenants to access sensitive information across namespace boundaries.
The technical implementation of this vulnerability occurs through the namespace-scoped Custom Resource Definition BMCEventSubscription which references secrets through the httpHeadersRef field. When an attacker with namespace-level privileges creates a BMCEventSubscription resource, the operator's admission controller fails to properly validate that referenced secrets exist within the same namespace as the corresponding BareMetalHost resource. This validation gap enables the operator to inadvertently load secrets from unauthorized namespaces into the attacker's namespace, effectively creating a cross-namespace secret leakage mechanism. The vulnerability is classified under CWE-284 Access Control Bypass and aligns with ATT&CK technique T1565.001 Credential Access: Steal Application Access Token, representing a direct compromise of secret management controls.
The operational impact of this vulnerability extends beyond simple information disclosure to potentially enable more sophisticated attacks including credential theft, service account token harvesting, and lateral movement within multi-tenant Kubernetes environments. Attackers can exploit this weakness to gain access to secrets containing database credentials, API keys, cloud provider tokens, and other sensitive information stored in different namespaces. The vulnerability affects all versions of BMO prior to 0.8.1 and 0.9.1, making it a persistent threat across multiple release lines. The patch implementation addresses this by enforcing namespace boundary validation at admission control time and preventing controller-level secret reading from unauthorized namespaces, effectively closing the access control gap.
The remediation strategy requires careful planning and execution to prevent service disruption during the upgrade process. Organizations must first duplicate any existing secrets referenced by BMCEventSubscription resources to the appropriate namespace where the corresponding BareMetalHost exists, ensuring continued functionality after the patch is applied. The upgrade to patched versions v0.8.1 or v0.9.1 represents the primary mitigation approach, as these releases implement strict namespace validation that prevents the problematic secret loading behavior. Alternative workarounds include configuring BMO with namespace-scoped RBAC permissions and utilizing the WATCH_NAMESPACE environment variable to restrict the operator's scope to single namespaces, effectively limiting its access capabilities. These measures align with security best practices for containerized applications and help prevent similar privilege escalation scenarios in other Kubernetes controllers. The vulnerability demonstrates the critical importance of validating resource references and implementing proper namespace boundaries in multi-tenant Kubernetes environments where security isolation is paramount.