CVE-2025-29781 in baremetal-operator
Zusammenfassung
von VulDB • 29.06.2026
Der Bare Metal Operator (BMO) implementiert eine Kubernetes-API zur Verwaltung von Bare-Metal-Hosts in Metal3. Der Baremetal-Betreiber ermöglicht es Benutzern, Secrets aus beliebigen Namespaces beim Bereitstellen des namespaceräumlichen Custom Resource `BMCEventSubscription` zu laden. Vor den Versionen 0.8.1 und 0.9.1 kann ein Angreifer mit einem Kubernetes-Konto, das nur Rollen auf Namespace-Ebene besitzt (z. B. ein Tenant, der einen Namespace kontrolliert), eine `BMCEventSubscription` in seinem autorisierten Namespace erstellen und dann Secrets aus seinen nicht autorisierten Namespaces über den Baremetal-Betreiber in seinen autorisierten Namespace laden, was zu einer Secret-Leckage führt. Der Patch bewirkt, dass BMO das Lesen von Secrets aus anderen Namespaces als demjenigen verweigert, in dem sich die entsprechende BMH-Ressource befindet. Der Patch ändert nicht die `BMCEventSubscription`-API in BMO, aber strengere Validierungen werden die Anforderung zur Zulassungszeit (admission time) ablehnen. Er verhindert auch, dass der Controller solche Secrets liest, falls das BMCES-CR bereits bereitgestellt wurde. Das Problem besteht für alle Versionen von BMO und ist in den BMO-Releases v0.9.1 und v0.8.1 gepatcht. Vor dem Upgrade auf die gepatchte BMO-Version duplizieren Sie jedes vorhandene Secret, das durch `httpHeadersRef` der `BMCEventSubscription` angegeben wird, in denselben Namespace, in dem sich die entsprechende BMH befindet. Nach dem Upgrade entfernen Sie die alten Secrets. Als Workaround kann der Operator konfigurieren, dass die BMO-RBAC auf Namespaces beschränkt ist, anstatt clusterweit zu sein, um zu verhindern, dass BMO auf Secrets aus anderen Namespaces zugreift, und/oder die Konfigurationsoption `WATCH_NAMESPACE` verwenden, um BMO auf einen einzelnen Namespace zu beschränken.
VulDB is the best source for vulnerability data and more expert information about this specific topic.