{"id":"CVE-2024-43803","aliases":["EUVD-2024-2846","GHSA-pqfh-xh7w-7h3p","GO-2024-3109","SUSE-SU-2025:0060-1","openSUSE-SU-2024:14608-1"],"status":"published","title":"BMO can expose particularly named secrets from other namespaces via BMH CRD","description":"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).\n\nBMO 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.\n\nThe 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.","severity":{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00574,"percentile":0.47817,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-200","CWE-653"],"published":"2024-09-03T18:56:29Z","modified":"2026-10-28T02:30:51Z","fixes":[{"ecosystem":"Go","package":"github.com/metal3-io/baremetal-operator","fixed_in":["0.8.0","0.6.2","0.5.2"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/metal3-io/baremetal-operator","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.7.0-rc.0"},{"fixed":"0.8.0"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/metal3-io/baremetal-operator","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.6.0"},{"fixed":"0.6.2"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/metal3-io/baremetal-operator","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.5.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/metal3-io/baremetal-operator","ranges":[{"type":"SEMVER","events":[{"introduced":"0.7.0-rc.0"},{"fixed":"0.8.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/metal3-io/baremetal-operator","ranges":[{"type":"SEMVER","events":[{"introduced":"0.6.0"},{"fixed":"0.6.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/metal3-io/baremetal-operator","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.5.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/metal3-io/baremetal-operator","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.5.2"},{"introduced":"0.6.0"},{"fixed":"0.6.2"},{"introduced":"0.7.0-rc.0"},{"fixed":"0.8.0"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250108T191942-150000.1.26.1"}]}],"bundled":18},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250108T191942-150000.1.26.1"}]}],"bundled":18},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241220T214820-1.1"}]}],"bundled":4}],"products":[{"vendor":"metal3-io","product":"baremetal-operator"}],"references":[{"url":"https://github.com/metal3-io/baremetal-operator/security/advisories/GHSA-pqfh-xh7w-7h3p","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/metal3-io/baremetal-operator/pull/1929","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/metal3-io/baremetal-operator/pull/1930","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/metal3-io/baremetal-operator/pull/1931","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/metal3-io/baremetal-operator/commit/3af4882e9c5fadc1a7550f53daea21dccd271f74","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/metal3-io/baremetal-operator/commit/bedae7b997d16f36e772806681569bb8eb4dadbb","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/metal3-io/baremetal-operator/commit/c2b5a557641bc273367635124047d6c958aa15f7","tags":["x_refsource_MISC","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43803","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-pqfh-xh7w-7h3p"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/43xxx/CVE-2024-43803.json","tags":["advisory"]},{"url":"https://github.com/metal3-io/baremetal-operator","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-20250060-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2024-12678","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-25131","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-25133","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-28892","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-43803","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45338","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45387","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-54148","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-55196","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-55947","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-56362","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-56513","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-56514","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-9779","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-21609","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-21613","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-21614","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-22130","tags":["web"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/RKGXQ5KH45FY7WLT7M5JFCJB2ZEAPTJA/","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2024-43803","title":"BMO can expose particularly named secrets from other namespaces via BMH CRD","description":"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).\n\nBMO 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.\n\nThe 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.","status":"published","published":"2024-09-03T18:56:29.607Z","modified":"2024-09-03T19:30:44.895Z","cvss":[{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-200","CWE-653"],"updated_at":"2026-11-02T14:33:58.357949Z"}],"euvd":[{"id":"EUVD-2024-2846","description":"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).\n\nBMO 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.\n\nThe 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.","status":"published","published":"2024-09-03T18:56:29Z","modified":"2024-09-03T19:30:44Z","cvss":[{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N","level":"medium"}],"updated_at":"2026-11-03T00:56:05.029422Z"}],"ghsa":[{"id":"GHSA-pqfh-xh7w-7h3p","title":"The Bare Metal Operator (BMO) can expose particularly named secrets from other namespaces via BMH CRD","description":"### Impact\nThe 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).\n\n### Limiting factors\nBMO 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.\n\nIt 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.\n\n### Patches\nThe 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.\n\nThe problem is patched in BMO releases v0.8.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading and if needed, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets.\n\n### Workarounds\nOperator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.\n\n### References\n- https://nvd.nist.gov/vuln/detail/CVE-2024-43803\n- https://github.com/metal3-io/baremetal-operator/pull/1929\n- https://github.com/metal3-io/baremetal-operator/pull/1930\n- https://github.com/metal3-io/baremetal-operator/pull/1931","status":"published","published":"2024-09-03T20:13:25Z","modified":"2024-09-03T21:45:29Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N","level":"medium"},{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N","level":"medium"}],"cwes":["CWE-200","CWE-653"],"updated_at":"2026-11-02T14:38:00.257632Z"}],"nvd":[{"id":"CVE-2024-43803","description":"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).\n\nBMO 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.\n\nThe 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.","status":"published","published":"2024-09-03T19:15:14.8Z","modified":"2026-06-17T07:51:44.6Z","cvss":[{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-200","CWE-653"],"updated_at":"2026-11-02T14:10:24.514378Z"}],"osv":[{"id":"CVE-2024-43803","title":"BMO can expose particularly named secrets from other namespaces via BMH CRD","description":"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).\n\nBMO 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.\n\nThe 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.","status":"published","published":"2024-09-03T18:56:29.607Z","modified":"2026-10-28T02:30:51.894964308Z","cvss":[{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N","level":"medium"}],"cwes":["CWE-200","CWE-653"],"updated_at":"2026-11-02T15:44:42.322107Z"},{"id":"GHSA-pqfh-xh7w-7h3p","title":"The Bare Metal Operator (BMO) can expose particularly named secrets from other namespaces via BMH CRD","description":"### Impact\nThe 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).\n\n### Limiting factors\nBMO 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.\n\nIt 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.\n\n### Patches\nThe 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.\n\nThe problem is patched in BMO releases v0.8.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading and if needed, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets.\n\n### Workarounds\nOperator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.\n\n### References\n- https://nvd.nist.gov/vuln/detail/CVE-2024-43803\n- https://github.com/metal3-io/baremetal-operator/pull/1929\n- https://github.com/metal3-io/baremetal-operator/pull/1930\n- https://github.com/metal3-io/baremetal-operator/pull/1931","status":"published","published":"2024-09-03T20:13:25Z","modified":"2024-12-20T21:13:23.260261Z","cvss":[{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N","level":"medium"},{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-200","CWE-653"],"updated_at":"2026-11-02T15:46:53.700556Z"},{"id":"GO-2024-3109","title":"The Bare Metal Operator (BMO) can expose particularly named secrets from other namespaces via BMH CRD in github.com/metal3-io/baremetal-operator","description":"The Bare Metal Operator (BMO) can expose particularly named secrets from other namespaces via BMH CRD in github.com/metal3-io/baremetal-operator","status":"published","published":"2024-12-20T20:36:43Z","modified":"2026-03-03T04:52:02.205791Z","updated_at":"2026-11-02T15:47:01.453823Z"},{"id":"openSUSE-SU-2024:14608-1","title":"govulncheck-vulndb-0.0.20241220T214820-1.1 on GA media","description":"These are all security issues fixed in the govulncheck-vulndb-0.0.20241220T214820-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-12-22T00:00:00Z","modified":"2026-02-04T03:43:56.070392Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"SUSE-SU-2025:0060-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20250108T191942 2025-01-08T19:19:42Z.\n  Refs jsc#PED-11136\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3371 GHSA-2r2v-9pf8-6342\n  * GO-2025-3374 CVE-2025-22130 GHSA-j4jw-m6xr-fv6c\n\n- Update to version 0.0.20250107T160406 2025-01-07T16:04:06Z.\n  Refs jsc#PED-11136\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3363 GO-2025-3364 GO-2025-3367 GO-2025-3368\n  * GO-2024-3355 CVE-2024-54148 GHSA-r7j8-5h9c-f6fx\n  * GO-2024-3356 CVE-2024-55947 GHSA-qf5v-rp47-55gg\n  * GO-2024-3357 CVE-2024-56362 GHSA-xwx7-p63r-2rj8\n  * GO-2024-3358 CVE-2024-45387 GHSA-vq94-9pfv-ccqr\n  * GO-2024-3359 CVE-2024-28892 GHSA-5qww-56gc-f66c\n  * GO-2024-3360 CVE-2024-25133 GHSA-wgqq-9qh8-wvqv\n  * GO-2025-3361 CVE-2024-55196 GHSA-rv83-h68q-c4wq\n  * GO-2025-3362 CVE-2025-21609 GHSA-8fx8-pffw-w498\n  * GO-2025-3363 CVE-2024-56514 GHSA-cwrh-575j-8vr3\n  * GO-2025-3364 CVE-2024-56513 GHSA-mg7w-c9x2-xh7r\n  * GO-2025-3367 CVE-2025-21614 GHSA-r9px-m959-cxf4\n  * GO-2025-3368 CVE-2025-21613 GHSA-v725-9546-7q7m\n\n- Update to version 0.0.20241220T214820 2024-12-20T21:48:20Z.\n  Refs jsc#PED-11136\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2024-3101 GHSA-75qh-gg76-p2w4\n  * GO-2024-3339 GHSA-8wcc-m6j2-qxvm\n\n- Update to version 0.0.20241220T203729 2024-12-20T20:37:29Z.\n  Refs jsc#PED-11136\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2024-3101 GHSA-75qh-gg76-p2w4\n  * GO-2024-3109 CVE-2024-43803 GHSA-pqfh-xh7w-7h3p\n  * GO-2024-3333 CVE-2024-45338 GHSA-w32m-9786-jp63\n  * GO-2024-3342 GHSA-hxr6-2p24-hf98\n  * GO-2024-3343 CVE-2024-9779 GHSA-jhh6-6fhp-q2xp\n  * GO-2024-3344 GHSA-32gq-x56h-299c\n  * GO-2024-3349 CVE-2024-25131 GHSA-77c2-c35q-254w\n  * GO-2024-3350 GHSA-5pf6-cq2v-23ww\n  * GO-2024-3354 CVE-2024-12678 GHSA-hr68-hvgv-xxqf\n","status":"published","published":"2025-01-10T11:33:29Z","modified":"2026-02-05T02:50:12.74079Z","updated_at":"2026-11-02T15:53:56.123059Z"}]}}