Das Wichtigste in Kürze (Stand: 21. Oktober 2026, 18:00 Uhr)
- Zwei kritische Schwachstellen in PHP (CVE-2026-109618 und CVE-2026-109619, CVSS 9.2) erlauben Angreifern, ohne Anmeldung Schadcode auf Webservern auszuführen.
- Betroffen sind nahezu alle Kunden mit Managed VM, Managed Services oder Webhosting.
- Die empfohlenen Schutzmaßnahmen haben wir bereits auf unseren Managed Servern umgesetzt.
- Die Sicherheitsupdates von Ubuntu, Debian und Plesk spielen wir aktuell ein und prüfen automatisiert, wo sie noch fehlen.
- Wir nehmen Ihre Dienste dafür nicht vom Netz. Sie müssen als Managed-Kunde nichts tun.
Seit gestern macht eine PHP-Sicherheitslücke weltweit Schlagzeilen. In den Medien heißt sie bereits „PHP2Shell“, in Anlehnung an die Log4Shell-Lücke von 2021. Einige Betreiber haben ihre Websites vorsorglich komplett abgeschaltet. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat eine Cybersicherheitswarnung veröffentlicht und rät dazu, die Patches unverzüglich einzuspielen.
Genau daran arbeiten wir. In diesem Beitrag erfahren Sie, was hinter der Lücke steckt, was wir bereits für Sie getan haben und was Sie tun sollten, wenn Sie Ihren Server selbst verwalten.
Was ist passiert?
PHP ist die Programmiersprache hinter einem Großteil aller Websites, von WordPress über Shopware bis zu Laravel-Anwendungen. Das PHP-Sicherheitsteam hat am 20. Oktober 2026 ein kritisches Sicherheitsupdate angekündigt und es am 21. Oktober veröffentlicht. Es schließt zwei Schwachstellen:
- CVE-2026-109618: fehlerhafte Behandlung von Speicherengpässen bei der Verarbeitung von Anfragen
- CVE-2026-109619: fehlerhafte Verwaltung des internen Anfragezustands, wenn PHP-Prozesse wiederverwendet werden
Beide sind mit 9.2 von 10 Punkten (CVSS v4.0) als kritisch eingestuft. Ein Angreifer braucht weder Zugangsdaten noch eine Aktion des Nutzers. Eine präparierte HTTP-Anfrage reicht aus, um im schlimmsten Fall eigenen Code auf dem Server auszuführen. Nach bisherigen Berichten liegt der Fehler in der Verarbeitung von Formular-Uploads (multipart/form-data). Dieser Teil läuft in PHP selbst, also bevor WordPress, ein Sicherheits-Plugin oder Ihre Anwendung überhaupt eingreifen kann.
Betroffen sind nach aktuellem Kenntnisstand PHP-Versionen von 5.4 bis 8.x. Laut BSI gibt es bisher keine bestätigten Angriffe, aber unbestätigte Berichte über bereits existierende Exploits. Sicherheitsforscher rechnen damit, dass nach der Veröffentlichung der Patches sehr schnell automatisierte Massenangriffe einsetzen.
Was wir bereits für Sie getan haben
Unsere Technik ist seit dem Bekanntwerden der Lücke im Einsatz. Wir gehen in zwei Stufen vor: Zuerst machen wir die Angriffsfläche dicht, dann schließen wir die Lücke selbst.
Stufe 1: Sofortmaßnahmen sind umgesetzt
Die von Sicherheitsexperten empfohlenen Gegenmaßnahmen haben wir über unser zentrales Konfigurationsmanagement auf unseren Managed Servern ausgerollt:
- PHP-Funktion „Upload Progress“ deaktiviert: Die Funktion, über die die Lücke nach bisherigen Erkenntnissen ausgenutzt wird, ist in der PHP-Konfiguration abgeschaltet.
- Multipart-Anfragen im Webserver blockiert: Anfragen dieses Typs weist der Webserver ab, bevor sie PHP erreichen. Das gilt für Plesk-Server ebenso wie für reine Apache- und nginx-Server, jeweils für alle virtuellen Hosts.
Ein Unterschied zu manchem anderen Anbieter: Wir nehmen Ihre Websites und Anwendungen dafür nicht vom Netz. Ihre Dienste bleiben erreichbar.
Stufe 2: Patches werden eingespielt
Die Hersteller haben inzwischen korrigierte Versionen veröffentlicht. Wir spielen sie derzeit auf allen betroffenen Systemen ein. Parallel bauen wir automatisierte Prüfungen, die uns zeigen, auf welchen Servern ein Update noch fehlt. So stellen wir sicher, dass kein System durchrutscht.
| Plattform | Korrigierte Version |
|---|---|
| PHP (offizielle Releases) | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| Plesk für Linux | PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 (für PHP 7.4, 8.0 und 8.1 noch keine Fixes) |
| Debian 13 (Trixie) | 8.4.27-1~deb13u1 |
| Ubuntu 26.04 LTS | php8.5 8.5.4-0ubuntu1.5 |
| Ubuntu 24.04 LTS | php8.3 8.3.6-0ubuntu0.24.04.13 |
| Ubuntu 22.04 LTS | php8.1 8.1.2-1ubuntu2.28 |
Quellen: php.net, Debian Security Announce, Ubuntu USN-8948-1, Plesk Support.
Was bedeutet das für Sie?
Kunden mit Managed VM, Managed Services oder Webhosting
Sie müssen nichts unternehmen. Wir kümmern uns um Schutzmaßnahmen, Updates und Kontrolle.
Eine Einschränkung sollten Sie kennen: Solange die Multipart-Sperre aktiv ist, funktionieren Datei-Uploads über Ihre Website nicht. Das betrifft zum Beispiel das Hochladen von Bildern in der WordPress-Mediathek, Kontaktformulare mit Dateianhang oder Upload-Funktionen in Shops und Webanwendungen. Der Server antwortet in diesen Fällen mit einer Fehlermeldung (HTTP 403). Normale Seitenaufrufe und einfache Formulare ohne Dateianhang sind nicht betroffen. Die Sperre ist eine Übergangsmaßnahme, bis die Patches vollständig eingespielt sind.
Ist eine Upload-Funktion für Ihr Geschäft gerade unverzichtbar? Dann sprechen Sie uns an. Wir finden gemeinsam eine Lösung.
Kunden mit selbst verwalteten Servern
Betreiben Sie einen Root-Server, eine VM oder Hardware in der Colocation in eigener Verantwortung, sollten Sie jetzt handeln:
- Updates einspielen: Paketquellen aktualisieren und alle installierten PHP-Versionen auf den korrigierten Stand bringen. Debian und Ubuntu übernehmen Korrekturen oft in bestehende Versionen. Maßgeblich ist daher die Paketversion aus der Tabelle oben, nicht die PHP-Versionsnummer.
- Dienste neu starten: PHP-FPM, Apache sowie langlaufende PHP-Prozesse wie Queue-Worker oder Scheduler neu starten. Sonst läuft weiterhin der alte Code im Speicher. Container-Images müssen neu gebaut und ausgerollt werden.
- Alte Systeme prüfen: Für PHP 8.1 und älter gibt es vom PHP-Projekt selbst keine Korrekturen mehr. Wer solche Versionen ohne Distributions-Backport einsetzt, sollte zügig auf eine unterstützte Version umsteigen.
- Übergangsweise absichern: Lässt sich ein Update nicht sofort einspielen, helfen die oben beschriebenen Sofortmaßnahmen:
session.upload_progress.enabled = Offin der PHP-Konfiguration und das Blockieren von Multipart-Anfragen im Webserver. - Auf Spuren prüfen: Logs ab dem 20. Oktober auf auffällige Upload-Anfragen und abgestürzte PHP-Prozesse durchsehen. Webverzeichnisse auf neue oder veränderte Dateien prüfen, ebenso Cronjobs, SSH-Schlüssel und Admin-Konten.
Wichtig: Eine Web Application Firewall oder ein CDN vor Ihrer Website schützt nur, wenn Ihr Server nicht direkt über seine IP-Adresse erreichbar ist. Sicherheits-Plugins für WordPress greifen bei dieser Lücke nicht, weil der Fehler vor dem Start von WordPress auftritt.
Sie möchten das nicht selbst erledigen? Wir übernehmen Patching, Prüfung und Absicherung Ihres Servers gern für Sie, kurzfristig oder dauerhaft als Managed Service.
Wie geht es weiter?
Wir arbeiten weiter mit Hochdruck daran, alle betroffenen Systeme vollständig zu patchen. Diesen Beitrag aktualisieren wir, sobald es Neuigkeiten gibt, etwa wenn weitere Hersteller-Updates erscheinen oder alle Systeme abgeschlossen sind.
Sicherheitslücken lassen sich nicht immer verhindern. Entscheidend ist, wie schnell und überlegt man reagiert. Dafür sind wir da: mit eigener Technik in Hamburg, kurzen Wegen und Menschen, die Ihre Systeme kennen.
Lars Sommerfeldt
Geschäftsführer, NMMN