PHP2Shell: Sogar die Cybersicherheitsbehörde musste ihre Website abschalten

Zwei kritische Sicherheitslücken in PHP gefährden Server und sensible Daten. Welches CMS dahinter läuft, spielt dabei keine Rolle.

Am Mittwoch, dem 21. Oktober 2026, wurden in fünf europäischen Ländern Regierungswebsites vorsorglich abgeschaltet. Grund waren Warnungen vor zwei kritischen Schwachstellen in PHP.

Die Niederlande nahmen Overheid.nl, MijnOverheid.nl und DigiD, ihr staatliches System für digitale Identitäten, vorübergehend vom Netz.

Auch das niederländische Nationale Zentrum für Cybersicherheit (NCSC) musste seine eigene Website abschalten.

Frankreich nahm die Websites der Präfekturen offline.

In Deutschland schaltete der zentrale IT-Dienstleister des Bundes, ITZBund, mehrere Regierungsseiten ab.

Das belgische Außenministerium nahm seine Websites vom Netz. In Finnland schaltete der staatliche IT-Dienstleister Valtori öffentliche Regierungsdienste ab.

Auch Österreich war betroffen. Die Universität Wien, die TU Wien, die Caritas Österreich und die Regionalzeitung NÖN nahmen Websites vorsorglich vom Netz.

Die Ausfälle beschränkten sich nicht auf Behörden.

Auch der Hafen Rotterdam, niederländische Parteien, Krankenhäuser und mehrere Wikimedia-Dienste waren von vorsorglichen Abschaltungen betroffen.

Sogar die Behörde, die andere niederländische Institutionen vor der Sicherheitslücke warnen sollte, musste ihre eigene Website vom Netz nehmen.

Dem Bug ist egal, welches CMS du verwendest

PHP2Shell bezeichnet zwei Sicherheitslücken, CVE-2026-109618 und CVE-2026-109619. Beide wurden nach CVSS v4.0 mit 9,2 von 10 Punkten bewertet. Betroffen ist PHP selbst.

Das Team von Wiz konnte zeigen, dass sich über diese Schwachstellen auf WordPress-, Drupal- und Joomla-Installationen Code aus der Ferne ausführen lässt, ohne dass eine Anmeldung nötig ist.

Ein Angreifer muss dafür lediglich speziell präparierte Anfragen an den Server schicken. Ein gestohlenes Administratorpasswort braucht er nicht.

Die Schwachstellen hängen damit zusammen, wie PHP bei Fehlern und nachfolgenden Anfragen mit dem Arbeitsspeicher umgeht. Bei bestimmten Konfigurationen lässt sich die Lücke ausnutzen, noch bevor der eigentliche Anwendungscode der Website überhaupt ausgeführt wird.

Es ging auch um die Daten

Ein kompromittierter Server kann zum Schürfen von Kryptowährungen, zum Versenden von Spam oder für weitere Angriffe missbraucht werden. Das sind bekannte Folgen solcher Sicherheitslücken. Bei PHP2Shell war aber noch etwas anderes besonders problematisch.

Angreifer konnten sensible Informationen aus dem PHP-Arbeitsspeicher auslesen, ohne vorher die vollständige Kontrolle über den Server übernehmen zu müssen.

In diesem Speicher können Passwörter, Anmeldetokens, API-Schlüssel und andere Informationen liegen, die eine Website gerade verarbeitet.

Gelingt es einem Angreifer, eigenen Code auf dem Server auszuführen, kann er unter Umständen auch auf Programmdateien, Quellcode, Datenbankzugangsdaten und weitere Systeme zugreifen, die für den kompromittierten Prozess erreichbar sind.

Wie weit dieser Zugriff reicht, hängt von der Serverkonfiguration, den Berechtigungen und der Trennung der Netzwerke ab. Gerade ältere Anwendungen mit zu großzügig vergebenen Zugriffsrechten oder schlecht voneinander getrennten Diensten können deutlich mehr preisgeben.

Eine Gemeindewebsite verwaltet vielleicht nur Öffnungszeiten und Müllabfuhrtermine. Ein anderes Behördenportal verarbeitet Ausweisdaten, Anträge oder persönliche Akten.

Bei öffentlichen Ausschreibungen kann am Ende durchaus eine funktionierende Website herauskommen, ohne dass auch die nötige Fachkompetenz für ihren sicheren Betrieb sichergestellt ist.

