PHP2Shell: Warum mehr Sicherheitsupdates eine gute Nachricht sind

Was am 21. Oktober passiert ist
 

Am 21. Oktober 2026 hat das PHP-Team ein Sicherheitsupdate veröffentlicht, das fast jede PHP-Website betrifft. PHP ist die Programmiersprache, mit der ein Server die Seiten einer Website erzeugt. Auch Drupal ist eines der vielen Systeme, die darauf aufbauen.
Wie verbreitet PHP ist, zeigt eine Zahl von W3Techs: Am 21. Oktober lief PHP auf 69,3 Prozent aller Websites, deren Programmiersprache bekannt ist. Auf Platz zwei folgt JavaScript mit 8,1 Prozent.
Die Lücken tragen den Namen PHP2Shell. Auf der üblichen Skala von 0 bis 10 erreichen sie einen Schweregrad von 9,2. Angreifer konnten ohne Login fremden Code auf einem Server ausführen oder Passwörter und Zugangsschlüssel aus dem Arbeitsspeicher lesen. Die eigentliche Website musste dafür keinen Fehler haben, der Fehler steckte in PHP selbst. Dass das keine Theorie blieb, zeigt ein Bericht von news.ORF.at über Millionen Angriffsversuche im Netz.
 

Das klingt nach einer schlechten Nachricht. Wir sehen das anders.

Warum mehr Sicherheitsupdates gut sind

Seit über einem Jahr beobachten wir, dass deutlich mehr Sicherheitslücken gefunden und geschlossen werden als früher. Ein wesentlicher Grund ist künstliche Intelligenz. Sicherheitsfachleute und Entwicklungsteams finden Schwachstellen damit schneller und gründlicher.
PHP2Shell ist ein gutes Beispiel. Gefunden haben die Lücken Forschende von Wiz Research, OpenAI und Calif, mit Unterstützung durch KI-Werkzeuge. Betroffen waren Versionen bis zurück zu PHP 5.4. Der Fehler lag also viele Jahre unentdeckt im Code.
 

Jede gefundene und geschlossene Lücke kann niemand mehr ausnutzen. Bei Open-Source-Software ist der Quellcode öffentlich, und genau das macht sie hier stark: Mehr Menschen und mehr Werkzeuge prüfen ihn. Die Software hinter Ihrer Website wird so laufend sicherer.
Die Kehrseite kennen alle, die Websites betreiben. Updates kommen häufiger und oft sehr kurzfristig. Damit muss man rechnen, und darauf kann man sich vorbereiten.

Wie gut die Koordination funktioniert hat
 

Bei kritischen Lücken gibt es ein eingespieltes Verfahren. Die Forschenden melden den Fund vertraulich, das zuständige Team baut eine Lösung, und erst dann wird die Lücke öffentlich. In den frühen Morgenstunden des 21. Oktober hat das PHP-Sicherheitsteam das Update für denselben Tag angekündigt. Solche Vorankündigungen sind bei hochkritischen Updates üblich. So kurzfristig sind sie selten.

Ganz nach Plan lief es diesmal nicht. Informationen zur Lücke waren schon vorab durchgesickert. Die Kette hat trotzdem gehalten. Das PHP-Team lieferte die Korrektur noch am selben Tag.

Für alle, die es genau wissen wollen: Geschlossen wurden zwei offiziell registrierte Schwachstellen, CVE-2026-109618 und CVE-2026-109619. Die korrigierten Versionen sind PHP 8Warum mehr Sicherheitsupdates gut sind.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 7.4 bis 8.1 gibt es keine offiziellen Releases mehr, nur minimale Korrekturen im Quellcode, die man selbst einbauen muss. Wer noch so alte Versionen betreibt, hat spätestens jetzt einen guten Grund für ein Upgrade.

Dazu kamen große Infrastruktur-Anbieter. Google Cloud, Cloudflare, AWS, Microsoft, Upsun und weitere Partner haben Anleitungen und vorläufige Schutzmaßnahmen für alle vorbereitet, die nicht sofort aktualisieren konnten.

