Skip to content
Fencer Vulns
medium 4.9

CVE-2024-43803 json

BMO can expose particularly named secrets from other namespaces via BMH CRD

published 2024-09-03 2 y ago modified 2026-06-17 4 mo ago also EUVD-2024-2846 , GHSA-pqfh-xh7w-7h3p , GO-2024-3109

cvss
4.9
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.6%
EPSS 0.6% chance of exploitation in 30 days, percentile 47%
public exploits
0
none known

Summary

The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The `BareMetalHost` (BMH) CRD allows the `userData`, `metaData`, and `networkData` for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the `Name` and `Namespace` of the Secret, meaning that versions of the baremetal-operator prior to 0.8.0, 0.6.2, and 0.5.2 will read a `Secret` from any namespace. A user with access to create or edit a `BareMetalHost` can thus exfiltrate a `Secret` from another namespace by using it as e.g. the `userData` for provisioning some host (note that this need not be a real host, it could be a VM somewhere).

BMO will only read a key with the name `value` (or `userData`, `metaData`, or `networkData`), so that limits the exposure somewhat. `value` is probably a pretty common key though. Secrets used by _other_ `BareMetalHost`s in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a `BareMetalHost`. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.

The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only. The problem is patched in BMO releases v0.7.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets. As a workaround, an operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.

Patch / fix

  • go github.com/metal3-io/baremetal-operator 0.5.2, 0.6.2, 0.8.0
  • linuxfoundation baremetal_operator 0.5.2, 0.6.2, 0.8.0
  • govulncheck-vulndb SLE Module for Package Hub 15 SP6, openSUSE Leap 15.6 0.0.20250108T191942-150000.1.26.1

suse advisories SUSE-SU-2025:0060-1

  • govulncheck-vulndb openSUSE Tumbleweed 0.0.20241220T214820-1.1

opensuse advisories openSUSE-SU-2024:14608-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2024-43803 updated cvss 4.9

Bare Metal Operator: BMO can expose particularly named secrets from other namespaces via BMH CRD

  • Red Hat OpenShift Container Platform 4.16 openshift4/ose-baremetal-rhel9-operator v4.16.0-202409121637.p0.gae55a70.assembly.stream.el9
    fixed: vendor fix “The Operator can configure BMO RBAC to be the namespace scoped for Secrets, instead of the cluster scoped to prevent BMO from accessing Secrets from other namespaces.” RHSA-2024:6824
  • Red Hat OpenShift Container Platform 4.18 rhcos 418.94.202502100215-0, openshift4/frr-rhel9 v4.18.0-202502041302.p0.g1ad8f2e.assembly.stream.el9, openshift4/ose-cli-rhel9 v4.18.0-202502040032.p0.ga50d4c0.assembly.stream.el9, openshift4/ose-pod-rhel9 v4.18.0-202502051032.p0.gacb9630.assembly.stream.el9, openshift4/ose-etcd-rhel9 v4.18.0-202501230001.p0.g914783c.assembly.stream.el9, openshift4/ose-tests-rhel9 v4.18.0-202502110432.p0.g0c7bed9.assembly.stream.el9, +184 more
    fixed: vendor fix “The Operator can configure BMO RBAC to be the namespace scoped for Secrets, instead of the cluster scoped to prevent BMO from accessing Secrets from other namespaces.” RHSA-2024:6122
  • Red Hat OpenShift Container Platform 4.16 rhcos 416.94.202409181502-0, openshift4/ose-sdn-rhel9 v4.16.0-202409120034.p0.g5b658c4.assembly.stream.el9, openshift4/ose-tests-rhel9 v4.16.0-202409180404.p0.g06403d4.assembly.stream.el9, openshift4/ose-tools-rhel9 v4.16.0-202409180404.p0.gc44c839.assembly.stream.el9, openshift4/ose-ironic-rhel9 v4.16.0-202409181436.p0.ge670fd3.assembly.stream.el9, openshift4/ose-console-rhel9 v4.16.0-202409181705.p0.g0b1616c.assembly.stream.el9, +25 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
2 y ago

Exploit prediction

0.57% chance of exploitation in the next 30 days, higher than 47% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CNA 3.1 4.9 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
GitHub 3.1 4.9 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N

Affected packages

ecosystem package affected fixed in
go github.com/metal3-io/baremetal-operator
>=0.7.0-rc.0, <0.8.0
>=0.6.0, <0.6.2
<0.5.2
0.8.0
0.6.2
0.5.2

Affected products

  • metal3-io baremetal-operator

Classification

Weakness
  • CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
  • CWE-653 Improper Isolation or Compartmentalization

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

CPEs and fixed versions use Anchore's correction of NVD's data: Added CPE configurations because not yet analyzed by NVD.