Sensible Bürgerdaten sollten getrennt von den öffentlich zugänglichen Websitedaten gespeichert werden. Dazu gehören eine saubere Netzwerktrennung, eingeschränkte Datenbankberechtigungen und streng kontrollierte Zugriffe.

Ein öffentlich erreichbarer PHP-Server hat keinen Grund, uneingeschränkten Zugriff auf eine komplette Bürgerdatenbank zu haben.

Solche Schutzmaßnahmen hätten PHP2Shell zwar nicht verhindert, aber deutlich einschränken können, welche Daten ein Angreifer nach einem erfolgreichen Angriff tatsächlich stehlen kann.

Vierzehn Jahre anfälliges PHP

Laut Wiz reicht der betroffene Code mindestens bis PHP 5.4 zurück. Diese Version erschien 2012.

Die PHP Foundation hat inzwischen eingeräumt, dass bereits 2024 bei Sicherheitsprüfungen Hinweise auf das zugrunde liegende Problem mit der Speicherverwaltung entdeckt wurden.

Vorgeschlagene Korrekturen warfen allerdings Fragen zur Kompatibilität und Stabilität auf. Die Arbeiten kamen ins Stocken.

Im August 2026 wurden funktionierende Angriffe demonstriert und dem PHP-Sicherheitsteam gemeldet. Eine koordinierte Veröffentlichung der Fehlerbehebungen war für den 22. Oktober vorgesehen.

Am 20. Oktober gelangten jedoch Details an die Öffentlichkeit. Daraufhin zog das PHP-Team die Veröffentlichung auf den 21. Oktober vor.

Kurz darauf meldete Cloudflare bereits schädlichen Datenverkehr gegen seine Kunden. Angreifer versuchten außerdem, ihre Anfragen so zu verändern, dass bestehende Schutzmaßnahmen umgangen werden konnten.

Was jetzt gemacht werden muss

Am 21. Oktober veröffentlichte PHP die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35, um beide Sicherheitslücken zu schließen.

Websites mit älteren, nicht mehr unterstützten PHP-Versionen müssen aktualisiert werden oder passende Sicherheitsupdates ihres jeweiligen Anbieters erhalten.

Ein Update von WordPress, Drupal oder einem selbst entwickelten CMS ersetzt kein Update der PHP-Laufzeitumgebung.

Web Application Firewalls können das Risiko verringern. Cloudflare hatte bereits vor der öffentlichen Bekanntgabe entsprechende Schutzregeln aktiviert. Solche Regeln sind allerdings nur ein zusätzlicher Schutz und keine dauerhafte Lösung.

Administratoren sollten außerdem ihre Serverprotokolle auf verdächtige Aktivitäten und Hinweise auf einen möglichen Einbruch prüfen.

Ein installiertes Sicherheitsupdate macht einen bereits erfolgten Angriff nicht rückgängig. Auch Zugangsdaten, die möglicherweise schon abgeflossen sind, werden dadurch nicht automatisch wieder sicher.

CERT-EU empfahl Organisationen, die nicht sofort patchen können, betroffene öffentlich erreichbare Anwendungen vorübergehend vom Netz zu nehmen oder zu isolieren.

Damit erklären sich auch die Ausfälle der Regierungswebsites am Mittwoch.

Ein Behördenportal abzuschalten ist lästig.

Einen anfälligen Server weiterhin mit sensiblen Bürgerdaten verbunden zu lassen, kann allerdings wesentlich teurer werden.

Die niederländische Cybersicherheitsbehörde hielt einen vorübergehenden Ausfall offenbar für die bessere Lösung.

Zur Abwechslung tat eine Regierungswebsite mit der Meldung „Dienst vorübergehend nicht verfügbar“ also genau das, was ihre Administratoren beabsichtigt hatten.

Das unmittelbare Problem lässt sich mit einem PHP-Update beheben. Die Folgen möglicher erfolgreicher Angriffe könnten aber erst viel später sichtbar werden.

Gestohlene persönliche Daten könnten verwendet werden, um falsche Identitäten anzulegen, betrügerische Anträge einzureichen oder Zugang zu weiteren staatlichen Diensten zu bekommen. Mit entsprechenden Berechtigungen könnten Angreifer sogar offizielle Datensätze verändert haben.

Das wirft auch Fragen zur zunehmenden Abhängigkeit von digitalen Identitätssystemen auf. Wenn eine einzige digitale ID zum Zugangsschlüssel für immer mehr staatliche Dienstleistungen wird, konzentriert sich damit auch das Risiko.

Wir werden in den nächsten Wochen weiterverfolgen, was noch ans Licht kommt.