PHP2Shell: Updates sind da – was WordPress-Betreiber je nach Hoster, PHP-Version und Betriebssystem jetzt tun

Die kurze Fassung: Was Sie jetzt tun sollten

1. Shared Hosting (Webspace beim Hoster): Im Kundenbereich die PHP-Version ansehen. Der Hoster spielt das Update ein. Fragen Sie schriftlich nach, ob und wann das geschehen ist. Läuft Ihr Tarif auf PHP 8.1 oder älter: auf 8.3 oder 8.4 umstellen (nach Backup, mit Test).
2. Eigener Server (VPS, Root-Server, Managed Server ohne Rundum-Service): Paketquellen aktualisieren, PHP-Pakete einspielen, alle PHP-Prozesse neu starten, Version prüfen. Ablauf je Betriebssystem weiter unten.
3. Ubuntu 20.04 oder älter: Das Update gibt es nur über Ubuntu Pro (ESM). Ohne Pro: Server absichern oder vom Netz nehmen und zügig umziehen. Details im eigenen Abschnitt.
4. PHP 8.1 oder älter: Es gibt keinen offiziellen Fix. Prüfen Sie, ob Ihr Anbieter einen Backport liefert. Wenn nicht: umziehen, bis dahin Zugriff einschränken.
5. Danach: Auf Anzeichen einer Übernahme prüfen (neue PHP-Dateien, unbekannte Administratoren). Ein Update entfernt keine Hintertür, die schon installiert wurde.

Wie wir auf die heutige Lage kommen

Eine kurze Chronologie, damit Sie Gerüchte von Fakten trennen können (Uhrzeiten UTC, wo nicht anders angegeben; deutsche Sommerzeit ist UTC+2):

