Das Wichtigste in Kürze
- Die Lücken CVE-2026-109618 und CVE-2026-109619 betreffen PHP-Installationen, die Webseiten ausliefern, unabhängig vom eingesetzten CMS.
- Sicher sind die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder Pakete Ihres Hosters mit eingespieltem Fix.
- Nach dem Update müssen die PHP-Prozesse neu gestartet werden, sonst läuft weiter der alte Code.
- PHP 8.1 und älter erhalten keine regulären Updates mehr. Hier ist ein Umstieg auf eine aktuelle Version der sichere Weg.
- Fragen Sie heute bei Hoster oder Dienstleister nach, ob Ihr Server bereits aktualisiert ist, und lassen Sie sich das bestätigen.
Was ist passiert?
Am 20. Oktober 2026 kündigte das PHP-Projekt eine kritische Sicherheitsaktualisierung an, einen Tag später erschienen die korrigierten Versionen. Behoben wurden zwei Fehler im Kern von PHP, also nicht in einem Plugin oder einer einzelnen Anwendung, sondern in der Programmiersprache selbst, auf der ein Großteil des Webs läuft.
Vereinfacht gesagt geht es um Fehler im Umgang mit dem Arbeitsspeicher. Bei CVE-2026-109618 kann PHP bei Speichermangel interne Daten nur halb aufgebaut zurücklassen und diese anschließend trotzdem weiterverarbeiten. Bei CVE-2026-109619 bleiben Daten einer Anfrage im Speicher zurück und können von der nächsten Anfrage an denselben Prozess genutzt werden. Beide Fehler lassen sich unter bestimmten Bedingungen so ausnutzen, dass Angreifer eigenen Code auf dem Server ausführen. Sicherheitsforscher stufen beide Lücken mit 9,2 von 10 Punkten (CVSS 4.0) als kritisch ein.
Besonders heikel: Nach Angaben der Forscher genügt im ungünstigsten Fall eine einzige Anfrage ohne Anmeldung, und der Angriff greift, bevor der Code Ihrer Website überhaupt ausgeführt wird. Zusätzlich wurde gezeigt, dass sich Inhalte aus dem Arbeitsspeicher auslesen lassen, darunter Passwörter, Zugangsdaten und Schlüssel. Amazon registrierte nach eigenen Angaben einen ersten Angriffsversuch bereits am 17. Oktober, also vor der Veröffentlichung. Behörden wie das britische NCSC und die US-Behörde CISA haben dringende Warnungen herausgegeben, in Deutschland mahnt das BSI zur sofortigen Aktualisierung.
Ist meine Website betroffen?
Wahrscheinlich ja, solange Ihr Server noch nicht aktualisiert wurde. Betroffen sind alle PHP-Installationen, die Webanfragen beantworten, egal ob über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Laut PHP-Projekt und Sicherheitsforschern ist dabei nicht entscheidend, welches CMS oder welcher Shop darauf läuft.
Auch wenn Ihre Website kein PHP nutzt, lohnt ein Blick in die übrige Technik: PHP steckt in vielen Produkten, etwa in Verwaltungsoberflächen von Firewalls, Routern, Hosting-Panels oder Branchensoftware. Mehrere Hersteller prüfen ihre Produkte derzeit, einige haben bereits bestätigt, betroffen zu sein.
- Ihre Website läuft mit WordPress, TYPO3, Contao, Joomla, Drupal, Shopware, WooCommerce, Magento oder einem anderen PHP-System
- Sie betreiben Kundenportale, Bewerbermanagement, Konfiguratoren oder interne Tools auf PHP-Basis
- Es laufen ältere Projekte oder Testumgebungen, um die sich niemand mehr aktiv kümmert
- Geräte oder Software im Unternehmen haben eine Weboberfläche, deren Hersteller PHP einsetzt
Diese PHP-Versionen schließen die Lücken
Das PHP-Projekt hat für alle noch unterstützten Versionszweige korrigierte Versionen veröffentlicht. Für die älteren Zweige 7.4, 8.0 und 8.1 gibt es nur Quellcode-Korrekturen, die Hoster oder Linux-Distributionen selbst einbauen müssen.
Wichtig: Viele Hoster und Linux-Distributionen spielen die Korrektur in ihre eigenen Pakete ein und behalten dabei die alte Versionsnummer. Eine niedrigere Nummer bedeutet dann nicht automatisch, dass Ihr Server ungeschützt ist. Verlassen Sie sich deshalb nicht allein auf die Versionsanzeige, sondern lassen Sie sich vom Hoster bestätigen, dass der Fix für PHP2Shell eingespielt ist.
| PHP 8.5 | ab 8.5.12 |
|---|---|
| PHP 8.4 | ab 8.4.27 |
| PHP 8.3 | ab 8.3.36 |
| PHP 8.2 | ab 8.2.35 (Support endet am 31.12.2026) |
| PHP 8.1, 8.0, 7.4 | keine offiziellen Versionen, nur Quellcode-Korrekturen über Hoster oder Distribution |
| PHP 7.3 und älter | keine Korrektur, Umstieg nötig |
Die Versionsnummer Ihrer Website finden Sie meist im Kundenbereich Ihres Hosters, bei WordPress unter Werkzeuge, Website-Zustand, Info, Server.
Was Sie jetzt veranlassen sollten
Als Geschäftsführung oder Marketingverantwortliche müssen Sie die Updates nicht selbst einspielen. Sie sollten aber dafür sorgen, dass es jemand tut, und sich das bestätigen lassen. Diese Reihenfolge hat sich bewährt:
- Bestandsaufnahme: Alle Websites, Shops, Portale und Testumgebungen auflisten, die auf PHP laufen, auch alte Kampagnenseiten und Subdomains
- Hoster oder IT-Dienstleister schriftlich fragen, ob PHP auf allen Servern aktualisiert und die PHP-Prozesse neu gestartet wurden
- Bei eigenen Servern: Pakete aktualisieren, PHP-FPM bzw. Webserver neu starten und prüfen, ob wirklich die neue Version Anfragen beantwortet
- Bei PHP 8.1 und älter: Umstieg auf eine unterstützte Version planen und Website vorher in einer Testumgebung prüfen
- Wenn ein Update nicht sofort möglich ist: Übergangsmaßnahmen umsetzen lassen oder die Anwendung vorübergehend vom Netz nehmen
- Nach dem Update auf Spuren eines Angriffs prüfen lassen: neue Administratorkonten, unbekannte Dateien, geänderte Inhalte
- Passwörter, Datenbankzugänge und API-Schlüssel erneuern, wenn der Server vor dem Update öffentlich erreichbar war
Wenn ein Update nicht sofort möglich ist
Für die Zeit bis zum Update gibt es Maßnahmen, die das Risiko verringern, aber nicht beseitigen. Dazu gehört, eine bestimmte PHP-Funktion zur Anzeige des Upload-Fortschritts serverseitig abzuschalten und Größe und Umfang eingehender Anfragen zu begrenzen. Viele Hoster haben das bereits vorsorglich auf ihren Servern erledigt. Anbieter wie Cloudflare haben zudem Filterregeln für bekannte Angriffsmuster bereitgestellt.
Alle Fachstellen betonen jedoch: Nur das Update schließt die Lücken vollständig. Das britische NCSC empfiehlt sogar, Systeme vom Netz zu nehmen, wenn sie weder aktualisiert noch mit Übergangsmaßnahmen geschützt werden können. Für eine Unternehmenswebsite ist ein paar Stunden offline meist das kleinere Übel als ein kompromittierter Server.
Was ein Angriff für Sie bedeuten würde
Wer Code auf Ihrem Webserver ausführen kann, hat in der Regel Zugriff auf alles, was dort liegt: Website-Inhalte, Kontaktanfragen, Bewerbungen, Kundendaten aus Shop oder Portal sowie die Zugangsdaten zur Datenbank. Typische Folgen sind eingeschleuste Schadsoftware, Spam- oder Phishing-Seiten unter Ihrer Domain, Rankingverluste bei Google und Warnhinweise im Browser.
Hinzu kommt die rechtliche Seite. Sind personenbezogene Daten betroffen, etwa Anfragen über Ihr Kontaktformular oder Bewerbungen, kann eine Meldung an die zuständige Datenschutzaufsicht nötig sein. Nach Art. 33 DSGVO muss sie in der Regel innerhalb von 72 Stunden erfolgen, nachdem Ihnen die Verletzung bekannt geworden ist. Zudem verlangt Art. 32 DSGVO angemessene technische Schutzmaßnahmen, wozu das zeitnahe Einspielen von Sicherheitsupdates gehört.
Das größere Dauerproblem: veraltete PHP-Versionen
PHP2Shell ist ein besonders schwerer Fall, aber kein Einzelfall. Jede PHP-Version erhält nur eine begrenzte Zeit Sicherheitsupdates: zwei Jahre volle Pflege, danach zwei Jahre nur noch Sicherheitskorrekturen, jeweils bis zum 31. Dezember. PHP 8.1 ist seit dem 31. Dezember 2025 ohne offizielle Updates, für PHP 8.2 endet die Unterstützung am 31. Dezember 2026.
Trotzdem laufen viele Websites auf Versionen, die längst keine Updates mehr bekommen. Laut W3Techs nutzten am 22. Oktober 2026 noch 26,9 Prozent der PHP-Websites Version 7 und 7,7 Prozent sogar Version 5. Solche Seiten bleiben bei neuen Lücken dauerhaft angreifbar, weil es für sie schlicht keine Korrektur mehr gibt.
Der Umstieg auf eine aktuelle Version ist selten ein Knopfdruck. Ältere Themes, Plugins oder Eigenentwicklungen funktionieren mit neuen PHP-Versionen oft nicht mehr. Planen Sie den Wechsel deshalb mit Testumgebung und genug Vorlauf, und nehmen Sie das Supportende von PHP 8.2 Ende dieses Jahres zum Anlass, jetzt zu prüfen.
Plugins und Erweiterungen nicht vergessen
Die meisten Sicherheitslücken stecken nicht in PHP selbst, sondern in Plugins, Themes und Erweiterungen. Allein für WordPress zählte der Sicherheitsanbieter Patchstack im Jahr 2025 insgesamt 11.334 neue Lücken, 42 Prozent mehr als im Vorjahr. 91 Prozent davon betrafen Plugins, nur sechs den WordPress-Kern. Bei 46 Prozent gab es zum Zeitpunkt der Veröffentlichung noch kein Update des Herstellers.
Wie schnell Angreifer reagieren, zeigt eine weitere Zahl aus dem Bericht: Bei stark ausgenutzten Lücken vergingen im gewichteten Median nur fünf Stunden bis zu massenhaften Angriffen. Wer Updates erst bei Gelegenheit einspielt, ist damit fast immer zu spät. Weniger ist hier mehr: Jedes Plugin, das Sie nicht brauchen, ist eine Angriffsfläche weniger.
Sicherheit als laufender Prozess
Eine Website ist nach dem Livegang nicht fertig, sondern braucht regelmäßige Pflege wie jede andere technische Anlage auch. Für Unternehmen im Mittelstand haben sich ein paar einfache Regeln bewährt, die viel Risiko aus dem Alltag nehmen.
- Eine verantwortliche Person oder einen Dienstleister mit klarer Zuständigkeit für Updates benennen
- Sicherheitsupdates für PHP, CMS und Plugins zeitnah einspielen, kritische Lücken innerhalb von Stunden statt Wochen
- Nicht genutzte Plugins, Themes, Testumgebungen und alte Microsites löschen
- Tägliche Backups außerhalb des Webservers, die regelmäßig testweise zurückgespielt werden
- Zugänge mit starken Passwörtern und Zwei-Faktor-Anmeldung schützen
- Supportenden von PHP und CMS im Kalender haben und Umstiege rechtzeitig planen
Quellen
- PHP-Projekt: Ankündigung der Sicherheitsversionen (php.net, Oktober 2026)
- Qualys: PHP2Shell, technische Details, Versionen und Übergangsmaßnahmen
- Help Net Security: PHP2Shell, critical PHP vulnerabilities patched
- NCSC (UK): Critical security issue affecting PHP
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching
- PC Games Hardware: PHP2Shell, BSI warnt vor gefährlichen Angriffen
- PHP Watch: Neue Support-Zeiträume für PHP-Versionen
- W3Techs: Nutzung von PHP und PHP-Versionen
- Patchstack: State of WordPress Security in 2026
- DSGVO Art. 33: Meldung von Verletzungen an die Aufsichtsbehörde