PHP2Shell: Was die kritische PHP-Sicherheitslücke für Ihre Server bedeutet

Update vom 27.10.: Am 24. Oktober hat ein Forscher von Perplexity auf eigenen Honeypots mit PHP 8.4.26 und mod_php erfolgreiche Angriffe beobachtet, 35 geöffnete Shells in einem Tag (SecurityWeek). Die US-Behörde CISA hat beide CVEs am 26. Oktober in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen. Seit dem 23. Oktober rät das PHP-Projekt außerdem, session.upload_progress.enabled=0 auch auf gepatchten Systemen bis zum nächsten regulären Bugfix-Release gesetzt zu lassen, wegen einer weiteren, nur in seltenen Konfigurationen ausnutzbaren Lücke (CVE-2026-115560, php.net). Der übrige Text gibt den Stand vom 23. Oktober wieder.

PHP2Shell ist der Name für zwei kritische Sicherheitslücken in PHP selbst, CVE-2026-109618 und CVE-2026-109619. Angreifer können darüber ohne Anmeldung Code auf dem Webserver ausführen. Schließen lässt sich das nur mit dem PHP-Update auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 vom 21. Oktober 2026. Ein Update von WordPress oder Nextcloud allein genügt nicht.

Wer eine Website, einen Shop oder eine selbst gehostete Nextcloud betreibt, sollte das Update heute einplanen.

Was ist PHP2Shell?

Hinter dem Namen stecken zwei Fehler in der Speicherverwaltung von PHP. Bei CVE-2026-109618 bricht PHP eine Anfrage ab, weil der Speicher ausgeht, und räumt danach Daten auf, die nur halb initialisiert waren. CVE-2026-109619 betrifft interne Zustände, die eine Anfrage überleben, obwohl ihr Speicher längst freigegeben ist. Bearbeitet derselbe PHP-Prozess danach eine weitere Anfrage, greift er auf diese Reste zu. Beide Lücken haben im Sicherheitshinweis des PHP-Projekts einen CVSS-4.0-Wert von 9,2.

Der Angriff passiert schon beim Verarbeiten der HTTP-Anfrage, bei mod_php sogar bevor eine Zeile Anwendungscode läuft. Login-Schutz und Sicherheits-Plugins greifen da noch gar nicht. Die Sicherheitsfirma Wiz hat laut Recorded Future eine Ausnutzung ohne Anmeldung gegen WordPress und Drupal demonstriert. Über einen Teil der Fehler lassen sich außerdem Speicherinhalte auslesen, in denen Passwörter oder API-Schlüssel stehen können.

Zur Lage am 23. Oktober: Amazon hat nach eigenen Angaben schon am 17. Oktober, vier Tage vor der Veröffentlichung, einen Angriffsversuch auf einem seiner Honeypots gesehen. Am 21. Oktober kursierten öffentliche Proof-of-Concept-Exploits, und mehrere Hoster meldeten dem Dienstleister Patchstack Angriffsversuche. Das BSI kannte in seiner Warnung vom 22. Oktober noch keine bestätigte erfolgreiche Ausnutzung, sprach aber von unbestätigten Berichten über funktionierende Exploits.

Welche PHP-Versionen sind betroffen?

Betroffen sind alle Versionen vor den Sicherheitsreleases vom 21. Oktober. Das PHP-Projekt nennt ausdrücklich jede Installation, die Web-Requests bedient: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht es bei mod_php, weil dort ein funktionierender Exploit bereits gezeigt wurde.

Die Supportzeiträume stammen aus der offiziellen Übersicht auf php.net.

Und wenn noch PHP 8.1 oder 7.4 läuft?

PHP 8.1 und ältere Zweige bekommen vom PHP-Projekt keine Releases mehr. Wegen der Schwere der Lücken hat das Sicherheitsteam zwar minimale Quellcode-Patches für 7.4, 8.0 und 8.1 bereitgestellt, die sind aber für Leute gedacht, die PHP selbst kompilieren. Einige Linux-Distributionen und kommerzielle LTS-Anbieter liefern Backports. Ob das für Ihr System gilt, sagt Ihnen nur der Sicherheitshinweis Ihres Anbieters.

Für noch ältere Versionen gibt es gar nichts, und Recorded Future warnt ausdrücklich davor, sie für unbetroffen zu halten. Wer heute noch eine Anwendung auf PHP 7 betreibt, hat meist einen Grund, etwa ein altes Shopsystem oder eine Eigenentwicklung, die niemand anfassen wollte. Diese Baustelle gehört jetzt auf den Tisch, und bis sie erledigt ist, sollte so ein System nicht offen im Internet hängen. Das britische NCSC rät, nicht absicherbare Systeme vom Netz zu nehmen.

Sind Nextcloud, WordPress und Onlineshops betroffen?