• 20.10., abends: Ein inzwischen gelöschter Forenbeitrag nennt zwei PHP-Lücken. Das Sicherheitsunternehmen watchTowr bestätigt, dass die Informationen echt sind. Das PHP-Sicherheitsteam kündigt um 19:33 UTC einen Notfall-Release für den 21.10. um 14:00 UTC an (Quelle: php.announce #509). Ursprünglich war die Offenlegung laut watchTowr für den 22.10. geplant.
• 21.10., Vormittag: Behörden und Hersteller warnen. Cloudflare rollt Notfall-Regeln für seine Firewall aus. Laut Berichten melden Hoster Patchstack erste Angriffsversuche. Das PHP-Team hat dies zu diesem Zeitpunkt nicht bestätigt.
• 21.10., 14:00 UTC (16:00 Uhr deutscher Zeit): PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35 und die Advisories mit CVE-Nummern. Distributionen hatten die Patches vorab erhalten (Help Net Security).
• Danach: Ubuntu, Debian (teilweise), Plesk, cPanel und andere liefern Pakete nach. Für PHP 7.4, 8.0 und 8.1 erscheinen minimale Backports für Selbstbauer.

Wer ist betroffen?

Betroffen ist praktisch jede Website, die PHP ausführt. Reines HTML ohne PHP ist nicht betroffen, ebenso wenig Baukästen wie Wix oder Jimdo, bei denen der Anbieter das alles erledigt. Ob Ihre Seite konkret angreifbar ist, hängt an vier Dingen: der PHP-Version, der Betriebsart von PHP (mod_php, FPM, andere), der Frage, wer das Update einspielt, und ob es tatsächlich läuft.

Wichtig für WordPress-Betreiber: Die Lücke liegt in PHP, nicht in WordPress. Ein aktuelles WordPress mit aktuellen Plugins schützt Sie nicht, wenn das darunterliegende PHP veraltet ist. Auch ein Sicherheits-Plugin ersetzt das Update nicht. Vor inoffiziellen „Fix-Plugins“ und kopierten Code-Schnipseln warnen mehrere Stellen, darunter Patchstack laut Dr. Web.

Wenn Sie nicht sicher sind, wer bei Ihnen PHP aktualisiert, gilt als Faustregel:

• Webspace/Shared Hosting: der Hoster.
• Managed WordPress-Hosting: der Hoster (bestätigen lassen).
• Managed Server mit Wartungsvertrag: der Anbieter, laut Vertrag.
• VPS/Root-Server/eigene Hardware: Sie, oder wer den Server betreut.
• Docker/Container: wer das Image baut und ausrollt, also meist Sie.
• Fertige Software mit eingebautem PHP (z. B. Nextcloud, Moodle, GLPI, Zabbix-Oberfläche, Appliances): der Hersteller oder Ihr Betreuer.

Was passiert technisch?

Wir beschreiben die Lücken so, wie das PHP-Team selbst es in den Advisories tut, und nicht mehr. Es gibt keine Angriffsanleitung und keine Beispielanfragen.

CVE-2026-109618 (Speichermangel): PHP bricht bei Speichermangel (Out-of-Memory) die aktuelle Anfrage über einen harten Sprung ab. Ist der Speicher der Anfrage zu diesem Zeitpunkt erst teilweise vorbereitet, bleibt er in einem ungültigen Zustand zurück. Beim anschließenden Aufräumen kann PHP diesen Zustand dann als gültig behandeln. Laut Advisory lässt sich das über verschiedene Wege auslösen und kann zur Ausführung fremden Codes führen. Das PHP-Team nennt Beispiele für Auslöser aus dem Bereich der Datei-Upload-Anfragen (Multipart); anwendungsspezifische Auslöser sind ebenfalls möglich.

CVE-2026-109619 (veralteter Zustand): PHP-Worker behalten Zustand von der vorigen Anfrage, der auf bereits freigegebenen Speicher zeigt. Wenn die nächste Anfrage im selben Worker diesen Zustand nutzt, entsteht ein Use-after-free-Fehler, der bei passender Speicheranordnung zur Codeausführung führen kann. Der Angreifer braucht zwei Dinge: eine Anfrage, die den Zustand stört, und eine, die ihn später nutzt. Beide müssen im selben Worker landen. Mehrere Worker oder häufiges Recycling senken die Erfolgsquote laut Advisory, heben das Problem aber nicht auf.

Warum mod_php am stärksten gefährdet ist: Bei Apache mit mod_php läuft PHP im Apache-Prozess selbst. Laut Advisory wurde dort die Codeausführung mit Standardeinstellungen über HTTP bestätigt, bei PHP-FPM zeigt das Advisory einen bestätigten Weg für die zweite Lücke und eine Anfälligkeit nach Quellcodeanalyse für die erste. FrankenPHP und LiteSpeed (LSAPI) gelten als wahrscheinlich bzw. bedingt anfällig.

Warum „hohe Angriffskomplexität“ kein Grund zur Entwarnung ist: Der Wert AC:H im CVSS-Vektor bedeutet, dass ein Angriff mehrere Versuche oder passende Bedingungen braucht. Das hält automatisierte Angriffe nicht auf. Mehrere Sicherheitsfirmen erwarten schnelle Massenversuche nach dem Patch, weil sich aus dem Patch auf die Lücke schließen lässt (Prognose, kein Beleg).

Was wird beobachtet?

• Berichte über erste Angriffe: Cloudflare spricht laut Tenable von frühen Angriffen. Laut Dr. Web meldeten mehrere Hoster Patchstack am Vormittag Angriffe. Ein Live-Blog verzeichnet Anfragen mit auffälligen Multipart-Grenzen und Cloudflare-Meldungen. Das PHP-Team und CISA (KEV) haben dies bisher nicht bestätigt, soweit wir es prüfen konnten.
• Exploit-Code: Es kursieren angebliche Proof-of-Concept-Repositories auf GitHub. Tenable konnte keinen funktionierenden verifizieren, ein Live-Blog warnt vor möglicherweise manipuliertem Code. Laden Sie nichts davon herunter und führen Sie nichts aus.
• Behörden: Das britische NCSC und CERT-EU raten laut Berichten, Systeme, die nicht sofort gepatcht werden können, vom Netz zu nehmen oder abzuschotten. Das BSI hat laut Zweitquellen eine Warnung der Stufe „Orange“ herausgegeben (Originalseite von uns nicht gelesen). Einige Behörden und Hochschulen nahmen Dienste vorübergehend offline.
• Firewalls: Cloudflare hat Regeln bereitgestellt, die für Verkehr über Cloudflare gelten (auch im kostenlosen Tarif). Cloudflare selbst und andere nennen das eine Übergangslösung. Imunify360 hat die Regelversion 8.83 ausgerollt (Virtual Patch, nur mit aktiver WAF). Beides ersetzt das Update nicht.

So prüfen Sie, ob Ihre Seite betroffen ist

Schritt 1: PHP-Version im WordPress-Backend

Werkzeuge, Website-Zustand, Reiter „Info“, Bereich „Server“. Dort steht die PHP-Version, mit der die Website tatsächlich läuft (Menüführung nicht getestet, entspricht der WordPress-Bedienung und den Angaben von Codeable).

Achtung: Die angezeigte Nummer kann auch bei gepatchten Distributionen niedrig aussehen. Ubuntu und Debian ändern die Versionsnummer beim Patchen oft nicht auf die Upstream-Nummer, sondern hängen eigene Zusätze an. Maßgeblich ist dann das Paket-Changelog (siehe unten).

Schritt 2: Auf dem Server

php -v
dpkg -l 'php*' | awk '/^ii/{print $2, $3}'

Beide Befehle haben wir in einer Testumgebung ausgeführt. Das erste zeigt die Version der Kommandozeile, das zweite (Debian/Ubuntu) die installierten Pakete. Die Kommandozeile und der Webserver können unterschiedliche PHP-Versionen nutzen. Maßgeblich ist, was der Webserver ausführt: im WordPress-Backend nachsehen oder php-fpm -v bzw. die Apache-Moduleinstellung prüfen. WP-CLI (nicht ausgeführt): wp eval 'echo PHP_VERSION;'.

Auf Ubuntu/Debian im Changelog nach der Lücke suchen (Befehl aus ma.ttias.be, nicht ausgeführt):

zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

Schritt 3: Läuft noch altes PHP im Speicher?

Nach dem Paket-Update laufen alte Prozesse weiter, bis sie neu gestartet werden. Mit diesem Befehl (aus ma.ttias.be; in einer Testumgebung ohne Fehler gelaufen, dort ohne Treffer) sehen Sie, ob Prozesse noch auf gelöschte Programmdateien zeigen:

sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps

Leere Ausgabe bedeutet: kein Prozess nutzt mehr gelöschte Dateien aus diesen Verzeichnissen. Unter Ubuntu/Debian zeigt zusätzlich sudo needrestart -b -r l (nicht getestet), welche Dienste einen Neustart brauchen.

Schritt 4: Hinweise auf eine Übernahme

Diese Prüfungen sind allgemeine Hygiene. Wir kennen für die beiden Lücken keine gesicherten Erkennungsmerkmale (Indikatoren). Treffer sind kein Beweis, fehlende Treffer keine Entwarnung. Die folgenden Befehle haben wir gegen ein Beispielverzeichnis getestet (im WordPress-Verzeichnis ausführen):

find wp-content/uploads -type f -name '*.php' -print
find . -name '*.php' -newermt '2026-10-20' -not -path './wp-content/plugins/*' -print
grep -rIl --include=*.php -E 'eval\(base64_decode' .

Die erste Zeile findet PHP-Dateien im Upload-Ordner (dort gehören keine hin). Die zweite findet seit dem 20.10. geänderte PHP-Dateien außerhalb der Plugin-Ordner; beachten Sie, dass normale Updates ebenfalls Dateien ändern. Die dritte sucht nach einem häufigen Verschleierungsmuster.

Im PHP-Fehlerlog (Pfad je nach Hoster) kann eine Häufung von Speichermangel-Meldungen ab dem 21.10. ein Hinweis auf Angriffsversuche sein, weil die erste Lücke Speichermangel ausnutzt. Das ist eine Überlegung von uns, kein bestätigter Indikator. Befehl, gegen ein Beispiellog getestet:

grep -E '^\[21-Oct-2026' php_errors.log | grep -E 'Allowed memory size|Maximum execution time'

Ein Live-Blog berichtet außerdem von Anfragen mit auffälligen Multipart-Kennungen; ohne Rohdaten der Anfrage-Köpfe sehen Sie das in normalen Zugriffs-Logs nicht. Vergleichen Sie stattdessen: neue Administratoren (WP-CLI, nicht ausgeführt: wp user list --role=administrator --fields=ID,user_login,user_email,user_registered), unbekannte geplante Aufgaben, neue Dateien im Webroot.

Wenn Sie Anzeichen finden: Server nicht selbst „aufräumen“, sondern Logs sichern, Zugang trennen und unsere Hack-Notfallhilfe oder Ihren Hoster einschalten. Ist ein Server mit personenbezogenen Daten übernommen worden, kann nach Art. 33 DSGVO eine Meldung an die Datenschutzaufsicht innerhalb von 72 Stunden nötig sein (keine Rechtsberatung; im Zweifel Fachleute fragen).

Was gilt für Ihre PHP-Version?

PHP-Zweig;Stand;Fix;Was zu tun ist
8.5;aktiv unterstützt;8.5.12;Update einspielen, Prozesse neu starten.
8.4;aktiv unterstützt;8.4.27;Update einspielen, Prozesse neu starten. Empfohlenes Ziel für Umzüge.
8.3;Sicherheitsupdates bis Ende 2027 (laut Level Nord);8.3.36;Update einspielen, Prozesse neu starten.
8.2;Sicherheitsupdates nur noch bis 31.12.2026;8.2.35;Heute patchen, aber den Wechsel auf 8.3/8.4 noch in diesem Quartal planen.
8.1;seit Ende 2025 ohne Support;kein regulärer Fix. Backport für Quellcode-Builds, Ubuntu 22.04 hat ein Distributionspaket;Distributions-Backport nutzen, wenn vorhanden. Sonst auf 8.3/8.4 umziehen. Bis dahin Zugriff einschränken.
8.0;seit 2023 ohne Support;kein regulärer Fix. Minimaler Backport;Wie 8.1, Umzug dringend.
7.4;seit 2022 ohne Support;kein regulärer Fix. Minimaler Backport, Ubuntu 20.04 (Pro/ESM), cPanel ea-php74 in Vorbereitung, Plesk „in Entwicklung“;Fix nur über Anbieter. Sonst Umzug.
7.0 bis 7.3;lange ohne Support;nur über Spezialanbieter (z. B. Ubuntu ESM für 7.0/7.2, TuxCare laut Plesk für 5.6/7.2/7.3);Umzug dringend. Bis dahin vom Netz nehmen oder per VPN schützen.
5.x;seit Jahren ohne Support;nur über Spezialanbieter;Nicht mehr sinnvoll betreibbar. Umziehen.

Die Spalte „Fix“ beschreibt, was wir bei der Recherche gesehen haben. Offiziell bewertet das PHP-Team nur 8.2 bis 8.5. Berichte nennen alle Versionen ab 5.4 als betroffen; wir behandeln ältere Zweige deshalb als gefährdet. Die Zahl der Hosts ist groß: Laut Mallory laufen rund 59 Prozent der öffentlich erreichbaren PHP-Hosts mit erkennbarer Version auf einem Zweig ohne regulären Fix (883.717 von etwa 1,5 Millionen). Eine Quelle, Methodik ungeprüft.

Der Wechsel von PHP 8.1 auf 8.3/8.4 in der Praxis (WordPress):

1. Vollständiges Backup (Dateien und Datenbank), Backup-Wiederherstellung kurz testen.
2. Wenn möglich auf einer Staging-Kopie umstellen. Plugins, Theme und WordPress aktualisieren.
3. Auf Fehlermeldungen achten (veraltete Plugins sind der häufigste Grund für Probleme bei neueren PHP-Versionen).
4. Bei Problemen: Plugin ersetzen oder entfernen. Die Notlösung „alte PHP-Version behalten“ ist gerade keine.

Was gilt für Ihr Betriebssystem?

Das Prinzip ist immer gleich: Das PHP-Update muss aus derselben Quelle kommen, aus der Ihr PHP stammt (Betriebssystem, Drittanbieter-Repository, Docker-Image, Panel, selbst gebaut). Danach müssen alle Prozesse neu gestartet werden, die PHP ausführen.

Ubuntu

Release;PHP-Paket;Gefixte Version laut Ubuntu;Voraussetzung
26.10;php8.5;8.5.9-0ubuntu2.1;normales Update
26.04 LTS;php8.5;8.5.4-0ubuntu1.5;normales Update
24.04 LTS;php8.3;8.3.6-0ubuntu0.24.04.13;normales Update
22.04 LTS;php8.1;8.1.2-1ubuntu2.28;normales Update
20.04 LTS;php7.4;7.4.3-4ubuntu2.29+esm5;Ubuntu Pro (ESM)
18.04 LTS;php7.2;7.2.24-0ubuntu0.18.04.17+esm14;Ubuntu Pro (ESM)
16.04 LTS;php7.0;7.0.33-0ubuntu0.16.04.16+esm22;Ubuntu Pro (ESM)
14.04 LTS;php5;5.5.9+dfsg-1ubuntu4.29+esm18;Ubuntu Pro (ESM)

Quelle: Ubuntu-Blog zu php2shell und USN-8948-1 (21.10.2026; die USN-Seite listet nur die Standard-Releases).

Beachten Sie die Versionsnummern: Auf Ubuntu 24.04 ist die gepatchte PHP-Version nach Ubuntu-Zählweise 8.3.6-…-.13, also nicht 8.3.36. Ubuntu bleibt bei der Grundversion und portiert nur die Korrekturen zurück. Wer nur auf php -v schaut und „8.3.6“ liest, hält das Server-PHP fälschlich für uralt. Entscheidend ist das Paket-Changelog beziehungsweise die Paketversion aus der Tabelle.

Ablauf auf Ubuntu/Debian (Befehle aus der Ubuntu-Anleitung und ma.ttias.be; nicht ausgeführt, außer dpkg):

dpkg -l 'php*' | awk '/^ii/{print $2, $3}'
sudo apt update
apt list --upgradable 2>/dev/null | grep php
sudo apt install --only-upgrade 'php8.3*' libapache2-mod-php8.3

Für jede auf dem Server installierte PHP-Version wiederholen (hier als Beispiel 8.3). Danach neu starten, je nach Betriebsart:

Betriebsart;Maßnahme
PHP-FPM;`sudo systemctl restart php8.3-fpm`. Laut ma.ttias genügt auch ein `reload`, wir empfehlen `restart`.
Apache mit mod_php;`sudo systemctl restart apache2`. `reload` oder `apachectl graceful` reichen laut ma.ttias nicht.
LiteSpeed;`lsphp`-Pakete aktualisieren, dann `sudo pkill lsphp` (aus ma.ttias.be).
Queue-Worker, Cronjobs, Laravel Octane;neu starten. Laravel-Queues: `php artisan queue:restart`.

Ist unattended-upgrades aktiv, spielt Ubuntu das Update laut Ubuntu-Blog innerhalb von 24 Stunden ein. Der Neustart der Dienste bleibt trotzdem nötig.

Ubuntu 20.04: der Sonderfall

Ubuntu 20.04 („Focal“) liefert PHP 7.4 (nach Ubuntu-Zählweise 7.4.3). Beides ist für das PHP-Projekt lange ausgelaufen. Das Betriebssystem selbst erhält nach unserem Kenntnisstand seit 2025 keine regulären Sicherheitsupdates mehr (nicht neu geprüft); Updates gibt es nur noch über Ubuntu Pro (ESM, Expanded Security Maintenance). Genau das gilt auch für diesen Fix: Er steht laut Ubuntu als 7.4.3-4ubuntu2.29+esm5 bereit, aber nur für Pro-Kunden. Ubuntu Pro ist laut Ubuntu-Blog für bis zu fünf Rechner kostenlos (für Community-Mitglieder bis zu 50).

Schritt 1: Feststellen, woher Ihr PHP kommt. Viele Server auf 20.04 haben ein PHP aus einem Fremd-Repository (zum Beispiel einem PPA von Ondřej Surý) statt aus Ubuntu selbst:

php -v
apt policy php7.4-cli

apt policy (nicht ausgeführt) zeigt, aus welcher Quelle das Paket stammt. Stammt es aus dem Ubuntu-Archiv, folgen Sie Weg A. Stammt es aus einem PPA oder Repository eines Drittanbieters, ist dessen Betreiber zuständig, und für diese Quellen haben wir keine belegte Zusage gefunden (Remi hat laut ma.ttias.be ausdrücklich keinen Fix am 21.10. zugesagt; für Sury nennt dieselbe Quelle keinen Termin). Dann Weg C.

Weg A: Ubuntu Pro aktivieren und den Fix einspielen (Befehle nach Ubuntu-Dokumentation und ma.ttias.be, nicht ausgeführt, Pro-Token aus Ihrem Ubuntu-Konto):

sudo pro attach <IHR-TOKEN>
pro status
sudo pro fix CVE-2026-109618
sudo apt update && sudo apt install --only-upgrade 'php7.4*'
sudo systemctl restart apache2     # bzw. php7.4-fpm

pro status zeigt, welche ESM-Dienste aktiv sind. Das Paket liegt nach unserem Wissen im Bereich „universe“; dann kommt der Fix aus dem Dienst für Anwendungen (esm-apps), nicht nur aus dem Basis-Dienst (esm-infra). ma.ttias.be nennt „ESM Infra“. Prüfen Sie daher mit pro status, dass beide Dienste aktiv sind. Mit pro fix CVE-2026-109618 prüft Pro, ob ein Fix für Ihr System bereitsteht, und spielt ihn ein. Prüfen Sie anschließend im Changelog (zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php7.4-*/changelog.Debian.gz), dass die Korrektur drin ist.

Weg B: Kein Pro, kein Fremd-PPA. Dann gibt es für 20.04 keinen Weg zum Fix außer Pro. Pragmatisch:

1. Sofort: Zugriff einschränken (VPN, IP-Freigabe, Passwortschutz auf Webserver-Ebene), wo die Website das zulässt. Das BSI nennt laut Zweitquellen Offlineschalten als letzte Option, wenn nichts anderes geht.
2. Heute: Ubuntu Pro für diese Maschine aktivieren (kostenlos bis fünf Rechner), dann Weg A.
3. Parallel: Umzug planen.

Weg C: PHP aus einem Fremd-Repository. Sie haben drei Möglichkeiten: Warten, bis der Betreiber des Repositories patcht (Termin unbekannt), auf das Ubuntu-Paket wechseln (Vorsicht: Versionssprung kann Anwendungen brechen) oder auf eine neuere, unterstützte PHP-Version umziehen. Wir raten zum Umzug.

Der eigentliche Weg: Umzug auf ein unterstütztes System. Ubuntu 20.04 und PHP 7.4 sind zwei Altlasten auf einmal. Ziel: Ubuntu 24.04 LTS mit PHP 8.3 (Ubuntu-Paket) oder 8.4. Ein direktes Hochstufen von 20.04 auf 24.04 ist nicht in einem Schritt vorgesehen (nach unserem Kenntnisstand läuft das über 22.04). In der Praxis ist ein neuer Server meist sauberer: neues System aufsetzen, WordPress und Datenbank per Backup übertragen, testen, DNS umstellen. Bis dahin gilt: Pro-Patch einspielen, Zugriff einschränken, Backups prüfen.

Wenn Sie nichts davon sicher beurteilen können: Das ist normal. Der Sicherheitscheck klärt PHP-Herkunft, Patchstand und Anzeichen einer Übernahme.

Debian

Der Debian-Sicherheitstracker zeigte beim Abruf am Nachmittag (ca. 15:30 UTC): php8.4 in Debian 13 (trixie) ist mit 8.4.27-1~deb13u1 behoben (DSA-6574-1). php8.2 in Debian 12 (bookworm) stand zu diesem Zeitpunkt noch auf „vulnerable“, ohne Fix (inzwischen behoben, siehe oben). Für Debian 11 endete der reguläre LTS-Support laut ma.ttias.be am 31.08.2026; Fixes gibt es nur über das kostenpflichtige ELTS von Freexian. Der Stand ändert sich schnell: Prüfen Sie den Tracker selbst. Wer auf Debian 12 PHP 8.2 aus dem Debian-Archiv nutzt, spielt das inzwischen veröffentlichte Update ein. Alternativ liefert das Sury-Repository (packages.sury.org) neuere PHP-Zweige; ein Termin für gepatchte Builds war nicht bekannt. Der Ablauf (apt, Neustart) entspricht dem Ubuntu-Ablauf oben.

Red Hat, AlmaLinux, Rocky Linux

Diese Distributionen liefern PHP über Module-Streams (RHEL 8 und 9) beziehungsweise Standardpakete (RHEL 10). Ob die gefixten Pakete schon bereitstehen, konnten wir nicht prüfen (Red-Hat-Seite nicht abrufbar). Am Vormittag standen laut ma.ttias.be RHEL 9 bei 8.2.33 und 8.3.33, also ohne Fix. Befehle zum Prüfen und Einspielen (aus ma.ttias.be, nicht ausgeführt):

rpm -qa 'php*' | sort
dnf module list --enabled php
sudo dnf upgrade 'php*'
dnf updateinfo list --security | grep php

Achtung bei RHEL 8: dnf install php installiert standardmäßig PHP 7.2, das seit 2021 keine Fixes bekommt (ma.ttias.be). Für Remi-Pakete (php84-php-fpm usw.) gab es am 21.10. laut ma.ttias.be keinen Fix; die PHP Foundation rät dort zum Wechsel auf Distributionspakete oder zum Selbstbauen. Auch hier: erst Paket-Update, dann systemctl restart php-fpm beziehungsweise httpd.

Docker und Container

Neues offizielles php:-Image ziehen beziehungsweise eigene Images mit docker build --pull neu bauen und die Container neu erstellen. Pinnt Ihr Dockerfile eine alte Patch-Version (zum Beispiel php:8.3.30-apache), muss die Zahl angehoben werden. apt oder dnf im laufenden Container aktualisieren das PHP in FrankenPHP-Images nicht. Die Hinweise stammen aus cms-admins.de und ma.ttias.be; wir haben sie nicht getestet.

Panels: Plesk, cPanel/CloudLinux

Plesk (Linux): Laut Plesk stellt Plesk inzwischen gepatchte Pakete bereit (siehe Aktualisierung oben). Zum Stand des 21.10. war der Fix für 7.4, 8.0 und 8.1 noch „in Entwicklung“, und für Plesk unter Windows gab es noch keine Fixes. Für PHP 5.6, 7.2 und 7.3 verweist Plesk auf das kostenpflichtige TuxCare Extended Lifecycle Support. Die installierte Version sehen Sie unter Tools & Settings, PHP Settings, oder per /opt/plesk/php/8.3/bin/php -v.

cPanel/CloudLinux: Laut Live-Blog bereitet cPanel Updates für ea-php74 bis ea-php85 vor (13:30 Uhr BST). CloudLinux bereitet einen Fix für alt-php vor, ohne Zeitplan (CloudLinux). Imunify360 hat die Regelversion 8.83 ausgerollt; sie blockiert das bekannte Muster, ist aber ein Virtual Patch. Prüfen Sie die Regelversion und aktualisieren Sie bei Bedarf (aus dem CloudLinux-Beitrag, nicht ausgeführt):

cat /etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/VERSION
imunify360-agent update --force modsec-rules

Wie Hoster damit umgehen

Wir haben die Stellungnahmen gelesen, die uns bis zum Nachmittag zugänglich waren. Sie sind Herstellerangaben und nicht unabhängig geprüft. Wichtig: Eine Maßnahme des Hosters bedeutet nicht automatisch, dass jede PHP-Version in jedem Tarif gepatcht ist.

Anbieter;Was der Anbieter sagt (Stand);Was Kunden tun müssen
netcup;Webhosting und Managed Server: Härtungsmaßnahmen werden vorbereitet, Patch wird automatisch eingespielt. Für ältere PHP-Versionen ohne offiziellen Patch will netcup einen eigenen Patch bauen und anwenden. Root-Server, VPS und Managed-Cloud-VMs: Verantwortung beim Kunden ([netcup-Status](https://www.netcup-status.de/2026/10/cve-2026-109618-109619-information-fuer-netcup-kunden-cve-2026-109618-109619-information-for-netcup-customers/)).;Webhosting/Managed: nichts. Root/VPS: selbst patchen, PHP-Versionen prüfen, Upgrade älterer Versionen vorbereiten.
SiteGround;Serverseitige Schutzregeln auf allen Servern ausgerollt, betroffene Funktionen für alle unterstützten PHP-Versionen deaktiviert (Stand 11:30 UTC) ([SiteGround](https://www.siteground.com/blog/critical-php-vulnerabilities-october-2026)).;Laut SiteGround keine Maßnahmen nötig. Bestätigung des finalen Updates abwarten oder erfragen.
Hetzner;Statusmeldung, Beginn 21.10. 11:04 UTC. Aktualisiert 22.10.: Bei unserem Abruf weiter „Investigating“. Eine Zweitquelle (hosttest.at) zitiert eine Meldung, wonach PHP 7.4 und 8.0 bis 8.5 bei Webhosting und Managed Servern gepatcht sind. Widerspruch, nicht aufgelöst ([Hetzner-Status](https://status.hetzner.com/incident/f4144d55-38c3-48d1-8664-7a3429355cd7)).;Statusseite selbst ansehen, Version im Kundenbereich prüfen. Eigene Server selbst patchen.
Serverprofis;Upload-Fortschritt (`session.upload_progress.enabled`) serverweit abgeschaltet. Ab 15:50 Uhr ModSecurity-Regel, die Datei-Uploads über die Website (multipart/form-data) mit 403 blockiert. Pakete kommen von CloudLinux/cPanel, Rollout nach Tests ([Serverprofis](https://www.serverprofis.de/php2shell-kritische-php-sicherheitsluecke/)).;Upload-Fortschritt nicht per `.user.ini` wieder einschalten, CMS aktuell halten, auf unbekannte Dateien und neue Administratoren achten. Uploads über die Website sind vorübergehend blockiert.
webhostone;Managed-Service-Kunden vorsorglich abgesichert, Sicherheitsversionen für 8.2 bis 8.5 sofort nach Release, ältere Versionen mit Sonderlösungen eventuell Stunden später ([webhostone](https://www.webhostone.de/blog/artikel/php2shell-kritische-php-sicherheitsluecke)). Eigenwerbung des Anbieters.;Managed: nichts. Root/vServer ohne Managed Service: selbst patchen.
Plesk (Panel);Aktualisiert 22.10.: Gepatchte Pakete unter Linux für 8.2 bis 8.5 sowie 8.1, 8.0 und 7.4, unter Windows für 8.2 bis 8.5 ([Plesk](https://support.plesk.com/hc/en-us/articles/44397729587351-Vulnerability-CVE-2026-109618-and-CVE-2026-109619-Remote-code-execution-in-PHP-shipped-with-Plesk)).;Updates im Panel einspielen, sobald verfügbar.
cPanel/CloudLinux-Hoster;`ea-php74` bis `ea-php85` in Vorbereitung, `alt-php` ohne Zeitplan. Imunify-Regel 8.83 als Zwischenschutz.;Beim Hoster nach dem Termin für Ihre PHP-Version fragen.
Kinsta, WP Engine, Pressable, WordPress VIP;Laut einem Beitrag von [Codeable](https://www.codeable.io/blog/php-vulnerability-cve-2026-109618/) aktualisieren solche Anbieter PHP selbst. Eine Bestätigung der Anbieter haben wir nicht gefunden, die Quelle ist eine Werbeseite.;Beim Anbieter nachfragen und sich bestätigen lassen.
Hostinger;Aktualisiert 22.10.: Regeln gegen bekannte Angriffsmuster, Upload-Fortschritt abgeschaltet, gepatchtes PHP auf der Plattform ausgerollt und Kunden angeschrieben ([Hostinger-Blog](https://www.hostinger.com/blog/protecting-php2shell/), 21.10., Herstellerangabe).;Tarife außer VPS: laut Hostinger nichts. VPS: selbst patchen. Empfehlung: auf PHP 8.3 oder neuer wechseln (nach Backup und Test).
IONOS;Aktualisiert 22.10.: Statusmeldung zu „Sicherheitswartungen“ (laut [hosttest.at](https://www.hosttest.at/artikel/kritische-php-sicherheitsluecke-php2shell), Original nicht gelesen).;VPS und Dedicated Server selbst aktualisieren. Sonst beim Anbieter nachfragen.
Alfahosting;Aktualisiert 22.10.: Betreut laut Statusseite (nach hosttest.at) die PHP-Umgebung bei Webspace.;vServer und Root-Server selbst patchen.
Strato, all-inkl, mittwald, Raidboxes, Hosteurope, DomainFactory;Keine öffentliche Stellungnahme gefunden. Das heißt nicht, dass keine existiert, nur dass wir keine lesen konnten.;Kundenbereich und Statusseite des Anbieters ansehen, schriftlich nachfragen (Vorlage unten).

Zwei Dinge, die bei allen Hostern gelten:

1. „Wir haben Schutzmaßnahmen“ ist nicht dasselbe wie „wir haben gepatcht“. Maßnahmen wie abgeschalteter Upload-Fortschritt oder Firewall-Regeln sind Notbehelfe. Fragen Sie nach der PHP-Version, die für Ihren Tarif nach dem Update tatsächlich läuft.
2. Alte PHP-Versionen im Tarif. Wer in seinem Tarif noch PHP 7.4 oder 8.1 eingestellt hat, wird vom Update des Hosters unter Umständen nicht erfasst. Stellen Sie selbst auf eine unterstützte Version um (nach Backup und Test).

Vorlage für die Nachfrage beim Hoster:

Guten Tag, zu den PHP-Lücken CVE-2026-109618 und CVE-2026-109619: Auf welche PHP-Version (genaue Nummer oder Paketversion) laufen meine Tarife/Server [Kundennummer, Domain] nach Ihrem Update? Wann wurde oder wird gepatcht, und gilt das auch für PHP [Ihre eingestellte Version]? Gibt es Einschränkungen, zum Beispiel für Datei-Uploads, die Sie vorübergehend gesetzt haben, und wann werden sie aufgehoben? Bitte bestätigen Sie mir das schriftlich.

Zwischenmaßnahmen: Was sie können und was nicht

Es kursieren Konfigurationsänderungen als Notbehelf. Die Meinungen darüber gehen auseinander, deshalb hier die Lage nüchtern:

• PHP-Advisory: Das Update ist die einzige vollständige Lösung. Als unvollständige Maßnahmen nennt das PHP-Team ein hartes Setzen von memory_limit=-1 über die Serverkonfiguration (nicht über Anwendungen), eine konservative post_max_size, Grenzen für Anfragegröße, Verschachtelung und Anzahl der Formularfelder und Uploads, und für die zweite Lücke session.upload_progress.enabled=0 sowie bei PHP 8.5 fatal_error_backtraces=0, jeweils mit Neustart aller Worker. Ausdrücklich nicht verwenden: RLIMIT_AS und RLIMIT_DATA (sie können den verwundbaren Pfad auslösen). Falls keine Datei-Uploads genutzt werden, können solche Anfragen am Frontend blockiert werden.
• Skepsis: PHP-Entwickler wie Joe Ferguson sagen laut Tenable, INI-Einstellungen würden einen nicht retten; GMO Flatt hat laut Live-Blog seinen Workaround zurückgenommen.
• Behörden: Das BSI kennt laut Zweitquelle keinen verlässlichen Workaround und nennt das Vom-Netz-Nehmen als Option.
• Nebenwirkungen: Blockaden von multipart/form-data brechen Upload-Felder, Kontaktformulare mit Anhang, Shop-Kassen und das Mediathek-Hochladen. Server-weite Änderungen sollten vom Hoster kommen, nicht aus Plugins.
• Unser Rat: Wenn Sie heute patchen können: patchen. Wenn nicht: Zugriff einschränken (VPN, Passwortschutz), Backups sichern, und Notbehelfe nur als Brücke bis zum Update einsetzen. Danach zurücknehmen, was Sie nicht brauchen (Multipart-Blockaden; session.upload_progress kann aus Sicherheitsgründen aus bleiben, wenn Ihre Anwendung keine Fortschrittsbalken benötigt, das empfiehlt auch das PHP-Advisory). Vermeiden Sie Skripte, die Sie nicht gelesen haben; ein auf GitHub kursierendes Skript zum Abschalten der Einstellung nennt sich selbst „stopgap, not a fix“ und rät, es nicht blind auszuführen.

Sonderfälle

• WordPress mit Cloudflare davor: Die Cloudflare-Regeln greifen nur für Verkehr, der über Cloudflare läuft. Ist der Server auch direkt über seine IP erreichbar, laufen Angriffe daran vorbei. Eine Firewall ersetzt das Update nicht.
• TYPO3, Drupal, Joomla, Shopware, Laravel/Symfony: Betroffen ist PHP, nicht das CMS. Composer- oder Framework-Updates beheben das nicht. Bei Shopware/Symfony Cronjobs und Worker auf der Kommandozeile im selben Durchgang aktualisieren (d-schwenker.de).
• Mehrere PHP-Versionen auf einem Server: Jede einzeln prüfen und patchen, auch die, die „nur für ein altes Projekt“ laufen.
• Nextcloud, Moodle, GLPI, Zabbix und Appliances mit eingebautem PHP: Hersteller-Update abwarten oder erfragen, Zugriff bis dahin einschränken.
• Windows/IIS: Für Plesk unter Windows hat Plesk inzwischen Fixes für 8.2 bis 8.5 bereitgestellt (siehe Aktualisierung bei den Panels). Bei eigenen Windows-Servern die Windows-Builds von php.net nutzen und prüfen.
• Staging- und Testsysteme: Oft vergessen, oft schlecht gepflegt, aber ebenso erreichbar. Mit inventarisieren.

Nach dem Update: eine Checkliste

1. PHP-Version über den Webserver bestätigen (Website-Zustand), nicht nur per Kommandozeile.
2. Prüfen, dass alle Prozesse neu gestartet sind (Befehle weiter oben).
3. Zwischenmaßnahmen zurücknehmen, die Funktionen blockieren (Multipart-Blockaden), sofern der Hoster sie nicht selbst steuert.
4. Auf Zeichen einer Übernahme prüfen: PHP-Dateien in Upload-Ordnern, neue Administratoren, geänderte Theme-Dateien, unerwartete Weiterleitungen, Spam-Treffer bei Google.
5. Passwörter, Sitzungen und Zugangsdaten erneuern, falls etwas auffällt.
6. Backups prüfen: Gibt es eines von vor dem 21.10., das sich wiederherstellen lässt?
7. Dokumentieren: Welche Version lief wann, wer hat wann gepatcht. Das hilft bei Rückfragen von Kunden und, falls nötig, der Datenschutzaufsicht.

Fazit

Die gute Nachricht: Der Fix ist da, und die Schritte sind überschaubar. Für die meisten Websites auf gepflegtem Shared Hosting heißt das: Version prüfen, beim Hoster nachhaken, fertig. Die Gefahr liegt bei den vergessenen Systemen: ein 20.04-Server mit PHP 7.4, ein Tarif mit alter PHP-Einstellung, ein Testsystem, das niemand mehr kennt. Heute lohnt sich ein ruhiger Inventurblick. Wir aktualisieren diesen Beitrag, sobald sich Ausnutzung, Hoster-Stand oder Distributionspakete ändern.

Häufige Fragen

Muss ich WordPress oder meine Plugins jetzt aktualisieren?

Nicht wegen dieser Lücke. WordPress, Plugins und Themes sind nicht das Problem. Aktuell halten sollten Sie sie ohnehin.

Hilft ein Sicherheits-Plugin?

Nein, nicht gegen diese Lücke. Sie sitzt in PHP, bevor Plugin-Code überhaupt läuft. Vor „Fix-Plugins“ und Code-Schnipseln warnt unter anderem Patchstack.

Bin ich sicher, wenn mein Hoster „alles erledigt“ sagt?

Lassen Sie sich die PHP-Version und das Datum des Updates bestätigen und prüfen Sie die Version im Website-Zustand.

Woher weiß ich, ob meine Seite schon angegriffen wurde?

Sicher nur durch Prüfung: neue PHP-Dateien, unbekannte Administratoren, Logs. Fehlende Anzeichen sind keine Garantie.

Reicht es, auf PHP 8.2 zu bleiben?

Für heute ja (8.2.35), aber der Sicherheitssupport endet am 31.12.2026. Planen Sie den Wechsel auf 8.3 oder 8.4.

Mein Server läuft auf Ubuntu 20.04. Was jetzt?

Siehe Abschnitt oben: Pro aktivieren und pro fix einspielen, Zugriff einschränken, Umzug planen.

Kann ich die Datei-Upload-Funktion einfach abschalten?

Als kurzfristige Brücke, ja, mit allen Nebenwirkungen (Mediathek, Formulare, Shop). Besser ist das Update.

Was kostet es, wenn Sie das für uns erledigen?

Der Preis hängt von Anzahl und Art der Server ab. Für den Fall einer Übernahme nennen wir unsere Notfallpreise unten; für Prüfung und Wartung sprechen Sie uns an.

Unser Angebot

Sie wissen nicht, welche PHP-Version Ihre Seiten nutzen oder wer sie aktualisiert? Der Sicherheitscheck prüft PHP-Stand, Herkunft des PHP, Plugins, Konten und Dateien und sagt Ihnen, was zu tun ist. Bei Auffälligkeiten hilft die Hack-Notfallhilfe (Bereinigung ab 249 €, Bereinigung und Härtung ab 549 €, einmalig zzgl. MwSt.). Wer Updates und Prüfungen dauerhaft abgeben möchte: WordPress-Wartung (ab 129 € pro Monat zzgl. MwSt.). Weiterführend: Anzeichen eines Hacks und die ersten 10 Schritte und WordPress gehackt – was tun?.