php2shell: Kritische PHP-Lücken CVE-2026-109618/109619, Notfall-Patch am 21.10. und Sofortmaßnahme

Von CMS ADMINS Redaktion · Aktualisiert am 21. Oktober 2026

Veröffentlicht: 21.10.2026 · Letzte Aktualisierung: 21.10.2026, 10:12 Uhr

Update-Verlauf: Was sich seit dem Leak geändert hat

Hier finden Sie alle Updates zu php2shell in zeitlicher Reihenfolge, das neueste steht oben. Stand jetzt (21.10.2026, 10:09 Uhr) sind die Patches noch nicht erschienen; das PHP-Team hat sie für heute, 21. Oktober, 16:00 Uhr deutscher Zeit (14:00 UTC) angekündigt.

Es ist das Szenario, das Sicherheitsverantwortliche am wenigsten mögen: Eine kritische Schwachstelle wird bekannt, bevor der Patch verfügbar ist. Genau das ist am 20. Oktober 2026 mit zwei Lücken im PHP-Kern passiert. Unter dem Namen „php2shell“ kursieren seitdem Screenshots und Berichte über zwei Remote-Code-Execution-Schwachstellen, die das PHP-Sicherheitsteam offiziell als kritisch (CVSS v4.0: 9.2) einstuft. Die Notfall-Patches erscheinen heute, am 21. Oktober um 14:00 UTC (16:00 Uhr deutscher Zeit).

Dieser Beitrag fasst zusammen, was über CVE-2026-109618 und CVE-2026-109619 bekannt ist, warum die Lücken gerade für WordPress-Betreiber relevant sind und welche Schritte Sie heute konkret gehen sollten. Wir aktualisieren den Artikel, sobald das offizielle Advisory vorliegt.

Bin ich betroffen? PHP-Versionen und Patch-Stand im Überblick

Wahrscheinlich ja, wenn auf Ihrem Server PHP läuft und die Website aus dem Internet erreichbar ist: Das PHP-Team ruft ausdrücklich alle PHP-Nutzer auf, sich auf das Update vorzubereiten. Die offizielle Liste der betroffenen Versionen veröffentlicht das PHP-Team erst mit dem Release; CERT-EU geht davon aus, dass alle PHP-Versionen ab PHP 5 betroffen sein könnten.

Die Tabelle zeigt, welche PHP-Zweige laut php.net noch Sicherheitsupdates erhalten und welche Version vor dem Notfall-Release die aktuelle war. Haben Sie eine dieser Versionen oder eine ältere installiert, brauchen Sie das Update von heute.

Was zu Betriebsart und Konfiguration bekannt ist: Welche Betriebsarten (SAPIs, also PHP-FPM, Apache-Modul, CGI oder Kommandozeile) und welche Einstellungen betroffen sind, hat das PHP-Team noch nicht veröffentlicht. Laut CERT-EU deutet die Bewertung CVSS 9.2 auf eine Ausnutzung ohne Anmeldung aus der Ferne hin. Ein Sicherheitsforscher verortet die Fehler im Upload-Fortschritts-Handler der PHP-Sessions (siehe Update-Verlauf); das ist unbestätigt. Diese Funktion ist in PHP standardmäßig eingeschaltet (session.upload_progress.enabled = 1).

Wichtig bei Linux-Distributionen: Debian, Ubuntu, Red Hat und andere liefern PHP oft mit eigenen Paketversionen aus. Ob Ihr System den Fix hat, erkennen Sie dann am Sicherheitshinweis der Distribution, nicht an der php.net-Versionsnummer. Den aktuellen Stand finden Sie im Abschnitt Status bei Distributionen und Hostern.

Was ist passiert? Die Chronologie des Leaks

Am 20. Oktober gegen 15:20 UTC tauchte auf Hacker News ein Beitrag auf, der zwei kritische PHP-Schwachstellen ankündigte, inklusive Details, die eigentlich bis Donnerstag unter Embargo standen. Der Beitrag wurde zwar schnell entfernt, doch Screenshots verbreiteten sich bereits über soziale Netzwerke. Darunter: das Banner eines Exploit-Tools namens „PHP2Shell“, das einer Gruppierung namens Calif.IO zugeschrieben wird und nach eigener Angabe gegen jede PHP-Version ab 5.4.0 funktionieren soll. Wenige Stunden später bestätigten Sicherheitsforscher von watchTowr die Echtheit des Leaks. Auch ein kurzes Video, das eine angebliche Ausnutzung der Lücke zeigte, war zeitweise online.