Ja, sofern sie auf einer ungepatchten PHP-Version laufen. Nextcloud, WordPress, Shopware, WooCommerce, Joomla, Typo3 und die meisten Eigenentwicklungen auf PHP-Basis hängen alle an derselben Laufzeitumgebung. Umgekehrt müssen Sie Ihre Nextcloud für PHP2Shell nicht anfassen, solange der PHP-Zweig gleich bleibt.

Viele Nextcloud-Installationen laufen in Docker, etwa als Nextcloud All-in-One. Container bringen ihr eigenes PHP mit, das Update des Host-Systems erreicht sie nicht. Nextcloud AIO hat am 21. Oktober die Version 14.4.1 mit aktualisiertem PHP veröffentlicht und rät dringend zum Update. Wer eigene Images baut, muss sie neu bauen und die Container neu starten.

Nextcloud 35 unterstützt nur noch PHP 8.3 bis 8.5 und empfiehlt 8.5. Wer das Update auf Nextcloud 35 ohnehin plant, kann den PHP-Wechsel gleich mit erledigen.

Wie prüfe ich meine PHP-Version?

Entscheidend ist die Version, mit der Ihr Webserver die Seiten ausliefert. Die kann von der Version auf der Kommandozeile abweichen, und auf Servern mit Plesk oder cPanel laufen oft mehrere PHP-Versionen nebeneinander.

Auf dem eigenen Server

Per SSH zeigt php -v die Version der Kommandozeile. Für PHP-FPM fragen Sie das passende Binary direkt ab, unter Debian und Ubuntu zum Beispiel php-fpm8.4 -v. Unter Plesk liegen die Versionen in /opt/plesk/php/, also etwa /opt/plesk/php/8.4/bin/php -v.

Sicherer ist der Blick aus der Anwendung heraus. WordPress zeigt die PHP-Version unter Werkzeuge, Website-Zustand, Bericht im Abschnitt Server. In Nextcloud finden Administratoren sie in den Verwaltungseinstellungen unter Systeminformationen. Alternativ legen Sie kurz eine Datei mit <?php phpinfo(); ins Webverzeichnis, rufen sie im Browser auf und löschen sie sofort wieder. Diese Seite verrät Angreifern sehr viel über Ihr System.

Bei Distributionspaketen kann die Nummer täuschen. Ubuntu und Red Hat bauen Sicherheitskorrekturen oft in ihre bestehenden Pakete ein, ohne auf die Versionsnummer von php.net zu springen, ein gepatchter Server zeigt dann womöglich eine ältere Nummer. Maßgeblich ist hier die Paketversion, die der Sicherheitshinweis Ihrer Distribution zu CVE-2026-109618 nennt.

Bei Shared Hosting und im Hosting-Panel

Im Kundenbereich Ihres Hosters stellen Sie die PHP-Version meist pro Domain ein, bei Plesk im Bereich PHP der jeweiligen Domain. Dort sehen Sie oft nur den Zweig, etwa „8.4“, aber nicht die genaue Patch-Version. Die liefert dann wieder phpinfo. Das PHP selbst aktualisieren können Sie bei Shared Hosting nicht, das muss der Hoster tun.

Wie spiele ich das PHP-Update ein?

Bei Shared Hosting ist Ihre Aufgabe kurz: Fragen Sie beim Hoster nach, ob die gepatchten Versionen installiert sind, und lassen Sie sich das am besten schriftlich bestätigen. Steht Ihre Domain noch auf einem alten Zweig wie 7.4 oder 8.1, stellen Sie im Panel auf 8.4 oder 8.5 um und testen danach Ihre Seite. Ältere Plugins und Themes vertragen den Sprung nicht immer.

Auf einem eigenen Server oder vServer gehen Sie so vor:

1. Verschaffen Sie sich einen Überblick, welche PHP-Versionen installiert sind und welche Websites sie nutzen. Unter Debian und Ubuntu zeigt dpkg -l 'php*' die installierten Pakete.
2. Spielen Sie die Updates ein, unter Debian und Ubuntu mit apt update && apt upgrade, unter Plesk zusätzlich über die Plesk-Updates. Bei Docker ziehen Sie neue Images und bauen die Container neu.
3. Starten Sie PHP neu. Ein installiertes Paket wirkt erst, wenn die laufenden Prozesse ersetzt sind: systemctl restart php8.4-fpm für FPM, bei mod_php der Apache selbst.
4. Kontrollieren Sie die Version noch einmal aus Sicht des Webservers, also per phpinfo oder in der Anwendung, und gleichen Sie sie mit der Tabelle oben oder dem Hinweis Ihrer Distribution ab.
5. Sehen Sie in die Logs zurück bis zum 17. Oktober (dazu weiter unten mehr).

Internetfähige Systeme kommen zuerst dran, interne danach. Denken Sie auch an Geräte, in denen PHP steckt, ohne dass es draufsteht. Das BSI weist darauf hin, dass Hersteller von Netzwerkkomponenten inzwischen eigene Sicherheitshinweise veröffentlichen, weil sie PHP in ihre Produkte eingebaut haben.

Was hilft, wenn das Update nicht sofort möglich ist?

