Am 21. Oktober 2026 hat das PHP-Team Fixes für zwei kritische Sicherheitslücken veröffentlicht, CVE-2026-109618 und CVE-2026-109619, zusammen PHP2Shell genannt. Ein Angreifer braucht dafür weder Login noch Passwort. Eine einzige präparierte Anfrage an Ihre Website kann reichen, um eigenen Code auf dem Server auszuführen und die Seite zu übernehmen. Wenige Stunden nach dem Release meldete die Sicherheitsfirma watchTowr Angriffsversuche auf beide Lücken, und Cloudflare berichtete von ersten Attacken.
Wenn Ihre Website, Ihr Onlineshop oder Ihr Admin-Panel auf PHP läuft, braucht Ihr Server noch heute die aktualisierte PHP-Version.
Was passiert ist
Das PHP-Team hat am 20. Oktober ein kritisches Release angekündigt und am 21. Oktober um 14:00 UTC die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Das PHP-Team bewertet beide Lücken mit 9,2 von 10 nach CVSS v4.0, also kritisch. Die eine betrifft den Umgang von PHP mit erschöpftem Speicher. Die andere sorgt dafür, dass Daten aus einer Anfrage in die nächste Anfrage im selben Serverprozess durchsickern.
Betroffen ist jede Art, PHP auf einem Webserver zu betreiben: PHP-FPM, Apache mit mod_php, php-cgi, LiteSpeed und FrankenPHP. Am höchsten stuft das PHP-Team das Risiko bei Apache mit mod_php ein. Das Advisory beschreibt einen vorgeführten Exploit, bei dem eine Anfrage ohne Login den Angriff auslöst, noch bevor irgendein Code der Website läuft.
Bis zum Abend des 21. Oktober hatte keine Sicherheitsfirma einen bestätigten Einbruch gemeldet. Code, der angeblich die Lücken ausnutzt, kursiert bereits im Netz, und Massenangriffe können jederzeit beginnen.
Sind Sie betroffen?
Prüfen Sie diese Punkte. Ein einziges „Ja“ genügt.
- Ihre Website läuft auf WordPress, WooCommerce, Laravel, OpenCart, Bitrix, Drupal, Magento oder einem anderen PHP-System.
- Ihr Unternehmen hat ein Admin-Panel, ein Kundenportal oder eine API in PHP. Das Backend einer mobilen App zählt auch dazu.
- Sie haben von Ihrem Hoster oder Entwickler keine Bestätigung, dass PHP auf Ihrem Server schon aktualisiert ist.
- Auf Ihrem Server läuft ein Hosting-Panel wie aaPanel. Einige Panels hatten am Tag des Releases noch kein aktualisiertes PHP.
- Ihre PHP-Version ist 8.1 oder älter.
Wenn Sie die Antworten nicht kennen, ist das Grund genug, heute nachzufragen.
Was ein Angreifer mit Ihrer Website anfangen kann
Wer Code auf dem Server ausführt, hat dieselben Zugriffsrechte wie Ihre Website. Konkret heißt das:
- volle Kontrolle über die Website: Seiten ändern, Admin-Konten anlegen, Besucher umleiten;
- Zugriff auf die Datenbank: Namen, E-Mail-Adressen, Anschriften und Bestellungen Ihrer Kunden;
- Schadsoftware oder Spam-Seiten auf Ihrer Website;
- eine Google-Warnung in den Suchergebnissen und im Browser, die Traffic und Umsatz stoppt, bis alles bereinigt ist.
Eine kompromittierte Website zu bereinigen kann Tage dauern, manchmal muss sie komplett neu aufgesetzt werden. Ein Update dauert Stunden.
Was Sie heute tun sollten
1. Finden Sie Ihre PHP-Version heraus. Ihr Hosting-Panel zeigt sie an, meist unter „PHP-Version“ oder „PHP-Einstellungen“. In WordPress öffnen Sie Werkzeuge → Website-Zustand → Bericht → Server. Unter Ubuntu kann nach einem Sicherheitsupdate weiterhin eine alte Nummer wie 8.3.6 angezeigt werden, weil Ubuntu das Paket patcht und die Versionsnummer beibehält. Ihr Hoster oder Entwickler muss dann die Paketversion prüfen.
2. Bitten Sie Ihren Hoster oder Entwickler, PHP zu aktualisieren. Diese Nachricht können Sie unverändert schicken:
Guten Tag, am 21. Oktober 2026 hat PHP Fixes für die kritischen Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 (PHP2Shell) veröffentlicht. Bitte bestätigen Sie uns, dass PHP auf unserem Server auf eine korrigierte Version aktualisiert ist (8.5.12, 8.4.27, 8.3.36, 8.2.35 oder ein gepatchtes Paket der Distribution) und dass PHP-FPM bzw. Apache neu gestartet wurde. Falls bei uns PHP 8.1 oder älter läuft, teilen Sie uns bitte mit, wie Sie den Fix einspielen wollen. Bitte prüfen Sie außerdem die Server-Logs auf Anzeichen einer Ausnutzung seit dem 21. Oktober.
3. Wenn Sie PHP 8.1 oder älter nutzen, planen Sie den Umstieg auf eine unterstützte Version. Für 7.4, 8.0 und 8.1 hat das PHP-Team nur Fixes im Quellcode veröffentlicht. Jemand muss PHP mit diesen Fixes aus dem Quellcode bauen oder die Website auf eine neuere Version umziehen.
Wenn Sie session.upload_progress.enabled in den PHP-Einstellungen abschalten, schließen Sie einen Teil des Angriffswegs. Laut PHP-Team macht das einen Server aber nicht sicher. Sehen Sie es als Notlösung bis zum Update.
Ihre Version und was zu tun ist
| Ihre PHP-Version | Was zu tun ist |
|---|---|
| 8.5 | Auf 8.5.12 aktualisieren |
| 8.4 | Auf 8.4.27 aktualisieren |
| 8.3 | Auf 8.3.36 aktualisieren |
| 8.2 | Auf 8.2.35 aktualisieren. Der Support für 8.2 endet am 31. Dezember 2026, planen Sie also das nächste Upgrade |
| 8.1, 8.0, 7.4 | Kein offizielles Update. PHP mit den Quellcode-Fixes bauen oder auf eine unterstützte Version wechseln |
| 7.3 und älter | Kein Fix vom PHP-Team. Auf eine unterstützte Version wechseln |
Ubuntu hat bereits korrigierte Pakete veröffentlicht. Bei anderen Linux-Distributionen sehen Sie im Security Advisory Ihres Anbieters nach.
Wie wir das für unsere Kunden gelöst haben
Das PHP-Team hat die Fixes um 14:00 UTC veröffentlicht. Unsere Techniker haben etwa eine Stunde später angefangen. Zwei Stunden danach, gegen 17:00 UTC, waren alle Server abgesichert, die wir betreuen: 88 Projekte in unserem Support.
Auf jedem Server haben wir zuerst den verwundbaren Mechanismus abgeschaltet und dann das korrigierte PHP installiert. Hosting-Panels wie aaPanel hatten am Tag des Releases kein aktualisiertes PHP, also haben wir PHP mit den Fixes aus dem Quellcode gebaut. Genauso sind wir bei Projekten auf PHP 7.4, 8.0 und 8.1 vorgegangen, die das PHP-Team nicht mehr aktualisiert. Nach dem Update haben wir die Server-Logs nach Spuren durchgesehen, dass jemand die Lücke ausgenutzt hat. Wir haben keine gefunden.
Unser automatisches Monitoring läuft rund um die Uhr, und unsere Techniker reagieren, sobald es einen Vorfall meldet.
Wie wir dabei vorgegangen sind, Schritt für Schritt: wie wir 88 PHP-Projekte in drei Stunden abgesichert haben.
Unsicher, ob Ihre Website geschützt ist?
Wir prüfen Ihre PHP-Version und aktualisieren sie innerhalb eines Arbeitstags. Läuft Ihre Website auf PHP 8.1 oder älter, sagen wir Ihnen, welcher Weg in Ihrem Fall schneller und günstiger ist: ein gepatchter Build oder ein Upgrade.
Wenn Sie danach laufende Betreuung möchten, finden Sie hier Website-Support und Server-Support. Für WordPress- und WooCommerce-Shops gibt es eine eigene Seite. Wenn Sie vermuten, dass vor dem Update jemand eingedrungen ist, oder wissen wollen, was sonst noch offen ist, gibt ein Penetrationstest die Antwort.
FAQ
Muss ich aktualisieren, wenn meine Website auf WordPress läuft?
Ja. WordPress läuft auf PHP, und die Lücke steckt in PHP selbst. Ein Update von WordPress und den Plugins behebt sie nicht. Ihr Server braucht die korrigierte PHP-Version.
Aktualisiert mein Hoster PHP automatisch?
Manche Anbieter tun das, manche warten, und auf vielen VPS und dedizierten Servern aktualisiert niemand PHP, solange Sie nicht danach fragen. Lassen Sie sich von Ihrem Anbieter schriftlich mit der genauen Version bestätigen, dass das Update eingespielt ist.
Geht meine Website nach dem Update kaputt?
Ein Update innerhalb desselben Zweigs, etwa von 8.3.x auf 8.3.36, enthält nur Sicherheits- und Bugfixes und wirkt sich selten auf eine Website aus. Ein Wechsel von 7.4 oder 8.1 auf einen neueren Zweig kann alte Plugins oder alten Code brechen, deshalb muss so ein Umstieg vorher getestet werden.
Reicht es, session.upload_progress abzuschalten?
Nein. Damit schließen Sie einen Teil eines Angriffswegs. Laut PHP-Team behebt nur das Update das Problem.
Quellen
- Ankündigung des PHP-Teams: https://www.php.net/archive/2026.php
- Security Advisories: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w und https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
- Berichte zu Angriffsversuchen und Exploit-Code: https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote