Veröffentlicht am 04.07.2026
Ein unbekannter Angreifer, irgendwo im Internet, tippt eine manipulierte Webadresse in seinen Browser – und liest kurz darauf die Datenbankpasswörter und API-Schlüssel Ihres Servers aus. Kein Login, keine gestohlenen Zugangsdaten, keine Interaktion Ihrerseits nötig. Genau dieses Szenario beschreibt CVE-2026-58467, eine kürzlich veröffentlichte Schwachstelle im Headless-CMS Cockpit. Wer das System betreibt, sollte jetzt handeln.
Am 2. Juli 2026 wurde die Schwachstelle CVE-2026-58467 offiziell in der US-amerikanischen Schwachstellendatenbank NVD veröffentlicht. Betroffen ist Cockpit CMS – ein PHP-basiertes, sogenanntes „Headless-CMS“ (ein Content-Management-System, das die Inhalte nur über eine Programmierschnittstelle bereitstellt und keine eigene Darstellungsschicht mitliefert). Betroffen sind alle Versionen vor Release 364.
Es handelt sich um eine Kombination aus zwei klassischen Angriffstechniken: Path Traversal (das „Ausbrechen“ aus einem vorgesehenen Verzeichnis, um beliebige Dateien auf dem Server zu erreichen) und Local File Inclusion, kurz LFI (das Einbinden und Ausführen lokaler Dateien durch die Anwendung). Die Schwachstelle ist unauthentifiziert ausnutzbar – ein Angreifer benötigt also keinerlei Zugangsdaten.
Die Bewertung fällt entsprechend ernst aus: CVSS 4.0 Base Score 8,2 (High), nach dem älteren Standard CVSS 3.1 immerhin 7,5 (High). Entdeckt wurde die Lücke vom Sicherheitsforscher George Chen, der sie am 23. Mai 2026 an den Hersteller meldete. Der Maintainer behob den Fehler bereits zwei Tage später, am 25. Mai 2026. Da der Hersteller jedoch auf mehrere Nachfragen (17. Juni und 1. Juli 2026) nicht mehr reagierte, entschied sich Chen zur koordinierten Veröffentlichung. Brisant: Zeitgleich mit der CVE-Veröffentlichung erschien ein öffentlicher Proof-of-Concept (PoC) auf GitHub – also fertiger Beispielcode, der zeigt, wie sich die Lücke ausnutzen lässt. Das senkt die Einstiegshürde für Angreifer erheblich.
Die Schwachstelle steckt in der zentralen Datei index.php von Cockpit CMS (Zeilen 46–72). Vereinfacht gesagt: Der Code übernimmt den vom Nutzer angefragten Pfad aus der URL direkt und ungeprüft und setzt daraus einen Dateipfad auf dem Server zusammen – ohne zu kontrollieren, ob dieser Pfad überhaupt innerhalb des dafür vorgesehenen Verzeichnisses (.spaces) liegt.
Ein Angreifer kann daher sogenannte „Dot-Dot-Slash“-Sequenzen (../) in die URL einschleusen. Jedes ../ springt eine Verzeichnisebene nach oben. Mit genügend dieser Sequenzen lässt sich aus dem vorgesehenen Verzeichnis ausbrechen und praktisch jede Datei auf dem Server lesen – etwa die Systemdatei /etc/passwd oder, weit gefährlicher, Konfigurationsdateien mit sensiblen Zugangsdaten.
Der Entdecker George Chen beschreibt den Kern des Problems so:
„Es wird keine Pfadenthaltungsprüfung durchgeführt. Der Code vergleicht realpath($spaceFilePath) nicht mit realpath(APP_SPACES_DIR). ‚..‘-Komponenten im URL-Pfad erlauben das Ausbrechen aus dem .spaces-Verzeichnis. […] Der PHP Built-in Server normalisiert ‚..‘ in URLs NICHT. REQUEST_URI enthält den rohen Pfad, was die Traversierung vollständig ausnutzbar macht.“ (Quelle: geo-chen/oss auf GitHub)
Endet der so zusammengebaute Pfad auf .php, wird die Datei nicht nur gelesen, sondern über PHP's include()-Funktion ausgeführt. Dann wird aus dem reinen Auslesen von Dateien eine Remote Code Execution (RCE) – die Fähigkeit, eigenen Programmcode auf dem fremden Server auszuführen. Das ist der schlimmstmögliche Fall.
Ob dieser Extremfall greift, hängt entscheidend von der Serverkonfiguration ab:
php -S): Hier ist die Lücke vollständig ausnutzbar – sowohl das Auslesen von Dateien als auch die Codeausführung. Dieser Server normalisiert URLs nicht und sollte ohnehin niemals im produktiven Betrieb eingesetzt werden.merge_slashes off: Ebenfalls anfällig, da hier der rohe URL-Pfad durchgereicht wird.Die technische Einordnung fällt unter CWE-22 (unzureichende Beschränkung eines Pfadnamens auf ein eingeschränktes Verzeichnis). Der EPSS-Score – ein Maß für die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen – lag bei Veröffentlichung bei 0,42 % (34. Perzentile). Das klingt niedrig, ist aber angesichts des öffentlich verfügbaren PoC-Codes mit Vorsicht zu genießen.
Cockpit CMS ist vor allem bei Entwicklern und technisch versierten KMU beliebt, die eine selbst gehostete, datenbankunabhängige Headless-CMS-Lösung suchen. Die Verbreitung ist beachtlich: Das Docker-Image cockpithq/cockpit verzeichnet über 500.000 Pulls auf Docker Hub. Das GitHub-Repository cockpit-hq/Cockpit hat 733 Sterne und 82 Forks, das ältere agentejo/cockpit über 6.000 Sterne (Stand Juli 2026).
Konkrete Zahlen zu im Internet exponierten Installationen liegen nicht vor. Fest steht: Wer Cockpit CMS als Backend für eine Unternehmenswebsite oder ein Kundenportal einsetzt, sollte sich angesprochen fühlen. Das Sicherheitsunternehmen IONIX teilt mit, es verfolge aktiv Exploitationsversuche und empfehle sofortiges Patchen.
Auffällig ist zudem, dass Cockpit CMS in jüngerer Vergangenheit mehrere Schwachstellen aufwies – darunter CVE-2026-34965 (authentifizierte RCE, CVSS 8.7, April 2026) und CVE-2026-31891 (SQL Injection, März 2026). Das deutet auf eine erhöhte Angriffsfläche des Produkts hin und unterstreicht, wie wichtig ein diszipliniertes Update-Management ist.
cat /pfad/zu/cockpit/CHANGELOG.md | head -5ps aux | grep 'php -S'. Falls ja, besteht ein besonders hohes Risiko.grep -r 'merge_slashes' /etc/nginx/ – ist merge_slashes off gesetzt, ist die Installation zusätzlich gefährdet.grep -n 'realpath' /pfad/zu/cockpit/index.php – fehlt die realpath()-Prüfung, ist die Datei verwundbar.grep -E '(\.\./|%2e%2e%2f|%252e%252e)' /var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/nullEin Patch steht bereit. Release 364 wurde am 23. Juni 2026 auf GitHub veröffentlicht und enthält den Fix: Der Code prüft nun nach Konstruktion des Dateipfads per realpath()-Vergleich, ob der aufgelöste Pfad tatsächlich innerhalb des erlaubten Verzeichnisses liegt – andernfalls wird die Anfrage abgelehnt. Handeln Sie in dieser Reihenfolge:
docker pull cockpithq/cockpit:core-latest (bzw. pro-latest).php -S betreibt. Nutzen Sie ausschließlich Apache oder Nginx.../, %2e%2e%2f, %252e%252e) in eingehenden Anfragen.Für deutsche Unternehmen ist diese Schwachstelle mehr als ein technisches Problem – sie hat unmittelbare datenschutzrechtliche Konsequenzen. Ein erfolgreicher Angriff kann Konfigurationsdateien, private Schlüssel und potenziell personenbezogene Daten offenlegen. Damit greifen zentrale Pflichten der DSGVO:
Dass das Bußgeldrisiko real ist, zeigt ein Vergleichsfall: Die griechische Aufsichtsbehörde HDPA verhängte im Dezember 2023 60.000 Euro gegen die Alpha Bank – davon 50.000 Euro allein für die verspätete Meldung einer Datenpanne nach Art. 33 DSGVO. Der Bußgeldrahmen der DSGVO reicht bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes.
Das Sherlock Forensics Team ordnet das Risiko so ein:
„Ein CVSS-Score von 7,5 bedeutet, dass diese Schwachstelle leicht auszunutzen ist, wahrscheinlich erheblichen Schaden verursacht oder beides. Für Startups und kleine Unternehmen ohne dediziertes Sicherheitsteam stellen Schwachstellen dieses Schweregrads ein reales operatives Risiko dar – kein theoretisches.“
CVE-2026-58467 vereint mehrere gefährliche Eigenschaften: Sie ist ohne Anmeldung, ohne Benutzerinteraktion und über das Netzwerk ausnutzbar, unter bestimmten Serverkonfigurationen sogar bis hin zur vollständigen Codeausführung. Und seit dem 2. Juli 2026 liegt fertiger Exploit-Code öffentlich vor. Zwar ist eine massenhafte Ausnutzung laut EPSS-Score bislang nicht dokumentiert, doch die niedrige Angriffskomplexität und der verfügbare PoC lassen eine Zunahme erwarten.
Die gute Nachricht: Ein Patch existiert. Wer Cockpit CMS betreibt, sollte umgehend auf Release 364 oder neuer aktualisieren, die Serverkonfiguration prüfen und die Logs auf Angriffsspuren durchsehen. Der Aufwand ist überschaubar – die Konsequenzen eines unbehandelten Vorfalls, von Datenverlust über Bußgelder bis zum Reputationsschaden, sind es nicht.