php2shell: Nicht die Größe der IT-Abteilung zählt, sondern Server pro Admin

Es gibt Tage, an denen in IT-Abteilungen niemand pünktlich Feierabend macht. Der 21. Oktober 2026 war so einer. Unter dem Namen php2shell wurden zwei kritische Sicherheitslücken in PHP bekannt, der Skriptsprache, auf der ein Großteil aller Websites läuft. Wie heise online berichtet, machen die beiden Fehler Webserver mit PHP direkt aus dem Netz angreifbar – betroffen sind Versionen der letzten 20 Jahre.

Die Lücken (CVE-2026-109618 und CVE-2026-109619) sind mit 9,2 von 10 Punkten auf der CVSS-Skala bewertet. Sie ermöglichen eine sogenannte Remote Code Execution: Angreifer führen eigenen Code auf einem fremden Server aus, im Zweifel ohne sich anzumelden. Wichtig für Website-Betreiber: Die Lücke steckt in PHP selbst, also eine Ebene unter WordPress, Joomla oder dem Onlineshop. Ein Update des CMS oder der Plugins schließt sie nicht.

Die Reaktion vieler Organisationen: Stecker ziehen. Laut 20 Minuten haben die Charité und die Stadt Mainz Webseiten vom Netz genommen, auch mehrere Schweizer Anbieter schalteten ihre Seiten zeitweise ab. Verständlich. Aber auch ein Offenbarungseid.

Bei meinen Kunden lief alles weiter. Innerhalb weniger Stunden nach dem Release waren alle Server, die ich betreue, aktualisiert. Ohne Abschaltung, ohne Ausfall, ohne Nebenwirkungen.

Die falsche Kennzahl: Wie groß ist Ihre IT-Abteilung?

Viele Unternehmer glauben, für ausfallsicheren und schnell gepatchten Serverbetrieb brauche es eine große IT-Abteilung. Mehr Admins, mehr Sicherheit. Das klingt logisch – und ignoriert die eigentlich entscheidende Kennzahl: Server pro Admin.

Bei großen Anbietern verwaltet eine zwölfköpfige Admin-Crew schnell mehrere tausend Server und virtuelle Maschinen (VMs). Das sind mehrere hundert Systeme pro Kopf. Das funktioniert nur mit Automatisierungswerkzeugen, die Updates auf Knopfdruck ausrollen. Wenn alles gut geht. Doch dazwischen liegen Freigabeprozesse, Testumgebungen, Abstimmungsrunden und die Frage, welche Anwendung auf welcher Maschine eigentlich noch mit welcher PHP-Version läuft. Genau dort entsteht die Panik – und am Ende die Abschaltung.

Bei einem kleinen Dienstleister kommen auf einen Admin vielleicht 75 Server. Rechnen wir mit fünf Minuten pro System für Update, Neuladen des Dienstes und Kontrolle, sind das gut sechs Stunden. Manuell, mit Sorgfalt, und meist schneller als der Konzern mit seiner Pipeline.

Natürlich ist das eine vereinfachte Milchmädchenrechnung. Kein Server gleicht dem anderen, und auch ich setze Werkzeuge ein, wo sie sinnvoll sind. Aber die Richtung stimmt: Überschaubarkeit ist im Ernstfall ein Geschwindigkeitsvorteil, kein Nachteil.

Cloud ist auch nur ein Server

Noch kritischer wird es dort, wo Konzerne beschließen, ihre IT-Abteilung könne doch auch selbst in der Cloud hosten. Eine VM bei AWS oder Azure ist am Ende genau das: ein Server. Der Cloud-Anbieter kümmert sich um Hardware und Rechenzentrum. Betriebssystem, PHP und alles darüber sind Ihre Sache (das sogenannte Modell der geteilten Verantwortung, Shared Responsibility).

Auf schnelles Patchen sind die wenigsten dieser Umgebungen vorbereitet. Es fehlt ein aktuelles Inventar. Container-Images bringen ihr eigenes, längst vergessenes PHP mit. Und die Test-VM, die vor zwei Jahren jemand aufgesetzt hat, hängt noch immer öffentlich im Netz. Die Cloud hat das Problem nicht gelöst – sie hat es nur unübersichtlicher gemacht.

Patchen ohne Ausfall: kein Hexenwerk, sondern Routine

Was es im Ernstfall braucht, ist weniger Personal als Ordnung:

• Vollständiges Inventar: Ich weiß für jeden Server, welche PHP-Version in welcher Betriebsart läuft – ob als PHP-FPM (FastCGI Process Manager) oder als Apache-Modul.
• Gepflegte Versionen: Korrigiert wurden PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter liefert das PHP-Projekt keine Sicherheitsupdates mehr. Wer noch PHP 7.4 betreibt, steht jetzt mit einer offenen Lücke da. Systeme aktuell zu halten, zahlt sich genau an Tagen wie diesem aus.
• Neu laden statt abschalten: Ein systemctl reload php8.3-fpm oder apachectl graceful lädt den Dienst neu, ohne laufende Anfragen abzubrechen. Für Besucher der Website passiert schlicht nichts.
• Prüfen statt hoffen: Nach jedem Update kontrolliere ich die laufende Version und den Status der Websites. Das Monitoring mit Uptime Kuma meldet sofort, wenn etwas hakt.
• Überbrückung bis zum Patch: Das PHP-Team hat Einstellungen veröffentlicht, die das Risiko senken, etwa das Abschalten der Upload-Fortschrittsanzeige. Es nennt sie selbst aber ausdrücklich nur eine vorübergehende Krücke.

Erfahrung ist der eigentliche Faktor

php2shell war nicht die erste kritische Lücke, die sofort geschlossen werden musste. Heartbleed, Log4Shell – jede dieser Nächte hat den Ablauf geschärft. Wer so etwas mehrfach durchgemacht hat, hat einen Plan in der Schublade und muss nicht erst eine Krisensitzung einberufen.

Das ist kein Heldentum. Es ist Handwerk: dokumentierte Systeme, überschaubare Strukturen und ein Ansprechpartner, der Ihre Server kennt. Und auch php2shell wird nicht die letzte Lücke dieser Art gewesen sein.

Fazit: Klein ist kein Risiko – unübersichtlich schon

Die Größe einer IT-Abteilung sagt wenig darüber aus, wie schnell Ihre Website im Ernstfall abgesichert ist. Entscheidend ist, wie viele Systeme ein Admin wirklich im Blick hat und wie gut er sie kennt. Während andere ihre Angebote vom Netz nahmen, liefen die Websites meiner Kunden einfach weiter – gepatcht und geprüft.

Wissen Sie, welche PHP-Version gerade auf Ihrem Server läuft?

Seit 30 Jahren betreibe ich Linux-Server und sorge dafür, dass Sicherheitslücken geschlossen sind, bevor sie zum Problem werden. Mit meinem Managed Hosting bekommen Sie wöchentliche Sicherheits-Updates, 24/7-Monitoring und im Ernstfall einen Ansprechpartner, der sofort handelt.

Schreiben Sie mir über das Kontaktformular oder direkt per WhatsApp.