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.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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. (CVE-2024-43803)

The remote SUSE Linux SLES15 / openSUSE 15 host has a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:0060-1 advisory.

    - Update to version 0.0.20250108T191942 2025-01-08T19:19:42Z.
      Refs jsc#PED-11136       Go CVE Numbering Authority IDs added or updated with aliases:
      * GO-2025-3371 GHSA-2r2v-9pf8-6342
      * GO-2025-3374 CVE-2025-22130 GHSA-j4jw-m6xr-fv6c

    - Update to version 0.0.20250107T160406 2025-01-07T16:04:06Z.
      Refs jsc#PED-11136       Go CVE Numbering Authority IDs added or updated with aliases:
      * GO-2025-3363 GO-2025-3364 GO-2025-3367 GO-2025-3368
      * GO-2024-3355 CVE-2024-54148 GHSA-r7j8-5h9c-f6fx
      * GO-2024-3356 CVE-2024-55947 GHSA-qf5v-rp47-55gg
      * GO-2024-3357 CVE-2024-56362 GHSA-xwx7-p63r-2rj8
      * GO-2024-3358 CVE-2024-45387 GHSA-vq94-9pfv-ccqr
      * GO-2024-3359 CVE-2024-28892 GHSA-5qww-56gc-f66c
      * GO-2024-3360 CVE-2024-25133 GHSA-wgqq-9qh8-wvqv
      * GO-2025-3361 CVE-2024-55196 GHSA-rv83-h68q-c4wq
      * GO-2025-3362 CVE-2025-21609 GHSA-8fx8-pffw-w498
      * GO-2025-3363 CVE-2024-56514 GHSA-cwrh-575j-8vr3
      * GO-2025-3364 CVE-2024-56513 GHSA-mg7w-c9x2-xh7r
      * GO-2025-3367 CVE-2025-21614 GHSA-r9px-m959-cxf4
      * GO-2025-3368 CVE-2025-21613 GHSA-v725-9546-7q7m

    - Update to version 0.0.20241220T214820 2024-12-20T21:48:20Z.
      Refs jsc#PED-11136       Go CVE Numbering Authority IDs added or updated with aliases:
      * GO-2024-3101 GHSA-75qh-gg76-p2w4
      * GO-2024-3339 GHSA-8wcc-m6j2-qxvm

    - Update to version 0.0.20241220T203729 2024-12-20T20:37:29Z.
      Refs jsc#PED-11136       Go CVE Numbering Authority IDs added or updated with aliases:
      * GO-2024-3101 GHSA-75qh-gg76-p2w4
      * GO-2024-3109 CVE-2024-43803 GHSA-pqfh-xh7w-7h3p
      * GO-2024-3333 CVE-2024-45338 GHSA-w32m-9786-jp63
      * GO-2024-3342 GHSA-hxr6-2p24-hf98
      * GO-2024-3343 CVE-2024-9779 GHSA-jhh6-6fhp-q2xp
      * GO-2024-3344 GHSA-32gq-x56h-299c
      * GO-2024-3349 CVE-2024-25131 GHSA-77c2-c35q-254w
      * GO-2024-3350 GHSA-5pf6-cq2v-23ww
      * GO-2024-3354 CVE-2024-12678 GHSA-hr68-hvgv-xxqf

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
417659	SCA: security update for github.com/metal3-io/baremetal-operator (GHSA-pqfh-xh7w-7h3p)	Tenable Cloud Security	SCA Checks	medium
417659	SCA: security update for github.com/metal3-io/baremetal-operator (GHSA-pqfh-xh7w-7h3p)	Tenable Self-Hosted Container Security	SCA Checks	medium
213966	SUSE SLES15 / openSUSE 15 Security Update : govulncheck-vulndb (SUSE-SU-2025:0060-1)	Nessus	SuSE Local Security Checks	critical

Detections

Analytics

CVE-2024-43803

medium

Tenable Plugins

medium

medium

critical