Das hier ist ein vollständig KI generierter Artikel.

Ein Sicherheitsforscher wirft Google vor, eine kritische Schwachstelle in einem Kubernetes-Operator auf Google Cloud Platform (GCP) nicht zu beheben – obwohl der Fehler intern als hochprioritär akzeptiert wurde. Gleichzeitig verweigert der Konzern eine Bug-Bounty-Auszahlung mit der Begründung, es handle sich gar nicht um eine Sicherheitslücke, sondern um erwartetes Verhalten.

Die Schwachstelle in Config Connector

Im Zentrum steht Config Connector, ein Open-Source-Kubernetes-Add-on, mit dem sich GCP-Ressourcen direkt über Kubernetes-Objekte verwalten lassen. Der Forscher Justin O’Leary beschreibt eine Lücke, die es jedem Kubernetes-Namespace-Nutzer ermöglichen soll, die Identity-and-Access-Management-Kontrollen (IAM) von GCP zu umgehen und sich effektiv die Rolle Owner auf Organisationsebene zu verschaffen.

Nach O’Learys Analyse führt Config Connector vor dem Ausführen privilegierter Operationen keinen eigenen Autorisierungs-Check durch. Hat der zugrunde liegende Config-Connector-Service-Account Organisationsrechte, kann ein Angreifer mit einfachem Namespace-Zugriff diesen Account als eine Art „verwirrten Stellvertreter“ (confused deputy) missbrauchen. In einem Proof-of-Concept demonstriert O’Leary, dass wenige Zeilen YAML genügen, um in Sekunden vollen administrativen Zugriff auf eine GCP-Organisation zu erlangen.

Googles Reaktion: Von „Nice catch!“ zu „Working as intended“

Google bewertete den ursprünglichen Report zunächst mit höchster Priorität (P1) und Schwere (S1) und bestätigte gegenüber O’Leary, dass ein internes Ticket eröffnet worden sei. Kurz darauf folgte jedoch eine Kehrtwende: Ein automatisiertes Security-Update teilte mit, dass der Fall zwar akzeptiert, aber nicht als Bug-Bounty-würdig eingestuft werde, da die Software „wie vorgesehen“ arbeite.

Zur Begründung verweist Google darauf, dass ein Angreifer bereits Zugriff auf einen stark privilegierten Config-Connector-Service-Account mit Organisationsrechten haben müsse. Zudem widerspreche eine derart weitreichende Berechtigung den eigenen Best Practices und dem Prinzip der minimalen Rechtevergabe. Dass der Fall intern weiterhin als P1/S1 mit Status „in progress (accepted)“ geführt wird und bislang weder ein Fix noch eine CVE veröffentlicht wurden, bleibt von Google unbeantwortet.

Konfliktlinie: Best Practices vs. reale Einsatzszenarien

O’Leary hält Googles Argumentation für unzureichend. Zwar sei korrekt, dass der Service-Account Organisationsrechte benötigt, um Ressourcen über mehrere GKE-Cluster hinweg zu verwalten. Gleichzeitig zeige die offizielle Dokumentation, wie genau solche Rechte in der Praxis konfiguriert werden – also kein exotisches Randsetup, sondern ein von Google selbst beschriebenes Szenario.

Der Kern seiner Kritik: Selbst wenn ein Service-Account weitreichende Rechte besitzt, dürfe ein beliebiger Namespace-Nutzer ohne eigene IAM-Berechtigungen diese Rechte nicht einfach übernehmen. Aus seiner Sicht ist das Fehlen eines expliziten Autorisierungs-Checks in Config Connector der eigentliche Fehler. Ein Entwickler mit einfachem kubectl-Zugriff auf einen Namespace solle weder Organisationseigentümer werden noch beliebige Service-Accounts ohne nachvollziehbare Spur im Audit-Log imitieren können.

Bug-Bounty-Frust in der Cloud-Szene

Der aktuelle Fall reiht sich für O’Leary in eine Serie ähnlicher Erfahrungen ein. Bereits bei einer zuvor gemeldeten Privilegieneskalation in Azure Backup für AKS sei sein Report von Microsoft abgelehnt und die Schwachstelle später stillschweigend behoben worden – ohne CVE oder öffentliche Sicherheitsmeldung. Für unabhängige Forscher entsteht so der Eindruck, dass grosse Cloud-Anbieter kritische Meldungen zwar intern ernst nehmen, nach aussen aber möglichst wenig Angriffsfläche bieten wollen.

Für Unternehmen, die stark auf Managed-Kubernetes-Umgebungen wie GKE setzen, bleibt die Situation unbefriedigend: Einerseits sind sie auf transparente Kommunikation und klare Patches angewiesen, andererseits geraten sie in eine Grauzone, wenn potenziell kritische Designschwächen als „Working as intended“ deklariert werden. Die Diskussion um ConfigConfusion zeigt, wie stark Sicherheitsbewertung, Implementierungsdetails und Bug-Bounty-Richtlinien auseinanderdriften können.

Fazit

Der Streit um ConfigConfusion macht deutlich, wie komplex die Sicherheitslage in modernen Cloud- und Kubernetes-Umgebungen ist. Selbst wenn alle formalen Best Practices eingehalten werden, können fehlende Autorisierungsprüfungen in zentralen Komponenten zu gravierenden Eskalationspfaden führen. Unabhängige Forschung spielt hier eine wichtige Rolle – doch solange Anbieter kritische Designfragen hinter Programmrichtlinien und Formulierungen wie „Working as intended“ verstecken, bleibt das Vertrauen der Community auf die Probe gestellt.

Quelle: https://www.theregister.com/security/2026/06/18/google-told-researcher-nice-catch-then-denied-bug-bounty-for-flaw-it-still-hasnt-fixed/5258076