Most recent entries from all

EUVD-2026-161194

fkie_cve-2024-43803

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…

GHSA-pqfh-xh7w-7h3p — The Bare Metal Operator (BMO) can expose particularly named secrets from other namespaces via BMH CRD

Affected: Go: github.com/metal3-io/baremetal-operator

### Impact 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 the baremetal-operator 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).

### Limiting factors 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.

### Patches 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.8.0, v0.6.2 and v0.5.2 and users should upgrade to thos…

openSUSE-SU-2024:14608-1 — govulncheck-vulndb-0.0.20241220T214820-1.1 on GA media

govulncheck-vulndb-0.0.20241220T214820-1.1 on GA media

RHSA-2024:6122 — Red Hat Security Advisory: OpenShift Container Platform 4.18.1 bug fix and security update

PostCSS: Improper input validation in PostCSS golang: net/http, x/net/http2: unlimited number of CONTINUATION frames causes DoS containers/image: digest type does not guarantee valid type go-retryablehttp: url might write sensitive information to log file openshift-console: OAuth2 insufficient state parameter entropy openshift/builder: Path traversal allows command injection in privileged BuildContainer using docker build strategy Podman: Buildah: cri-o: FIPS Crypto-Policy Directory Mounting Issue in containers/common Go Library pam: Improper Hostname Interpretation in pam_access Leads to Access Control Bypass rsync: Info Leak via Uninitialized Stack Contents ose-olm-catalogd-container: incomplete fix for rapid reset (CVE-2023-39325/CVE-2023-44487) cross-spawn: regular expression denial of service golang-protobuf: encoding/protojson, internal/encoding/json: infinite loop in protojson.Unmarshal when unmarshaling certain forms of invalid JSON axios: axios: Server-Side Request Forgery Bare Metal Operator: BMO can expose particularly named secrets from other namespaces via BMH CRD path-to-regexp: Backtracking regular expressions cause ReDoS golang.org/x/net/html: Non-linear parsing of case-insensitive content in golang.org/x/net/html openshift-controller-manager: Elevated Build Pods Can Lead to Node Compromise in OpenShift openstack-ironic: Lack of checksum validation on images dompurify: DOMPurify vulnerable to tampering by prototype pollution GraphQL: Denial of Service (DoS) v…

SUSE-SU-2025:0060-1 — Security update for govulncheck-vulndb

Security update for govulncheck-vulndb