PHP2Shell – Wenn das digitale Fundament Risse bekommt

Ein Fundament hat einen entscheidenden Nachteil: Man sieht es nicht. Deshalb wird über Fassaden gern gesprochen, über das Darunter meist erst dann, wenn sich oben etwas bewegt. Im Internet haben wir diese Gewohnheit erstaunlich sorgfältig übernommen. Die Website soll modern aussehen, schnell laden und möglichst wenig kosten. Was sie im Innersten zusammenhält, fällt unter die beruhigende Sammelbezeichnung „Das macht unser Dienstleister“.
Seit dem 20. und 21. Oktober 2026 hat dieses Darunter einen Namen, der auch außerhalb der IT-Abteilung Aufmerksamkeit verdient: PHP2Shell. Gemeint sind zwei kritische Sicherheitslücken in PHP, bezeichnet als CVE-2026-109618 und CVE-2026-109619. Fehler beim Umgang mit Arbeitsspeicher und Fehlerzuständen können es Angreifern ermöglichen, auf verwundbaren Servern eigenen Programmcode auszuführen – ohne vorherige Anmeldung.
PHP arbeitet auf dem Server hinter vielen Webanwendungen. WordPress ist ein bekanntes Beispiel. Die aktuelle Schwachstelle sitzt in dieser technischen Grundlage; ein Update des Inhaltsverwaltungssystems oder seiner Erweiterungen allein beseitigt sie nicht. WordPress weist ausdrücklich darauf hin, dass PHP selbst aktualisiert werden muss. Ein neuer Anstrich hilft eben wenig, wenn der Schaden darunterliegt.
Dabei geht es bereits um beobachtete Angriffsversuche. Cloudflare berichtet von Angriffsdaten und veränderten Angriffsmustern, mit denen Schutzmaßnahmen umgangen werden sollten. Das Unternehmen empfiehlt trotz seiner zusätzlichen Schutzregeln weiterhin die Aktualisierung von PHP. Ob ein bestimmter Server tatsächlich kompromittiert wurde, muss im Einzelfall untersucht werden.
Für die Bau- und Immobilienwirtschaft gehört diese Entwicklung mitten in den Betriebsalltag. Wir haben die Trennung zwischen Gebäude und Daten längst selbst aufgehoben. Denken Sie an ein Mieterportal, einen digitalen Projektraum oder eine Plattform für Wartungsunterlagen. Wenn ein solcher Dienst auf verwundbarem PHP läuft, kann aus einer Softwarelücke ein Problem für ganz handfeste Arbeitsabläufe werden. Welche Systeme betroffen sind, muss der jeweilige Betreiber prüfen. Der Name der Anwendung genügt dafür ebenso wenig wie ihr gepflegtes Erscheinungsbild.
Für Betreiber ergeben sich daraus zunächst drei konkrete Aufgaben:
Den Hoster oder IT-Dienstleister feststellen lassen, welche eingesetzten Dienste PHP verwenden und welche Version beziehungsweise welches korrigierte Herstellerpaket dort tatsächlich läuft.
Die Sicherheitsupdates unverzüglich einspielen lassen und anschließend prüfen, ob die korrigierte Umgebung aktiv ist und die Anwendungen funktionieren.
Kann eine verwundbare Anwendung nicht sofort abgesichert werden, ihre öffentliche Erreichbarkeit vorübergehend einschränken oder sie vom Netz nehmen. CERT-EU empfiehlt eine solche Isolation bis zur eingespielten und überprüften Korrektur.
Seit dem 21. Oktober stehen die korrigierten PHP-Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 bereit. Bei Paketen von Linux-Distributionen oder Anbietern mit Langzeitunterstützung kann die Korrektur auch in eine ältere Versionslinie zurückübertragen sein. Deshalb gehört zur Prüfung die konkrete Sicherheitsmeldung des Anbieters. PHP 8.1 und ältere Zweige erhalten vom PHP-Projekt keine regulären Sicherheitsupdates mehr.
Ich würde mir die Rückmeldung des Dienstleisters dokumentieren lassen: betroffene Systeme, eingespielte Korrektur, Zeitpunkt und Ergebnis der Kontrolle. „Wir kümmern uns“ beschreibt eine Absicht. Für die Betriebsorganisation braucht es einen nachvollziehbaren Abschluss. Das ist uns aus der technischen Instandhaltung durchaus vertraut, auch wenn dort die Unterlagen gelegentlich eine ähnlich ausgeprägte Neigung zum Unsichtbarwerden besitzen.
Die PHP Foundation benennt in ihrer Aufarbeitung außerdem begrenzte Ressourcen und schwierige Entscheidungsprozesse als Ursachen für Verzögerungen bei der Behebung. Für mich steckt darin eine zweite Lehre: Wer dauerhaft auf gemeinsam entwickelte Software baut, muss auch über die Finanzierung ihrer Pflege sprechen. Die Kosten verschwinden nicht dadurch, dass auf der Downloadseite kein Kaufpreis steht.
Digitale Infrastruktur gehört deshalb in die laufende Betriebsplanung: mit Zuständigkeiten, Aktualisierungen, überprüfbaren Sicherungen und einem Vorgehen für den Ausfall. Wir sollten dabei dieselben Fragen stellen, die wir an ein Gebäude richten: Was haben wir? Wer betreut es? Wann wurde es zuletzt geprüft? Und was geschieht, wenn es versagt?
Ein Fundament bleibt auch dann wartungsbedürftig, wenn man es nicht sieht.




Kommentare