Diese Hilfsbereitschaft erleben wir in vielen Open-Source-Communities. Im Drupal-Slack, dem Chat der Drupal-Community, und auf Mastodon haben die Threads am 21. Oktober geglüht. Dort wurden wichtige Informationen ausgetauscht, offen und für alle lesbar. Bei Software mit geschlossenem Quellcode ist so ein offener Austausch kaum möglich.

Was wir für unsere Kunden getan haben
 

Unser Team war ab den Morgenstunden an dem Thema. Bis die neuen PHP-Versionen eingespielt waren, sind wir in dieser Reihenfolge vorgegangen:

1. Vorbereiten. Wir haben die Ankündigung ausgewertet und die Arbeit für den Tag geplant.
2. Gehostete Kunden informieren. Kunden, deren Websites auf unseren Servern laufen, bekamen zu Mittag eine persönliche Nachricht. Darin stand, wie ernst die Lücke ist, dass ihre Website zeitweise nicht erreichbar sein kann und dass sie selbst nichts tun müssen.
3. Betreute Kunden vorbereiten. Kunden, die wir betreuen, aber nicht hosten, haben wir erklärt, was sie oder ihr Hosting-Anbieter tun müssen.
4. Systeme absichern. Einen Teil der Systeme haben wir vorübergehend heruntergefahren. Bei kritischeren Systemen haben wir vorab Schutzmaßnahmen umgesetzt, damit die Lücke bis zum Update nicht ausnutzbar war.
5. Aktualisieren. Danach haben wir die PHP-Versionen aktualisiert. Sobald eine Website wieder online war, war das Thema für den Kunden erledigt.

Warum BUZZTION-Websites online bleiben konnten

Für Kunden, die BUZZTION von uns beziehen, war die Lage einfacher. BUZZTION liefert die Website als statische Seiten aus. Besucherinnen und Besucher bekommen fertige Seiten, beim Aufruf läuft kein PHP.
 

Das Redaktionssystem im Hintergrund braucht PHP sehr wohl. Wir konnten es deshalb komplett abdrehen, bis das Update eingespielt war. Die Website selbst blieb die ganze Zeit erreichbar, und PHP2Shell hatte nichts, woran es ansetzen konnte. Bearbeiten ließen sich Inhalte in diesen Stunden nicht, und das war der ganze Preis.

Was wir über unsere Kunden hinaus getan haben

PHP steckt in viel mehr Software als in den Websites, die wir betreuen. Viele Open-Source-Systeme laufen auf PHP. Die Lücke selbst wird am Server geschlossen, aber die Menschen, die diese Systeme einsetzen, müssen davon erfahren. Wo es zu PHP2Shell noch keine Diskussion gab, haben wir deshalb einen Thread gestartet.
Uns ging es darum, eine offene Diskussion über die Möglichkeiten anzustoßen. Das bringt mehr als Geheimniskrämerei hinter verschlossenen Türen. Wichtig ist vor allem, dass auch die Projekte hinter diesen Systemen ihre Nutzerinnen, Nutzer und Kunden informieren und sie durch das Update begleiten. Genau so funktioniert Open Source, wenn es gut läuft.

Was das für Sie bedeutet
 

Sicherheitsupdates werden weiter häufiger kommen, oft mit wenigen Stunden Vorlauf. Das ist der Preis dafür, dass Open-Source-Software sicherer wird, und wir halten ihn für fair. Entscheidend ist, wie schnell eine Website danach wieder geschützt ist.

Am 21. Oktober hat das bei unseren Kunden innerhalb eines Arbeitstags geklappt: Warnung zu Mittag, Schutzmaßnahmen vorbereitet und umgesetzt, Updates eingespielt, sobald sie verfügbar waren. Unser Leitsatz dafür passt in eine Zeile: „Be smart. Prepare and update fast."