GHSA-C98H-7HP9-V9HQ
Vulnerability from github – Published: 2025-03-17 21:26 – Updated: 2025-03-19 14:59Impact
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 (BMCES). An adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a BMCES in their authorized namespace and then load Secrets from their unauthorized namespaces to their authorized namespace via the Baremetal Operator controller's cluster scoped privileges, causing Secret leakage.
Patches
The patch makes BMO refuse to read Secrets from other namespace than where the corresponding Bare Metal Host (BMH) resource is. The patch does not change the BMCEventSubscription API in BMO, but stricter validation will deny the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES resource 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.
Workarounds
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.
References
Credits
Metal3 Security Team thanks WHALEEYE and debuggerchen of Lab for Internet and Security Technology for responsible vulnerability disclosure.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/metal3-io/baremetal-operator/apis"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.9.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.9.0"
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/metal3-io/baremetal-operator/apis"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-29781"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-653"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-17T21:26:14Z",
"nvd_published_at": "2025-03-17T22:15:14Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nThe Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. \n\nBaremetal Operator enables users to load Secret from arbitrary namespaces upon deployment of the namespace scoped Custom Resource `BMCEventSubscription` (BMCES). An adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a BMCES in their authorized namespace and then load Secrets from their unauthorized namespaces to their authorized namespace via the Baremetal Operator controller\u0027s cluster scoped privileges, causing Secret leakage.\n\n### Patches\n\nThe patch makes BMO refuse to read Secrets from other namespace than where the corresponding Bare Metal Host (BMH) resource is. The patch does not change the `BMCEventSubscription` API in BMO, but stricter validation will deny the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES resource has already been deployed.\n\nThe 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`\u0027s `httpHeadersRef` to the same namespace where the corresponding BMH exists. After upgrade, remove the old Secrets.\n\n### Workarounds\n\nOperator 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.\n\n### References\n\n- [patch to main](https://github.com/metal3-io/baremetal-operator/commit/19f8443b1fe182f76dd81b43122e8dd102f8b94c)\n- [patch to release-0.9](https://github.com/metal3-io/baremetal-operator/pull/2321)\n- [patch to release-0.8](https://github.com/metal3-io/baremetal-operator/pull/2322)\n- [BMCEventSubscription design document](https://github.com/metal3-io/metal3-docs/blob/main/design/baremetal-operator/bmc-events.md)\n\n### Credits\n\nMetal3 Security Team thanks [WHALEEYE](https://github.com/WHALEEYE) and [debuggerchen](https://github.com/debuggerchen) of [Lab for Internet and Security Technology](https://users.cs.northwestern.edu/~list/) for responsible vulnerability disclosure.",
"id": "GHSA-c98h-7hp9-v9hq",
"modified": "2025-03-19T14:59:19Z",
"published": "2025-03-17T21:26:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/metal3-io/baremetal-operator/security/advisories/GHSA-c98h-7hp9-v9hq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29781"
},
{
"type": "WEB",
"url": "https://github.com/metal3-io/baremetal-operator/pull/2321"
},
{
"type": "WEB",
"url": "https://github.com/metal3-io/baremetal-operator/pull/2322"
},
{
"type": "WEB",
"url": "https://github.com/metal3-io/baremetal-operator/commit/19f8443b1fe182f76dd81b43122e8dd102f8b94c"
},
{
"type": "PACKAGE",
"url": "https://github.com/metal3-io/baremetal-operator"
},
{
"type": "WEB",
"url": "https://github.com/metal3-io/metal3-docs/blob/main/design/baremetal-operator/bmc-events.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Bare Metal Operator (BMO) can expose any secret from other namespaces via BMCEventSubscription CRD"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.