Das PHP-Sicherheitsteam reagierte noch am selben Abend (19:33 UTC) mit einer offiziellen Vorab-Mitteilung: Ein Security-Release, das zwei kritische Schwachstellen behebt, erscheint am Mittwoch, 21. Oktober um 14:00 UTC, einen Tag früher als ursprünglich geplant. Das Team behält sich zudem vor, die Patches noch früher zu veröffentlichen, falls weitere Details öffentlich werden oder aktive Angriffe beobachtet werden. Ebenfalls noch am 20. Oktober veröffentlichte CERT-EU, das Cyber-Notfallteam der EU-Institutionen, ein eigenes Security-Advisory (2026-018) zu den beiden Lücken.

Was wir über CVE-2026-109618 und CVE-2026-109619 wissen und was nicht

Bei vorzeitig geleakten Schwachstellen ist die Trennung zwischen bestätigten Fakten und Spekulation besonders wichtig. Der aktuelle Stand:

Bestätigt ist:

• Beide Schwachstellen stecken im PHP-Kern selbst und nicht in einem Plugin, Theme oder CMS. Das PHP-Sicherheitsteam stuft beide als kritisch ein (CVSS v4.0: 9.2).
• Öffentliche Berichte beschreiben sie als Remote Code Execution: Ein Angreifer könnte den Server dazu bringen, beliebige Befehle auszuführen. CERT-EU spricht von potenziell unauthentifizierter RCE, also ohne jegliche Zugangsdaten ausnutzbar.
• Die Patches erscheinen heute um 16:00 Uhr deutscher Zeit, zusammen mit der offiziellen Liste betroffener und gefixter Versionen.

Noch offen ist:

• Die technische Ursache: Welcher Teil von PHP betroffen ist, ob die Lücke über einen simplen Web-Request erreichbar ist oder eine bestimmte Konfiguration voraussetzt, ist nicht veröffentlicht.
• Die exakten betroffenen Versionen: Berichte von Sicherheitsforschern nennen die PHP-Versionen 5 bis 8. Offizielle Fixes werden allerdings nur für die aktuell unterstützten PHP-8-Zweige erwartet.
• Ein öffentlicher Exploit: Proof-of-Concept-Code ist bislang nicht bestätigt im Umlauf. Erfahrungsgemäß folgt er jedoch sehr schnell, sobald die Patches veröffentlicht sind, denn Angreifer rekonstruieren die Lücke dann aus den Code-Änderungen.

Der Name „php2shell“ stammt aus der Security-Community und ist Programm: Eine Anfrage an Ihre Website, eine Shell auf Ihrem Server.

Warum das jede WordPress-Website betrifft

PHP ist die Sprache, in der WordPress, WooCommerce, Drupal, Joomla und Magento geschrieben sind. Sie läuft auf praktisch jedem Shared-Hosting-Paket, in Control-Panels wie Plesk und cPanel und in unzähligen Anwendungen, die gar nicht damit werben, dass unter der Haube PHP arbeitet.

Das unterscheidet diese Lage von einer typischen Plugin-Schwachstelle: Wenn ein WordPress-Plugin verwundbar ist, betrifft das die Websites, die genau dieses Plugin einsetzen. Wenn PHP selbst verwundbar ist, ist potenziell jede PHP-Website betroffen, unabhängig davon, wie gut WordPress, Themes und Plugins gepflegt sind. Ein vollständig aktuelles WordPress schützt nicht vor einer Lücke in der Sprach-Laufzeitumgebung darunter.

Wichtig zu verstehen: Die Lücke lässt sich nur auf Infrastruktur-Ebene schließen: durch ein PHP-Update auf dem Server. Kein Plugin, kein Theme-Fix und keine Anwendungs-Firewall im CMS kann das Problem beheben, denn der Angriff trifft PHP selbst, bevor Ihr WordPress-Code überhaupt ausgeführt wird. Die E-Commerce-Sicherheitsfirma Sansec, die vor allem Magento-, Shopware- und WooCommerce-Shops im Blick hat, bringt es auf den Punkt: Sie erwartet Massen-Angriffe innerhalb von 15 Minuten nach Veröffentlichung des Patches. Sie rät dazu, den eigenen Hosting-Anbieter schon heute in Bereitschaft zu versetzen.

Dazu kommt ein strukturelles Problem: Viele Websites laufen noch auf PHP-Versionen, die ihr Lebensende längst erreicht haben. PHP 7.4 etwa wird seit Ende 2022 nicht mehr mit Sicherheitsupdates versorgt. Für solche Systeme wird es voraussichtlich keinen offiziellen Patch geben. Hier sind die Hosting-Anbieter und Linux-Distributionen gefragt, die teils eigene Backports pflegen.

Was Sie jetzt tun sollten: Checkliste für heute

Schalten Sie bis zum Patch die PHP-Funktion Session Upload Progress ab, prüfen Sie die Wirkung über den Webserver und spielen Sie das PHP-Update ein, sobald es erscheint. Die folgenden Schritte zeigen, wie das geht und woran Sie erkennen, dass es gewirkt hat.

• Bis 16:00 Uhr: PHP-Installationen erfassen, Sofortmaßnahme setzen, Wirkung im Webserver prüfen, Hoster bzw. Patch-Fenster organisieren.
• Ab 16:00 Uhr: Update einspielen, PHP-FPM bzw. Webserver neu starten, Version im Webserver prüfen.
• Danach: Logs und Prozesse auf Auffälligkeiten beobachten, Systeme ohne Fix abschirmen oder upgraden.

1. Sofortmaßnahme: Session Upload Progress abschalten

Setzen Sie session.upload_progress.enabled auf Off; nach den bisherigen Angaben schließt das den beschriebenen Angriffsweg, ersetzt aber nicht das Update. Diese Übergangslösung stammt nicht vom PHP-Team, sondern beruht auf den bisher unbestätigten Angaben zur Fehlerursache.

Laut PHP-Handbuch ist die Einstellung vom Typ INI_PERDIR. Sie lässt sich also nicht per ini_set() im Code ändern, sondern nur in der Konfiguration:

• php.ini bzw. eine Datei im conf.d-Verzeichnis der jeweiligen PHP-Version: session.upload_progress.enabled = Off
• PHP-FPM-Pool (z. B. www.conf): php_admin_flag[session.upload_progress.enabled] = off. Ein Pool-Wert überschreibt die php.ini, prüfen Sie deshalb auch bestehende Pool-Einträge.
• Shared Hosting mit PHP-FPM/FastCGI: eine .user.ini im Web-Root mit session.upload_progress.enabled = Off. PHP liest diese Datei nur in Abständen neu ein (Standard: 5 Minuten).
• Apache mit mod_php: in der .htaccess php_flag session.upload_progress.enabled off

Starten Sie danach PHP-FPM bzw. den Webserver neu, auf Debian und Ubuntu zum Beispiel mit systemctl restart php8.3-fpm (Versionsnummer anpassen). Mehrere installierte PHP-Versionen brauchen die Einstellung jeweils einzeln.

2. Wirksamkeit prüfen: nur über den Webserver verlässlich

Ob die Abschaltung wirkt, sehen Sie zuverlässig nur in einer Anfrage über den Webserver. php -i zeigt die Konfiguration der Kommandozeile, und auch php-fpm -i liest nur die php.ini, nicht die Einstellungen der einzelnen Pools (php_admin_value, php_admin_flag).

So prüfen Sie es: Legen Sie im Web-Root kurzzeitig eine Datei mit zufälligem Namen an, etwa check-8f3k2.php, mit diesem Inhalt:

<?php
echo PHP_VERSION, ' | upload_progress: ', var_export(ini_get('session.upload_progress.enabled'), true);

Rufen Sie die Datei im Browser auf. Zeigt sie bei upload_progress den Wert '1', ist die Funktion noch aktiv; '0' oder '' bedeutet abgeschaltet. Alternativ funktioniert eine Datei mit phpinfo();, die allerdings deutlich mehr über Ihren Server verrät. Löschen Sie die Prüfdatei sofort nach dem Test.

3. Patch einspielen und Version kontrollieren

Spielen Sie das Update ein, sobald PHP es veröffentlicht oder Ihre Distribution bzw. Ihr Hoster es bereitstellt, und starten Sie PHP-FPM bzw. den Webserver anschließend neu. Laufende PHP-Prozesse nutzen sonst weiter die alte, verwundbare Version.

# Debian / Ubuntu
apt update && apt list --upgradable 2>/dev/null | grep -i php
apt install --only-upgrade 'php*'

# RHEL / AlmaLinux / Rocky
dnf check-update 'php*'
dnf upgrade 'php*'

# installierte Paketstände anzeigen
dpkg -l | grep -i php      # Debian / Ubuntu
rpm -qa | grep -i php      # RHEL-Familie

