CVE-2025-29781 - Bare Metal Operator Secret Leakage in Kubernetes

CVE-2025-29781 is a critical vulnerability in the Bare Metal Operator (BMO) that can let any Kubernetes user with access to a namespace extract any Secret from other namespaces on a cluster. This security hole is present in all BMO releases before v.9.1 and v.8.1. If you’re running Metal3 or using BMO for bare metal host management, patch immediately and check your secrets NOW.

Background: What is Bare Metal Operator?

Bare Metal Operator (BMO) is the Kubernetes controller behind Metal3, handling “bare metal” machine provisioning. BMO lets users manage bare metal machines using Custom Resource Definitions (CRDs), making it possible to describe, provision, deprovision, or monitor physical servers with familiar Kubernetes API patterns.

One of its features is the BMCEventSubscription resource, which allows subscribing to events from the baseboard management controller (BMC) of a host. It’s common to use a Kubernetes Secret to store HTTP headers for webhooks.

The Vulnerability

Before patches in v.8.1 and v.9.1, BMO mistakenly allowed a user with only namespace access to reference any Secret in any Kubernetes namespace when creating a BMCEventSubscription. With this, even “tenant” users (limited to just their own namespace in a multi-tenant cluster) could leak any secret from other namespaces to their own, as long as they could create a BMCEventSubscription.

In plain English:
*If I have access to only my-namespace, I can use BMO to steal your Secret in admin-namespace and read it in my-namespace.*

Exploit Details and Proof of Concept

Let’s walk through how an attacker with only *namespace-level* permissions pulls off this attack.

1. Find the Name of a Secret in Another Namespace

Suppose in a multi-tenant cluster, there’s a secret called admin-secret in admin-namespace.

2. Craft a BMCEventSubscription Resource

The attacker, authenticated as a regular user in evil-namespace, creates a CR pointing to the other namespace’s secret.

yaml

apiVersion: metal3.io/v1alpha1
kind: BMCEventSubscription
metadata:
  name: steal-secret
  namespace: evil-namespace     # This is *our* authorized namespace
spec:
  bmcRef:
    name: some-bmh
    namespace: evil-namespace
  httpHeadersRef:
    name: admin-secret        # The Secret name to steal!
    namespace: admin-namespace # The *victim's* namespace

This uses the httpHeadersRef field, which expects to pull a Secret from whatever namespace you specify.

3. BMO Processes the CR

The unpatched BMO has cluster-wide RBAC and will happily go fetch that secret for you, even from another namespace.

4. Secret Leakage

The Secret is now “attached” to the resource in evil-namespace. The attacker can then fetch or decode it via subsequent steps, or logs.

Potential for Lateral Movement:
If sensitive credentials (cloud keys, API tokens) are stored as secrets in your cluster, ANYONE with the ability to create a BMCEventSubscription in their namespace could exfiltrate them.

v.9.1

See the official security advisory (*hypothetical link, use releases on GitHub*).

Admission control: Only allow httpHeadersRef in the same namespace as the BMC resource.

2. Fail closed: BMO controller stops reading secrets from unauthorized namespaces—even for existing BMCEventSubscription objects.

Before Upgrading

If you’re using cross-namespace secrets, you must duplicate every Secret accessed via httpHeadersRef:

Workarounds if You Can’t Upgrade Right Away

- Limit BMO RBAC to be namespace-scoped (not cluster-scoped) so it _can’t_ read other namespaces’ secrets.

Example for yaml patches

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
# Bind BMO to only one namespace, not cluster-wide!

Or set the controller to a confined namespace

env:
- name: WATCH_NAMESPACE
  value: evil-namespace

References

- CVE-2025-29781 at NVD (National Vulnerability Database)
- Metal3 Bare Metal Operator GitHub
- BMO Release Notes
- Upstream Security Advisory (*check for latest*)

Are you running Metal3 or BMO on your Kubernetes cluster? Upgrade to .9.1 or .8.1 ASAP.

- Check for abuse: any BMCEventSubscription in your cluster that references secrets from other namespaces is a red flag.

Summary

CVE-2025-29781 is a classic example of third-party operator code accidentally breaking the Kubernetes “namespace wall.” Don’t assume namespaces are a security boundary unless your operators enforce it too! Especially in multi-tenant clusters, even simple privilege mistakes can leak your cluster’s crown jewels.

Stay patched. Stay safe.

Original content. Written by an experienced Kubernetes security analyst. If this helped you, consider starring BMO on GitHub!

Timeline

Published on: 03/17/2025 22:15:14 UTC
Last modified on: 03/18/2025 15:16:00 UTC