PHP2Shell: die PHP-Sicherheitslücke vom Oktober 2026 und warum Website-Wartung wichtig ist

PHP2Shell sind zwei kritische Sicherheitslücken in PHP, über die Angreifer ohne Passwort Code auf Webservern ausführen konnten – die Korrektur erschien am 21. Oktober 2026 in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ein WordPress-Update hilft nicht, denn der Fehler steckt in PHP selbst: Geschützt ist eine Website erst, wenn ihr Server eine korrigierte PHP-Version nutzt – und genau das ist Aufgabe der Website-Wartung.
Inhalt
- Was ist PHP2Shell? Eine PHP-Sicherheitslücke, keine WordPress-Lücke
- Chronologie: was letzte Woche passiert ist
- Was wir getan haben – Website-Wartung in Echtzeit
- PHP2Shell: 6 Schritte, die Sie jetzt erledigen sollten
- Welche PHP-Version ist sicher?
- Warum eine PHP-Sicherheitslücke für Website-Wartung spricht
- Wie es nach PHP2Shell weitergeht
- Häufige Probleme nach einem PHP-Update
- Häufig gestellte Fragen
- Brauchen Sie Hilfe?
Die vergangene Woche hat den Unterschied zwischen einer gewarteten und einer ungewarteten Website deutlich gezeigt. Eine Sicherheitslücke in PHP – der Sprache, auf der WordPress, WooCommerce und laut W3Techs rund 69 % der Websites mit bekannter serverseitiger Sprache laufen – wurde einen Tag vor der geplanten Veröffentlichung bekannt, und erste Angriffsversuche gab es Stunden vor dem Patch. Im Folgenden erkläre ich, was passiert ist, was wir auf unseren Servern getan haben und was Sie heute prüfen sollten.
Was ist PHP2Shell? Eine PHP-Sicherheitslücke, keine WordPress-Lücke
PHP ist die Sprache, mit der Ihr Server die Website „ausführt“: Jeder Seitenaufruf, jede Bestellung und jedes Formular läuft darüber. PHP2Shell ist der Name für zwei kritische Schwachstellen im PHP-Interpreter selbst – CVE-2026-109618 und CVE-2026-109619, beide mit 9,2 von 10 nach CVSS v4.0 bewertet. Laut der offiziellen Sicherheitsmeldung von PHP ermöglichen sie Remote Code Execution (RCE): Ein Angreifer ohne Passwort kann den Server seine Befehle ausführen lassen.
Kurz gesagt liegt die Ursache darin, wie PHP eine Anfrage bei Speichermangel oder einem fatalen Fehler abbricht: Manche Daten bleiben nur halb aufgeräumt und können von einer späteren Anfrage wiederverwendet werden. Betroffen ist jede PHP-Installation, die Webanfragen bedient – PHP-FPM, Apache mod_php, LiteSpeed und andere –, wobei mod_php das höchste Risiko hat. Den gleichen Umfang bestätigt die Sicherheitsmeldung von CERT-EU.
Das Wichtigste für Website-Betreiber: PHP2Shell wird nicht durch ein Update von WordPress, Theme oder Plugins behoben, sondern nur durch eine neue PHP-Version auf dem Server.
Chronologie: was letzte Woche passiert ist
| Datum (UTC) | Ereignis |
|---|---|
| 20. Oktober | PHP kündigt ein kritisches Sicherheitsupdate an. Details gelangen vor der geplanten Veröffentlichung an die Öffentlichkeit. |
| 21. Oktober, morgens | Hosting-Firmen melden Patchstack Angriffsversuche, Cloudflare registriert erste Angriffe – Stunden vor dem Patch. |
| 21. Oktober, ca. 13:30–14:00 | PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erscheinen mit den Korrekturen. PHP 8.1 und älter erhalten keine offizielle Version, nur minimale Quellcode-Backports für 7.4, 8.0 und 8.1. |
| 21.–22. Oktober | Mehrere Proof-of-Concept-Exploits werden veröffentlicht. Massenhafte Angriffsversuche werden beobachtet, ohne bestätigte massenhafte Einbrüche. |
| 23. Oktober | PHP veröffentlicht eine dritte Lücke, CVE-2026-115560. Sie betrifft nur Anwendungen mit ungewöhnlichen Sitzungseinstellungen und wird im nächsten regulären Release behoben. |
Eine ausführliche Chronologie der Angriffe hat Patchstack veröffentlicht, eine technische Analyse Rapid7.
Was wir getan haben – Website-Wartung in Echtzeit
Ich betreue Websites seit 2012, und PHP2Shell gehört zu den schwersten PHP-Sicherheitslücken, die ich erlebt habe. Auf dem Server, auf dem infobgnet.com und die Websites unserer Wartungskunden laufen, wurden die korrigierten Versionen am 21. Oktober installiert – PHP 8.3.36 und 8.2.35 sowie korrigierte Builds für die älteren Zweige. Danach habe ich geprüft, dass alle PHP-Prozesse neu gestartet wurden und mit der neuen Version laufen – nicht mit der alten, die noch im Speicher lag.
Das ist der häufigste Fehler, den ich sehe: Die neue Version ist installiert, aber die alten Prozesse laufen weiter. Alles sieht in Ordnung aus, und trotzdem ist die Website angreifbar. Deshalb heißt Website-Wartung nicht „auf Aktualisieren klicken“, sondern nach jedem Update prüfen.