Kontrollieren Sie danach die Version wieder über den Webserver mit der Prüfdatei aus Schritt 2 (und löschen Sie sie danach). Die Fix-Versionen nennen wir hier, sobald sie offiziell sind. Die Sofortmaßnahme können Sie nach dem Update zurücknehmen, sie schadet aber auch nicht, wenn Sie keine Upload-Fortschrittsanzeige nutzen.

4. Vorbereitung und Notfallplan

Die Patches sind zum Zeitpunkt der Veröffentlichung dieses Artikels noch nicht erschienen. Das Ziel bis dahin: vorbereitet sein, um in der Minute der Veröffentlichung handeln zu können.

1. Inventarisieren Sie jede PHP-Installation. Beginnen Sie bei den Webservern, und denken Sie dann an die weniger offensichtlichen Orte: Control-Panels wie Plesk und cPanel, Appliances von Drittherstellern, Windows-Software mit gebündeltem php.exe, und natürlich alles, was WordPress, Drupal, Joomla oder Magento ausführt. Ihre aktive PHP-Version sehen Sie in WordPress unter Werkzeuge, Website-Zustand, Reiter „Bericht“, Abschnitt „Server“.
2. Planen Sie Ihr Patch-Fenster für heute 16:00 Uhr. Aktualisieren Sie zuerst die Systeme, die direkt aus dem Internet erreichbar sind. Achten Sie auf die offiziellen Versionsnummern im PHP-Announcement und prüfen Sie, ob Ihre Linux-Distribution oder Ihr Hosting-Anbieter Backport-Pakete bereitstellt.
3. Identifizieren Sie PHP-Versionen ohne Support. Läuft bei Ihnen noch PHP 5, 7 oder 8.0/8.1, bekommen Sie möglicherweise keinen offiziellen Fix. Die Optionen: auf einen unterstützten PHP-8-Zweig aktualisieren, das System vom Netz nehmen oder es übergangsweise hinter VPN oder einer Web Application Firewall (WAF) abschirmen.
4. Behalten Sie im Blick, was PHP startet. Richten Sie Alarme für PHP-Prozesse ein, die Shells, Interpreter oder Download-Tools starten. Auf Linux-Servern ohne Monitoring ist das erwähnte process-watcher im Beobachtungsmodus ein schneller Einstieg.
5. Im Verdachtsfall: isolieren und Beweise sichern. Trennen Sie den Server vom Netz und sichern Sie Webserver- und PHP-Logs. Suchen Sie nach Webshells und neuen Dateien im Web-Root sowie nach neu angelegten Cronjobs und Benutzerkonten.

Status bei Distributionen und Hostern

Stand 21.10.2026, 10:09 Uhr gibt es noch keine offiziellen Pakete oder Sicherheitshinweise der großen Linux-Distributionen zu CVE-2026-109618 und CVE-2026-109619. Auch die NIST-Schwachstellendatenbank NVD und die Security-Advisories des PHP-Projekts auf GitHub führen die beiden CVEs noch nicht.

Zu anderen Hosting-Anbietern liegen uns keine überprüfbaren offiziellen Angaben vor. Fragen Sie Ihren Anbieter direkt, ob er die Sofortmaßnahme umgesetzt hat und wann er die Patches einspielt. Wir ergänzen diese Tabelle, sobald die Distributionen Pakete veröffentlichen.

Wie Angriffe aussehen werden: PHP startet Prozesse, die es nicht starten sollte

Auch ohne technische Details lässt sich gut vorhersagen, wie eine Ausnutzung in der Praxis sichtbar wird, denn fast jeder PHP-Angriff folgt demselben Muster: Ein PHP-Arbeitsprozess (etwa php-fpm, php-cgi, httpd oder apache2) startet plötzlich Programme, die dort nichts zu suchen haben:

• Shells wie sh, bash oder unter Windows cmd.exe und powershell.exe
• Interpreter wie python oder perl
• Download- und Netzwerk-Tools wie curl, wget oder nc
• Aufklärungs-Befehle wie whoami, id oder uname -a, direkt vom Webserver-Prozess ausgeführt

Verdächtig sind außerdem Befehlszeilen mit typischen Reverse-Shell-Mustern wie /dev/tcp/, fsockopen oder mkfifo. Der Sicherheitsforscher Florian Roth hat mit process-watcher ein kostenloses Linux-Tool veröffentlicht, das genau solche verdächtigen Kindprozesse von PHP überwacht. Das ist eine schnelle Möglichkeit, auf Servern ohne Endpoint-Schutz noch heute Sichtbarkeit zu bekommen.

