Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Updates veröffentlicht: Zwei kritische Schwachstellen im Kern der Programmiersprache, zusammen „PHP2Shell“ genannt, erlauben es Angreifern, aus der Ferne eigenen Code auf dem Server auszuführen. Ein Passwort brauchen sie dafür nicht. Weil der Fehler in PHP selbst steckt und nicht in einer Anwendung, ist auch eine sauber programmierte Website betroffen.
Wer PHP einsetzt – etwa für WordPress, Joomla, Drupal, Magento oder Shopware, aber auch für Weboberflächen von NAS-Systemen und anderen Geräten –, sollte heute prüfen, welche PHP-Version läuft. Es gibt bereits Berichte über Ausnutzungsversuche.
Was ist PHP2Shell?
PHP2Shell ist der Spitzname für zwei Sicherheitslücken mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Das PHP-Team bewertet beide mit 9,2 von 10 Punkten (CVSS 4.0), also als kritisch.
- CVE-2026-109618: Wenn PHP während einer Anfrage ohne Arbeitsspeicher dasteht, kann der Abbruch interne Daten halb initialisiert zurücklassen. Beim Aufräumen behandelt PHP diese dann als gültig.
- CVE-2026-109619: Interne Daten einer Anfrage überleben, obwohl ihr Speicher schon freigegeben wurde. Eine spätere Anfrage im selben Prozess kann diesen veralteten Zustand nutzen.
Das Ergebnis ist in beiden Fällen Remote Code Execution: Der Angreifer führt Befehle mit den Rechten des Webserver-Benutzers aus. Damit lassen sich Kundendaten abgreifen, Websites manipulieren, Schadsoftware nachladen oder weitere Systeme im Netzwerk angreifen.
Wer ist betroffen?
Betroffen ist jede PHP-Installation, die Webanfragen beantwortet – unabhängig davon, ob PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed zum Einsatz kommt. Das größte Risiko besteht laut PHP-Team bei Apache mit mod_php. Laut den Berichten reicht dort unter Umständen eine einzige Anfrage ohne Anmeldung.
Ein Update von WordPress, Plugins oder dem Shop schließt die Lücke nicht. Sie liegt eine Ebene tiefer, in PHP auf dem Server.
Welche PHP-Version ist sicher?
| PHP-Zweig | Verwundbar | Gepatcht ab |
|---|---|---|
| 8.5 | vor 8.5.12 | 8.5.12 |
| 8.4 | vor 8.4.27 | 8.4.27 |
| 8.3 | vor 8.3.36 | 8.3.36 |
| 8.2 | vor 8.2.35 | 8.2.35 |
| 8.1 und älter | alle | kein reguläres Update |
Für PHP 8.1 und älter gibt es keinen offiziellen Patch im Regelbetrieb. Das PHP-Team hat zwar Quelltext-Backports für 7.4, 8.0 und 8.1 bereitgestellt, diese richten sich aber an Anwender, die PHP selbst bauen. Alle anderen brauchen einen Hoster oder Distributionsanbieter, der den Fix zurückportiert, oder den Wechsel auf eine unterstützte Version.
Wichtig: Distributionen liefern Fixes oft als Backport, ohne die Versionsnummer anzuheben. Im Zweifel hilft der Sicherheitshinweis bzw. das Changelog des Paketanbieters.
Vorgehen: Website bei einem Hoster
- Prüfen, ob der Hoster die PHP-Version automatisch aktualisiert hat (Hoster-Hinweise, Admin-Bereich oder die PHP-Version der Website).
- Update anstoßen: Falls nicht, die Aktualisierung im Admin-Bereich selbst auslösen, sofern der Hoster das anbietet.
- Nachfragen: Ist das nicht möglich und die Version noch nicht aktualisiert, beim Hoster anfragen, bis wann gepatcht wird.
Vorgehen: Website selbst gehostet
- PHP-Version aktualisieren auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 (bzw. das entsprechende Distributionspaket).
- Ubuntu: Paketquelle prüfen. Das bekannte PHP-Repository von Ondřej Surý (
ppa:ondrej/php) zieht von Launchpad aufpackages.sury.orgum. Wer die Warnung zum geänderten „Label“ nur wegklickt, bekommt künftig keine Updates mehr. Die Paketquelle also auf den neuen Server umstellen, dannapt updateundapt upgrade. - Dienste neu starten (PHP-FPM bzw. Apache), denn laufende Prozesse nutzen sonst weiter den alten Code.
- Version kontrollieren – mit
php -vund für den Webserver-Betrieb über die tatsächlich ausgelieferte PHP-Version.
Empfehlung bis zum Update
Solange ein System nicht gepatcht werden kann, ist die sicherste Option: Website offline nehmen, um Kundendaten und Server zu schützen. Diese Empfehlung teilen auch Behörden wie die amerikanische CISA und das britische NCSC für Systeme, die nicht sofort aktualisiert werden können oder auf PHP 8.1 und älter laufen.
Als reine Übergangslösung nennt das PHP-Team Einstellungen, die den Missbrauch erschweren: etwa session.upload_progress.enabled=0 (danach alle PHP-Prozesse neu starten) und eine Begrenzung der Anfragegröße. Das ist ausdrücklich keine vollständige Abhilfe, sondern bestenfalls eine Krücke.
Wer hinter Cloudflare liegt, profitiert zusätzlich von bereitgestellten WAF-Regeln für die bekannten Angriffswege. Auch sie ersetzen das Update nicht.
Nicht vergessen: Geräte und vergessene Systeme
PHP steckt nicht nur in Websites. Auch Geräte mit Weboberfläche – NAS-Systeme, Appliances, Verwaltungsportale – nutzen häufig PHP. Hier hängt der Fix am Hersteller: Firmware-Updates prüfen, und bis dahin den Zugriff aus dem Internet sperren. Dasselbe gilt für alte, ungepflegte Anwendungen auf Servern, die kaum jemand mehr im Blick hat.
Fazit
PHP2Shell gehört zu den schwersten PHP-Lücken der letzten Jahre. Das Update ist der einzige vollständige Schutz, und es ist verfügbar. Prüfen Sie heute, welche PHP-Version Ihre Websites, Shops und Geräte nutzen, und nehmen Sie ungepatchte Systeme vom Netz, bis sie aktualisiert sind.
Wir von HK Trust Solutions prüfen für Sie, welche Systeme betroffen sind, koordinieren Updates mit Ihrem Hoster oder spielen sie auf Ihren Servern ein. Melden Sie sich: +49 7721 402 414 0 oder über hk-ts.de.
Quellen:
- PHP2Shell: Critical PHP vulnerabilities patched, update now! – Help Net Security
- Critical Vulnerabilities in PHP Require Immediate Patching – CISA
- PHP2Shell: PHP Remote Code Execution Exploited – watchTowr
- php2shell: Kritische Sicherheitslücken erlauben Codeeinschleusung in PHP – heise online
- Ubuntu: apt error … the PPA is moving to packages.sury.org – Nextcloud Forum
- PHP-Sicherheitslücke „PHP2Shell“: Ist meine Website betroffen? – hueske.digital