Das PHP-Projekt nennt einige Konfigurationsänderungen, sagt aber deutlich, dass sie nur einzelne Angriffswege verbauen. Als Überbrückung für ein, zwei Tage taugen sie.

Gegen CVE-2026-109618 empfiehlt das Projekt memory_limit=-1, und zwar so, dass Anwendungen den Wert nicht überschreiben können, etwa per php_admin_value im FPM-Pool oder in der Apache-Konfiguration. Das klingt paradox, nimmt dem Angreifer aber das gezielte Auslösen des Speicherfehlers. Dafür darf ein einzelner Prozess beliebig viel Speicher belegen. Begrenzen sollten Sie das über ein Container- oder cgroup-Limit, nicht über RLIMIT_AS oder RLIMIT_DATA, denn genau die können den verwundbaren Pfad auslösen. Dazu kommt ein niedriges post_max_size: 8 MB für Anwendungen ohne Datei-Uploads, 32 MB, wenn Uploads gebraucht werden.

Gegen CVE-2026-109619 hilft das Abschalten des Upload-Fortschritts in Sessions. Unter PHP 8.5 kommt eine zweite Einstellung dazu:

; php.ini oder FPM-Pool, danach alle Worker neu starten
session.upload_progress.enabled = 0
post_max_size = 8M          ; 32M, falls Uploads nötig sind
fatal_error_backtraces = 0  ; nur PHP 8.5

; im FPM-Pool, damit die Anwendung es nicht zurücksetzt
php_admin_value[memory_limit] = -1

Über ini_set() oder eine .user.ini gesetzt, wirken die Werte zu spät. Testen Sie danach die Uploads in Ihrer Anwendung, gerade bei einer Nextcloud, deren Kernaufgabe das Hochladen von Dateien ist.

Cloudflare hat nach Angaben von Help Net Security für alle Kunden, auch im kostenlosen Tarif, erste WAF-Regeln ausgerollt. Amazon schlägt vor, Multipart-Uploads vorübergehend zu blockieren, wo die Anwendung sie nicht braucht. Wenn nichts davon geht, bleibt der Rat des NCSC: das System offline nehmen, bis es gepatcht ist.

Woran erkenne ich, ob mein Server angegriffen wurde?

Ein Patch schließt die Lücke, entfernt aber keinen Angreifer, der schon drin ist. Amazon empfiehlt in seiner Analyse, die Suche beim 17. Oktober zu beginnen, dem Tag des ersten bekannten Versuchs. Weil der Angriff unterhalb der Anwendung stattfindet, zeigen Anwendungslogs laut Recorded Future wenig. Webserver- und Systemlogs sind ergiebiger.

Amazon nennt als konkretes Merkmal POST-Anfragen mit Datei-Uploads, die den String PHP_SESSION_UPLOAD_PROGRESS enthalten. Den sehen Sie allerdings nur, wenn eine WAF oder ein Reverse Proxy Request-Bodies protokolliert, in normalen Access-Logs steht er nicht. Dort achten Sie eher auf gehäufte Multipart-POSTs von einzelnen IP-Adressen. In den PHP- und FPM-Fehlerlogs sind viele „Allowed memory size exhausted“-Meldungen in kurzer Zeit oder abgestürzte Worker verdächtig, denn CVE-2026-109618 setzt genau am Speicherfehler an. Auf Systemebene suchen Sie nach PHP-Dateien, die seit dem 17. Oktober neu sind oder sich geändert haben, etwa mit find /var/www -name '*.php' -newermt 2026-10-17, und nach Prozessen wie Shells, curl oder wget, die der Webserver-Benutzer gestartet hat.

Ein einzelner Treffer beweist noch keinen Einbruch, schließlich haben Sie selbst vielleicht Plugins aktualisiert. Erhärtet sich der Verdacht, tauschen Sie alle Zugangsdaten aus, die der Server kannte, vom Datenbankpasswort bis zu den API-Schlüsseln in der Konfiguration. Wegen der möglichen Speicherauslesung gilt das auch, wenn sich keine Hintertür findet. Einen Verdacht auf Kompromittierung können Sie dem BSI melden.

Der Webserver von acona-softwares.de läuft bereits auf PHP 8.5.12. Wenn wir Ihre Nextcloud als Managed Nextcloud auf unseren Servern in Deutschland betreiben, spielen wir Updates und Sicherheits-Patches selbst ein und kümmern uns um die Backups. Hängt bei Ihnen eine ältere PHP-Anwendung fest, die sich nicht einfach aktualisieren lässt, sprechen wir im kostenlosen 20-minütigen Erstgespräch darüber, ob sich eine Modernisierung der Webanwendung lohnt.

Häufige Fragen

Quellen

1. PHP-Projekt: Security advisory – Critical remote code execution vulnerabilities, update now (21.10.2026)
2. GitHub Security Advisory GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
3. GitHub Security Advisory GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
4. BSI: PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit
5. Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure in MadPot
6. SecurityWeek: PHP2Shell Exploitation Moves From Probes to Working Shells