Kurzfassung

In Prowler steckt vor Version 5.36.0 eine kritische Schwachstelle im Kubernetes-Provider. Wer eine präparierte kubeconfig-Datei an den Connection-Test übergibt, kann über alte GCP-Auth-Provider-Einträge mit cmd-path und cmd-args offenbar eigene Befehle auf dem Shared Worker auslösen. Für Umgebungen in Betrieb ist das kein Theorieproblem. Wer Prowler für Kubernetes-Prüfungen nutzt, sollte die Version sofort prüfen und zügig aktualisieren.

Was ist passiert?

Der Fehler sitzt in der Prüfung der kubeconfig-Inhalte. Die Anwendung hat nur bestimmte Exec-Auth-Blockaden berücksichtigt, alte Varianten mit GCP auth-provider aber nicht sauber abgefangen. Genau diese Lücke wurde beim Verbindungscheck des Kubernetes-Providers relevant: Die API lädt die Konfiguration, und die darunterliegende Kubernetes-Python-Komponente verarbeitet dann die Angabe so, dass ein vom Angreifer gelieferter Befehl ausgeführt werden kann.

Das ist heikel, weil der Angriff nicht erst tief im System ansetzen muss. Ein präparierter Request an den Connection-Test genügt nach der Herstellerbeschreibung. Ob dafür bereits eine Authentifizierung im betroffenen Prowler-Setup notwendig ist, geht aus dem Auszug nicht hervor.

Technische Details

Betroffen ist CVE-2026-73263, vom NVD als kritisch eingestuft. Auslöser ist die unvollständige Erkennung von kubeconfig_content mit legacy gcp auth-provider und den Feldern cmd-path sowie cmd-args. Die Logik in der API prüfte nur exec-Blöcke. Danach wurde die Konfiguration an config.load_kube_config_from_dict weitergereicht. Dort landet die Verarbeitung schließlich bei kubernetes-python CommandTokenSource.token, das den angegebenen Befehl über subprocess.Popen startet.

Technisch läuft das auf eine Remote Code Execution hinaus, allerdings innerhalb des Kontextes des gemeinsamen Workers. Das ist für Cloud- und Plattformteams besonders unangenehm, weil solche Worker oft mehr Rechte haben, als man auf den ersten Blick vermutet. Ob ein erfolgreicher Angriff sofort zu einer vollständigen Übernahme führt, hängt vom Deployment, den Rechten des Dienstkontos und der Isolation der Umgebung ab.

Wer ist betroffen?

Betroffen sind Installationen von Prowler vor Version 5.36.0, sofern dort der Kubernetes-Provider verwendet wird. Für Unternehmen im DACH-Raum trifft das vor allem Teams, die mit Prowler Kubernetes-Cluster prüfen oder Security-Checks automatisieren. Wer nur andere Provider nutzt, dürfte deutlich weniger Risiko haben, aber die konkrete Nutzung des Kubernetes-Connectors sollte trotzdem geprüft werden.

Für Privatnutzer ist das Thema nur dann relevant, wenn sie Prowler selbst betreiben. Das ist eher ein Fall für Admins, Plattformteams und Sicherheitsverantwortliche. In regulären Heimumgebungen spielt die Schwachstelle praktisch keine Rolle.

Empfohlene Maßnahmen

Die wichtigste Maßnahme ist simpel: auf Version 5.36.0 oder neuer gehen. Davor sollte niemand den Kubernetes-Connection-Test mit unklaren oder fremden kubeconfig-Inhalten ausführen. Wer Prowler in einer Pipeline oder als internen Dienst betreibt, sollte den Zugriff auf die API zusätzlich einschränken und prüfen, wer Verbindungen zu Kubernetes-Providern anstoßen darf.

Praktisch heißt das für Admins: Version inventarisieren, betroffene Instanzen priorisieren, Update einplanen, danach die Logs auf auffällige Connection-Tests und ungewöhnliche Worker-Aktivität prüfen. Wenn Prowler in einer geteilten Laufzeitumgebung läuft, lohnt sich auch ein Blick auf die Trennung der Rechte. Der Shared Worker ist hier der eigentliche Schmerzpunkt.

Einschätzung von CyberSecurity-News.de

Die Schwachstelle ist ernst. Nicht wegen eines spektakulären Angriffsbilds, sondern weil sie in einem Werkzeug sitzt, das selbst Sicherheitsprüfungen ausführt. Genau solche Tools laufen oft mit Vertrauen im Bauch und zu wenig Härtung im Alltag. Das rächt sich bei Eingabedaten, die aus dem Ruder laufen.

Positiv ist nur, dass ein Fix in 5.36.0 vorliegt. Kritisch bleibt die dünne Informationslage zum Angriffspfad im echten Betrieb. Aus dem NVD-Eintrag geht nicht hervor, wie leicht sich die Lücke außerhalb eines gezielt manipulierten Requests ausnutzen lässt. Für Betreiber reicht das aber nicht als Entwarnung. Wer Prowler produktiv oder in CI/CD einsetzt, sollte den Patch nicht schieben.

Fazit

CVE-2026-73263 ist eine klare Priorität für alle, die Prowler mit Kubernetes-Anbindung nutzen. Der Fehler ermöglicht unter den beschriebenen Bedingungen die Ausführung fremder Befehle über eine manipulierte kubeconfig. Das Update auf 5.36.0 gehört sofort auf die To-do-Liste. Wer zusätzlich den Zugriff auf den Provider-Connection-Test begrenzt, senkt das Risiko spürbar.

Quellenangabe

Weiterführende Quelle: NVD – CVE-2026-73263