Gerade Linux-Webserver im Shared Hosting sind hier der wunde Punkt: Sie sind aus dem Internet erreichbar, werden aber selten so eng überwacht wie Firmen-Arbeitsplätze. Eine PHP-Lücke kann dort still ausgenutzt werden und lange unbemerkt bleiben.

Einordnung: Ruhe bewahren, aber heute handeln

Noch gibt es keine bestätigten aktiven Angriffe und keinen öffentlichen Exploit-Code. Panik ist also nicht angebracht, Aufschub allerdings auch nicht. Die Erfahrung mit vergleichbaren Fällen zeigt: Sobald die Patches veröffentlicht sind, vergleichen Angreifer die Code-Änderungen mit der Vorgängerversion und rekonstruieren daraus funktionierende Exploits. Im Fall php2shell existiert offenbar bereits ein fertiges Angriffs-Tool, weshalb Sansec mit Massen-Scans binnen Minuten rechnet. Wer heute patcht, ist auf der sicheren Seite. Wer es auf nächste Woche verschiebt, spielt mit deutlich schlechteren Karten.

CERT-EU gibt für den Fall, dass sofortiges Patchen nicht möglich ist, eine klare Empfehlung: Internet-erreichbare PHP-Anwendungen übergangsweise vom öffentlichen Netz isolieren, bis der Fix eingespielt ist. Für geschäftskritische Systeme, die nicht sofort aktualisiert werden können, ist das die unbequeme, aber richtige Konsequenz.

Dass das PHP-Team den Release-Termin nach dem Leak kurzfristig vorgezogen hat, ist dabei die richtige Entscheidung: Jede Stunde zwischen Leak und Patch arbeitet für die Angreifer.

Häufige Fragen

Ich habe WordPress, Plugins und Theme aktuell: Bin ich trotzdem betroffen?

Ja, möglicherweise. Die Lücken stecken in PHP selbst, nicht in WordPress. Entscheidend ist, welche PHP-Version auf Ihrem Server läuft. Das Update muss auf Server-Ebene eingespielt werden, nicht im WordPress-Backend.

Woher weiß ich, welche PHP-Version meine Website nutzt?

In WordPress unter Werkzeuge, Website-Zustand, Reiter „Bericht“, Abschnitt „Server“. Alternativ zeigt Ihr Hosting-Control-Panel die PHP-Version an. Bei Unsicherheit fragen Sie Ihren Hosting-Anbieter, und fragen Sie gleich mit, wann er die Patches vom 21. Oktober einspielt.

Mein Hoster verwaltet PHP: Muss ich selbst etwas tun?

Beim klassischen Shared Hosting spielt der Anbieter die PHP-Updates ein. Verlassen Sie sich aber nicht blind darauf: Fragen Sie nach, ob und wann die Security-Releases vom 21. Oktober übernommen werden. Bei eigenen Servern (VPS, Dedicated) sind Sie selbst verantwortlich.

Was ist mit alten PHP-Versionen wie 7.4?

PHP-Versionen vor 8.2 werden offiziell nicht mehr unterstützt und erhalten voraussichtlich keinen Patch vom PHP-Projekt. Manche Linux-Distributionen und Hosting-Anbieter pflegen eigene Backports. Mittelfristig führt an einem Upgrade auf einen unterstützten PHP-8-Zweig kein Weg vorbei. Es macht Ihre Website nebenbei auch schneller.

Hilft es, session.upload_progress abzuschalten?

Als Übergang wahrscheinlich ja, als Lösung nein. Nach den bisher unbestätigten Angaben eines Forschers liegen die Lücken in genau dieser Funktion, das PHP-Team hat die Ursache aber noch nicht bestätigt. Setzen Sie die Einstellung als Sofortmaßnahme, prüfen Sie sie über den Webserver und spielen Sie trotzdem das Update ein.

Welche PHP-Version enthält den Fix?

Das steht noch nicht fest. Das PHP-Team nennt die gefixten Versionen erst mit dem Release am 21. Oktober um 16:00 Uhr deutscher Zeit. Die bis dahin aktuellen Versionen 8.5.11, 8.4.26, 8.3.35 und 8.2.34 enthalten den Fix nicht; wir tragen die neuen Versionsnummern hier ein, sobald sie veröffentlicht sind.

Quellen: PHP: Upcoming Critical PHP Security Release (Announcement) · CERT-EU: Security Advisory 2026-018 · Sansec: Critical PHP RCE · Florian Roth: process-watcher (GitHub) · php.net: News-Archiv 2026 · php.net: Supported Versions · php.net: Unsupported Branches · PHP-Handbuch: Session-Konfiguration · php-src Security Advisories (GitHub) · NIST NVD