Kritische Lücke „php2shell“: Unsere PHP-Updates werden ausgerollt

Das PHP-Projekt hat am Mittwoch, dem 21. Oktober 2026, um 14:00 Uhr UTC Sicherheitsversionen veröffentlicht, die zwei kritische Lücken zur Remote-Codeausführung schließen: CVE-2026-109618 und CVE-2026-109619, beide mit 9,2 von 10 bewertet (CVSS v4.0). Die Forscher von watchTowr haben das Duo „php2shell“ getauft.

Unsere Teams rollen die korrigierten Versionen gerade auf den von uns betreuten Servern aus. Dieser Artikel erklärt, worum es bei diesen Lücken geht, warum sie so ernst genommen werden und was wir unternehmen.

Zwei Lücken im Kern von PHP

Die Lücken betreffen weder WordPress noch PrestaShop noch eine bestimmte Erweiterung: Sie stecken in der PHP-Engine selbst, in der Art, wie sie jede Anfrage vorbereitet und anschließend aufräumt. Sie lassen sich daher unabhängig von der Website oder dem installierten CMS auslösen.

CVE-2026-109618: Speicherbeschädigung nach Speichermangel

Überschreitet eine Anfrage den erlaubten Speicher, bricht PHP sie ab. Fällt dieser Abbruch auf einen ungünstigen Moment, sind manche internen Daten der Anfrage nur halb initialisiert. Das Aufräumen am Ende der Anfrage behandelt sie trotzdem als gültige Daten, was den Speicher beschädigt und zur Ausführung von Code führen kann, den der Angreifer wählt.

Laut dem Sicherheitshinweis des PHP-Projekts ist das Risiko mit mod_php (PHP direkt in Apache geladen) am höchsten: Mit einem vorgeführten Exploit kann eine nicht authentifizierte Anfrage den Angriff auslösen, noch bevor der Code der Website läuft.

CVE-2026-109619: wiederverwendeter veralteter globaler Zustand

Die zweite Lücke betrifft einen internen Zustand jeder Anfrage, der die Freigabe des Speichers, in dem er lag, überdauern kann. Die nächste Anfrage, die derselbe PHP-Prozess bearbeitet (zum Beispiel ein PHP-FPM-„Worker“), kann diesen veralteten Zustand dann wiederverwenden, bevor er zurückgesetzt wird. Die von PHP veröffentlichten Übergangsmaßnahmen zeigen, dass sie mit der Fortschrittsanzeige für Datei-Uploads (session.upload_progress) und in PHP 8.5 mit den Backtraces fataler Fehler zusammenhängt.

Warum das ernst ist

• Keine Authentifizierung nötig: Eine einfache HTTP-Anfrage an eine PHP-Website genügt, ohne Konto und ohne bestimmtes Formular.
• Alle PHP-Websites sind betroffen: WordPress, PrestaShop, Joomla, Drupal, Laravel, Magento … Die Schätzungen reichen von 1,3 bis über 1,9 Millionen im Internet erreichbaren Servern.
• Details sind vor der Veröffentlichung durchgesickert, weshalb das PHP-Projekt den Fix am Vortag angekündigt hat. Exploit-Code ist bereits im Umlauf, ungeprüft (und teils präpariert: führen Sie ihn nicht aus).
• Erste Angriffe werden von Cloudflare erwähnt, bislang aber weder vom CERT-FR noch vom CISA-Katalog ausgenutzter Schwachstellen bestätigt.
• Der Präzedenzfall spricht für sich: 2024 wurde CVE-2024-4577 weniger als 24 Stunden nach der Veröffentlichung ausgenutzt.

Betroffene und korrigierte Versionen

Das CERT-EU hält es für möglich, dass alle Versionen seit PHP 5 betroffen sind. Einige Anbieter liefern zurückportierte Fixes für ältere Zweige, die einzige dauerhafte Lösung bleibt aber der Wechsel auf eine gepflegte Version.

Was wir bei HaiSoft tun

Wir haben die Ankündigung seit dem Vortag verfolgt und waren vorbereitet: Die Updates werden gerade auf unseren Servern ausgerollt.

• Shared Hosting: Die korrigierten Versionen werden für alle angebotenen PHP-Versionen installiert. Sie müssen nichts tun, der Vorgang verläuft für Ihre Websites transparent.
• Betreute dedizierte und virtuelle Server: Wir aktualisieren PHP auf jedem Server; dieser Eingriff ist in Ihrem Managed-Service-Vertrag enthalten. Die korrigierten Pakete aus dem Repository sury.org sind bereits verfügbar und werden installiert.
• Server mit Plesk oder den offiziellen Debian-Paketen: Plesk und Debian haben ihre korrigierten Pakete noch nicht veröffentlicht. Wir verfolgen ihre Veröffentlichungen und spielen die Updates ein, sobald sie erscheinen.
• Websites, die noch mit PHP 8.1 oder älter laufen: Diese Versionen erhalten keinen Fix. Wir kontaktieren die betroffenen Kunden, um eine Migration auf eine gepflegte Version zu planen.

Sie verwalten Ihren Server selbst?

1. Erfassen Sie die installierten PHP-Versionen: php -v, die Debian-Pakete php8.* oder plesk bin php_handler --list unter Plesk.
2. Aktualisieren Sie auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 (oder das korrigierte Paket Ihrer Distribution) und starten Sie alle PHP-FPM-Dienste neu, bei mod_php auch Apache.
3. Wenn das Update warten muss, setzen Sie die Übergangsmaßnahmen des PHP-Projekts um: Sie verringern das Risiko, beseitigen es aber nicht.
4. Isolieren Sie Anwendungen auf nicht mehr gepflegten Versionen (VPN, Filterung, Abschaltung), wie vom CERT-EU empfohlen, bis zu ihrer Migration.
5. Überwachen Sie jede Shell und jeden curl- oder wget-Aufruf, der von php-fpm, apache2 oder httpd gestartet wird: das typische Zeichen eines erfolgreichen Angriffs.

Die vom PHP-Projekt empfohlenen Übergangsmaßnahmen gehören in die php.ini oder in die Konfiguration des PHP-FPM-Pools (nicht in eine .user.ini und nicht per ini_set()), gefolgt von einem Neustart aller Worker:

; CVE-2026-109619
session.upload_progress.enabled = 0
; nur PHP 8.5
fatal_error_backtraces = 0
; CVE-2026-109618: Größe der Anfragen begrenzen
; (8M ohne Datei-Uploads, 32M mit)
post_max_size = 8M

Für CVE-2026-109618 rät das PHP-Projekt außerdem, memory_limit = -1 zu setzen, ohne dass die Anwendung den Wert ändern kann, und die Größe der Anfragen auf Ebene des Webservers oder Proxys zu begrenzen. Diese Einstellung hebt jede Speichergrenze pro Skript auf: Nutzen Sie sie nur, wenn ein sofortiges Update wirklich unmöglich ist.