Kurz gesagt: Wer die PHP-Lücke PHP2Shell heute noch geschlossen haben will, braucht vier Dinge: das richtige Update, den Neustart aller PHP-Prozesse, die Prüfung auf bereits eingeschleusten Schadcode und einen Nachweis. Sind Sie betroffen? Rufen Sie an. Wir helfen. Wir übernehmen das remote, ab der ersten Nachricht.
Jetzt nichts löschen und nichts neu aufsetzen. Auch beim Patchen gilt: Erst sichern, dann ändern. Falls schon etwas eingedrungen ist, brauchen wir den Stand von Dateien und Logs. Notfall melden, wir klären mit Ihnen die Reihenfolge.
Warum die Lücke nicht warten kann
Die beiden Lücken CVE-2026-109618 und CVE-2026-109619 stecken in PHP selbst und erlauben Schadcode aus der Ferne ohne Anmeldung. Das BSI hat Warnstufe 3 (Orange) ausgerufen und empfiehlt das sofortige Update. Wenn das nicht sofort geht, sollen Webserver vorübergehend vom Netz. Laut Medienberichten gab es schon vor Veröffentlichung der Patches am 21.10.2026 erste beobachtete Angriffsversuche. Cloudflare hat Versuche beobachtet und Schutzregeln ausgerollt, warnt aber, dass Regeln anhand der Anfragedaten allein nicht genügen.
Wichtig für Betreiber: Ein CMS-Update schließt die PHP-Lücke nicht. Auch WordPress.org plant laut Berichten kein Update dagegen, weil die Lücke im Interpreter liegt. Geschlossen wird sie nur auf der PHP-Ebene, also bei dem, was Ihr Server tatsächlich ausführt.
Was Sie jetzt sofort tun
- Zielversion kennen. Behoben sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.2 erreicht am 31.12.2026 das Ende der Unterstützung, planen Sie das mit ein.
- Alle Systeme erfassen. Auch Testserver, Containerimages und Altsysteme, die aus dem Internet erreichbar sind.
- Zuständigkeit klären. Bei Hosting-Paketen und Managed Servern spielt der Anbieter ein. Fragen Sie schriftlich nach Version und Neustart.
- Logs aufbewahren. Ab dem 20.10.2026, so die Fachpresse.
- Fenster abstimmen. Ein Neustart unterbricht kurz laufende Anfragen. Legen Sie einen Zeitpunkt fest, an dem jemand Entscheidungen treffen kann.
- Nicht warten, wenn es offen ist. Kann nicht sofort gepatcht werden, prüfen Sie mit uns das Abschotten oder die Übergangsmaßnahmen.
Wie hilft PHP SOS konkret?
- Lage aufnehmen: Wir erfassen Systeme, PHP-Versionen, Betriebsarten, Hoster und Erreichbarkeit und legen die Reihenfolge fest: erst die am stärksten exponierten Systeme.
- Sichern und schließen: Wir sichern den Ist-Zustand, spielen das Update ein oder bringen das Hosting auf den nachweislich gepatchten Stand und starten alle Prozesse neu. Bei Containern bauen wir das Image neu und rollen es aus.
- Prüfen und bereinigen: Weil ein Patch Schadcode nicht entfernt, prüfen wir auf Zeichen eines früheren Einbruchs und bereinigen bei Bedarf.
- Härten und berichten: Sie erhalten einen schriftlichen Nachweis je System und Empfehlungen, damit das nächste Update schneller läuft. Das Leistungsbild beschreibt der PHP-Patch-Service.
Update, Neustart, Nachweis: worauf es ankommt
Der häufigste Fehler ist ein Update ohne Neustart. Solange alte Prozesse im Speicher laufen, bleibt der verwundbare Code aktiv, auch wenn die Dateien neu sind. Die Anleitung dazu steht auf der Seite PHP-FPM und alle Worker neu starten. Der zweite Fehler ist, die Anzeige zu glauben: Distributionen und Hoster liefern oft Backports, dann bleibt die Versionsnummer gleich. Belastbar ist der Paket-Changelog mit den CVE-Nummern, bei Debian-Familie mit apt-get changelog <paket>.
Zusätzlich gilt laut PHP-Handbuch seit den Sicherheitsreleases die neue Direktive memory_hard_limit_percent. Kennt eine PHP-Version sie nicht, ist sie betroffen. Der Test ist kurz:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Er muss je Version und Betriebsart laufen, weil die Kommandozeile eine andere PHP-Version nutzen kann als der Webserver. Zum Abschluss halten wir das Ergebnis fest, damit Sie es Ihrem Hoster, Versicherer oder Auftraggeber zeigen können.
Wenn das Update nicht sofort geht
Es gibt Gründe, warum ein Update nicht heute möglich ist: eine alte Anwendung, die auf neuere PHP-Versionen nicht läuft, ein Hoster ohne Freigabe, ein Containerimage in einer festen Pipeline. Für diese Fälle nennt php.net Übergangsmaßnahmen, die ausdrücklich kein vollständiger Schutz sind: memory_limit=-1 so setzen, dass Anwendungen es nicht überschreiben können, post_max_size begrenzen, session.upload_progress.enabled=0 und auf PHP 8.5 fatal_error_backtraces=0, jeweils mit Neustart. Dazu kommen Schutzregeln am Rand, die ein Update nicht ersetzen. Ein kursierender Tipp, alle Anfragen mit PHPSESSID zu blockieren, wird von Fachautoren ausdrücklich abgelehnt.
Welche Maßnahmen zu Ihrem System passen und was sie brechen können, besprechen wir vorher. Mehr dazu auf der Seite Sofortmaßnahmen, wenn Sie noch nicht patchen können und beim Thema WAF und virtuelles Patching. Für PHP 8.1 und älter gilt eine eigene Lage, die unter PHP 8.1 und älter: Was jetzt gilt beschrieben ist.
Was Sie uns schicken sollten
- Liste der Server und Hoster, soweit vorhanden
- Ausgabe von
php -vje System und Hinweis auf die Betriebsart - Angabe, ob Container, Plesk, cPanel oder ein Managed-Angebot im Einsatz ist
- gewünschtes Zeitfenster und Ansprechperson für Neustarts
- Hinweise auf Auffälligkeiten seit dem 17.10.2026
Warum PHP SOS
Wir arbeiten Made in Germany und sind seit über 25 Jahren mit unserem Partnernetzwerk aus Cyber-Profis auf IT-Sicherheit spezialisiert. Sie haben einen Ansprechpartner, der das Update begleitet, den Neustart prüft und den Nachweis liefert. Wir arbeiten remote, ohne Anfahrt, und dokumentieren jeden Schritt. Wir versprechen keine Wunder: Ein Patch schließt die Lücke, er beweist nicht, dass vorher nichts geschehen ist, und das sagen wir Ihnen auch so.
Sind Sie betroffen? Rufen Sie an. Wir helfen.
Lassen Sie die Lücke nicht länger offen stehen. Rufen Sie an oder schreiben Sie per WhatsApp. Wir übernehmen ab der ersten Nachricht und bleiben dabei, bis der Vorfall abgeschlossen und dokumentiert ist. Jetzt Notfall melden.
Häufige Fragen
Kann ich die PHP-Sicherheitslücke selbst schließen oder brauche ich Hilfe?
Ein Update ist für Admins machbar, aber fehleranfällig: Es muss die Version gelten, die wirklich ausliefert, und alle Prozesse müssen neu starten. Wer mehrere Server, Containerimages oder einen Hoster mit Eigenheiten hat, spart mit Unterstützung Zeit und Fehler.
Muss PHP nach dem Update neu gestartet werden?
Ja. Neue Dateien allein reichen nicht, solange alte PHP-Prozesse im Speicher laufen. Alle Worker beziehungsweise Prozesse müssen neu gestartet werden, bei mod_php der Webserver.
Was tun, wenn es noch kein Update für meine PHP-Version gibt?
Für PHP 8.1 und älter liefert das PHP-Projekt keine offiziellen Updates mehr. Dann sind ein nachweislich gepatchter Backport des Anbieters, eine Migration auf eine gepflegte Version oder Übergangsmaßnahmen nötig, die aber keinen vollständigen Schutz bieten.
Reicht es, session.upload_progress.enabled auf 0 zu setzen?
Nein. Laut Fachberichten schließt die Einstellung allein nicht beide Lücken, das PHP-Update bleibt Pflicht. Setzen Sie sie nur in php.ini, FPM-Pool oder Serverkonfiguration, nicht per ini_set() oder .user.ini.
Woher weiß ich, dass die Lücke danach wirklich geschlossen ist?
Durch einen Nachweis am laufenden System: Version oder Paket-Changelog, ein Test auf die neue Direktive memory_hard_limit_percent und die Bestätigung, dass alle Prozesse nach dem Update neu gestartet wurden.