PHP2Shell: 6 Schritte, die Sie jetzt erledigen sollten
- Prüfen Sie Ihre PHP-Version. In WordPress unter Werkzeuge → Website-Zustand → Bericht → Server. Dort sollte 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder eine neuere Version desselben Zweigs stehen.
- Fragen Sie Ihren Hoster schriftlich. Ist die Version älter, fordern Sie ein Update an. Beim Shared Hosting ist das Aufgabe des Hosters – PHP können Sie dort nicht selbst aktualisieren.
- Stellen Sie sicher, dass PHP neu gestartet wurde. Die Korrektur für PHP2Shell wirkt erst nach einem Neustart der PHP-Prozesse. Ein guter Hoster oder eine Website-Wartung erledigt das automatisch.
- Planen Sie den Umstieg von PHP 8.1 und älter. Diese Versionen erhalten keine offiziellen Korrekturen mehr, und PHP 8.2 erreicht am 31. Dezember 2026 sein Supportende. Sinnvolles Ziel ist PHP 8.3 oder 8.4 – nach einem Test auf einer Kopie der Website.
- Ändern Sie Passwörter und Schlüssel, wenn der Server lange angreifbar war. Forscher haben gezeigt, dass ein PHP2Shell-Angriff den Speicher von PHP auslesen kann – samt Passwörtern, Tokens und API-Schlüsseln. Ändern Sie Admin- und Datenbankpasswörter sowie Schlüssel für Zahlungsdienste.
- Prüfen Sie auf Anzeichen eines Einbruchs über PHP2Shell. Unbekannte Administratoren, neue Dateien in Theme- und Plugin-Ordnern, seltsame Weiterleitungen. Wenn Sie unsicher sind, fordern Sie ein kostenloses SEO-Audit an – es enthält auch eine Sicherheitsprüfung.
Die offiziellen Hinweise von WordPress zum Aktualisieren von PHP finden Sie auf der Seite Update PHP.
Welche PHP-Version ist sicher?
| PHP-Version | Sicher ab | Was zu tun ist |
|---|---|---|
| PHP 8.5 | 8.5.12 | Auf 8.5.12 oder neuer aktualisieren |
| PHP 8.4 | 8.4.27 | Auf 8.4.27 oder neuer aktualisieren |
| PHP 8.3 | 8.3.36 | Auf 8.3.36 oder neuer aktualisieren |
| PHP 8.2 | 8.2.35 | Aktualisieren und 8.3/8.4 planen – Supportende am 31.12.2026 |
| PHP 8.1 und älter | Keine offizielle Version | Nur Backports des Anbieters; dringend auf 8.3/8.4 umsteigen |
Warum eine PHP-Sicherheitslücke für Website-Wartung spricht
Eine Website ohne Wartung verlässt sich darauf, dass jemand anderes das Problem bemerkt. Bei PHP2Shell vergingen zwischen dem Bekanntwerden und den ersten Angriffen Stunden, nicht Wochen. Das leistet eine regelmäßige Website-Wartung in einer solchen Lage:
| Ohne Wartung | Mit Website-Wartung | |
|---|---|---|
| Wer von der Lücke erfährt | Niemand – bis etwas kaputtgeht | Die Wartung, am Tag der Veröffentlichung |
| PHP-Update | Wann der Hoster dazu kommt | Am selben Tag geprüft und bestätigt |
| Neustart und Kontrolle | Findet nicht statt | Teil des Ablaufs |
| Backup vor Änderungen | Falls vorhanden | Immer |
| Kontrolle nach dem Angriff | Nein | Ja – Nutzer, Dateien, Logs |
Bei INFOBGNET kostet die Website-Wartung €70 im Monat und umfasst Updates von WordPress, Theme und Plugins, Backups, Überwachung von Sicherheit und Geschwindigkeit, Betreuung von Hosting und Domain sowie bis zu 1 Stunde Korrekturen. Für Onlineshops lesen Sie unseren Artikel zur Onlineshop-Wartung.
Wie es nach PHP2Shell weitergeht
Mit dem Update vom 21. Oktober ist die Geschichte nicht vorbei. Darauf sollten Sie in den kommenden Wochen achten:
- Die dritte PHP-Lücke (CVE-2026-115560) wird im nächsten regulären Release behoben. Bis dahin empfiehlt PHP, session.upload_progress.enabled zu deaktivieren. Sie betrifft nur Websites mit ungewöhnlichen Sitzungseinstellungen, aber Ihr Hoster sollte die Einstellung ausgeschaltet haben.
- Windows-Server haben am 26. Oktober zusätzliche Builds erhalten – PHP 8.5.12-1, 8.4.27-1, 8.3.36-1 und 8.2.35-1 – mit einer Korrektur in der Brotli-Bibliothek (Meldung von PHP). Läuft Ihre Website auf einem Windows-Server, installieren Sie auch diese.
- PHP 8.2 erreicht am 31. Dezember 2026 sein Supportende. Die nächste Lücke nach PHP2Shell wird für 8.2 nicht mehr behoben – der Umstieg auf 8.3 oder 8.4 sollte daher jetzt erfolgen, nicht erst nach einem Vorfall.
- Weitere Angriffsversuche. Nach einer großen Lücke wie PHP2Shell scannen Bots noch wochenlang Websites. Ungepatchte Websites werden noch lange angegriffen, wenn die Nachrichten längst vorbei sind.
Genau hier zahlt sich Website-Wartung aus: Jemand behält diese Termine für Sie im Blick und aktualisiert rechtzeitig – vor dem nächsten PHP2Shell, nicht danach.
Häufige Probleme nach einem PHP-Update
- Die Website funktioniert nach dem Wechsel auf eine neue PHP-Version nicht mehr. Ursache: ein altes Plugin oder Theme, das für PHP 7 geschrieben wurde. Lösung: auf einer Staging-Kopie testen, das Plugin aktualisieren oder ersetzen und erst dann die Live-Website umstellen.
- Die Version wurde aktualisiert, aber Scanner melden die Website weiter als anfällig für PHP2Shell. Ursache: Alte PHP-Prozesse wurden nicht neu gestartet. Lösung: PHP-FPM/LiteSpeed neu starten oder den Hoster darum bitten.
- Der Hoster antwortet nicht oder nennt keinen Termin. Ursache: billiges oder nicht verwaltetes Hosting. Lösung: Umzug zu einem Anbieter, der am selben Tag patcht – auch das gehört zur Website-Wartung.
- „Ich habe WordPress aktualisiert, also bin ich sicher.“ Ursache: Verwechslung von WordPress und PHP. Lösung: die PHP-Version im Website-Zustand prüfen – für PHP2Shell war kein WordPress-Update nötig, und es gab auch keins.
Allgemeine Gewohnheiten für mehr Sicherheit finden Sie unter Wie Sie im Internet sicher bleiben.
Häufig gestellte Fragen
Ist meine WordPress-Website von PHP2Shell betroffen?
Ja, wenn Ihr Server eine PHP-Version vor 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 nutzt. Prüfen Sie das unter „Werkzeuge → Website-Zustand → Bericht → Server“. Die WordPress-Version spielt keine Rolle.
Muss ich wegen PHP2Shell WordPress aktualisieren?
Nein. Die Lücke steckt in PHP, deshalb ist die Korrektur eine neue PHP-Version auf dem Server. WordPress aktuell zu halten bleibt wichtig, löst dieses Problem aber nicht.
Was ist CVE-2026-115560 vom 23. Oktober?
Eine dritte PHP-Lücke im Zusammenhang mit dem Upload-Fortschritt in Sitzungen. Sie betrifft nur Anwendungen mit ungewöhnlichen Sitzungseinstellungen und wird im nächsten regulären Release behoben. Bis dahin empfiehlt PHP, session.upload_progress.enabled zu deaktivieren.
Ich nutze PHP 7.4 – was soll ich tun?
PHP 7.4 wird seit Jahren nicht mehr offiziell unterstützt. Es gibt nur minimale Quellcode-Patches, die manche Anbieter einbauen. Am sichersten ist der Umstieg auf PHP 8.3 oder 8.4 nach einem Test auf einer Kopie der Website.
Was kostet die Website-Wartung bei INFOBGNET?
€70 im Monat. Enthalten sind Updates, Backups, Überwachung von Sicherheit und Geschwindigkeit, Hosting und Domain sowie bis zu 1 Stunde Korrekturen pro Monat.
Brauchen Sie Hilfe?
Wenn Sie nicht sicher sind, welche PHP-Version Ihre Website nutzt oder ob Ihr Hoster rechtzeitig reagiert hat, schreiben Sie uns – wir prüfen es. Und wenn Sie sich nie wieder darum kümmern möchten, sehen Sie sich unsere Website-Wartung an.

Cookie-Banner: Was die EU-Aufsichtsbehörden 2026 erwarten
Ein rechtskonformes Cookie-Banner blockiert nicht notwendige Cookies, bis der Besucher wählt, zeigt „Ablehnen“ genauso deutlich wie „Akzeptieren“ und lässt Menschen ihre Entscheidung jederzeit ändern.…
Weiterlesen →
Black Friday: Website-Vorbereitung 2026 – Checkliste für Geschwindigkeit, SEO und EU-Preisregeln
Die Vorbereitung der Website auf den Black Friday bedeutet: Geschwindigkeit, Checkout und Sicherheit testen, eine dauerhafte Aktionsseite für SEO auffrischen und Preise nach den…
Weiterlesen →
Barrierefreiheitsstärkungsgesetz (BFSG) 2026: Was Website-Betreiber in der EU wissen müssen
Wenn Ihre Website Produkte oder Dienstleistungen an Kunden irgendwo in der EU verkauft, gibt es eine gesetzliche Pflicht, die Sie vielleicht übersehen haben: die…
Weiterlesen →Möchten Sie ein SEO-Audit Ihrer Website?
Ein kostenloses SEO-Audit, ganz unverbindlich. Einfach ein konkreter Blick darauf, was sich verbessern lässt.