php2shell: kritische PHP-Sicherheitslücke (CVE-2026-109618, CVE-2026-109619) und was jetzt zu tun ist

Prüfen Sie nur Systeme, die Ihnen gehören oder für die Sie verantwortlich sind. Diese Seite und unser Versions-Check arbeiten ausschließlich mit Versionsnummern, die Sie selbst eingeben; die Auswertung läuft direkt in Ihrem Browser. Nichts hier testet, scannt oder sondiert einen Server. Unabhängige Website, nicht mit der PHP Group oder php.net verbunden.

Kurzantwort

„php2shell“ ist der Spitzname, den Wiz Research zwei kritischen PHP-Sicherheitslücken gegeben hat: CVE-2026-109618 und CVE-2026-109619. Die PHP Group bewertet beide mit CVSS v4.0 9,2 (kritisch) und schreibt, dass sie unauthentifizierte Remote-Code-Ausführung ermöglichen können. Das heißt: Ein Fremder aus dem Internet kann unter Umständen Code auf Ihrem Server ausführen, ohne sich anzumelden.

Betroffen ist jeder Server, der PHP für Webanfragen nutzt. Gepatcht sind PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 (jeweils oder neuer). Wer auf einer älteren Version derselben Zweige oder auf PHP 8.1, 8.0 oder 7.4 läuft, muss handeln. Die PHP Group schreibt in ihren Meldungen auf php.net: „There are no complete mitigations, updating is the only safe choice.“ Sinngemäß: Es gibt keine vollständigen Gegenmaßnahmen; nur ein Update ist eine vollständige Lösung.

Nutzen Sie Webhosting, bei dem Sie PHP nur im Kundenmenü umstellen können, gilt: Status Ihres Anbieters lesen (siehe Hoster-Übersicht), PHP-Version nachsehen, im Zweifel beim Support nachfragen. Betreiben Sie einen eigenen Server (vServer, Root-Server, Cloud), folgen Sie den 3 Schritten.

Was ist php2shell?

• Zwei Lücken, ein Update. CVE-2026-109618 heißt in den Hinweisen der PHP Group „RCE via OOM corruption“, CVE-2026-109619 „RCE via stale global state“ (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp). RCE steht für Remote Code Execution, also Code-Ausführung aus der Ferne. Beide Lücken werden mit denselben PHP-Versionen geschlossen. Wie sie technisch funktionieren, beschreiben wir bewusst nicht; für das Patchen brauchen Sie das nicht.
• Schweregrad. Beide Lücken: CVSS v4.0, Wert 9,2, Stufe „Critical“, vergeben von der PHP Group selbst. Die US-Datenbank NVD hat bei beiden CVEs inzwischen eine eigene Bewertung ergänzt: CVSS v3.1, bei CVE-2026-109618 Wert 9,8 (kritisch), Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, bei CVE-2026-109619 seit dem 22. Oktober Wert 8,1 (hoch), Vektor CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (zuvor 9,8); die Bewertung der PHP Group (CVSS 4.0, 9,2) bleibt als sekundäre Angabe stehen.
• Woher der Name kommt. „php2shell“ steht weder in der php.net-Meldung noch in den CVE-Einträgen. Den Namen hat Wiz Research in einem Blogbeitrag geprägt, auf den auch die NVD verweist. Andere Stellen wie CERT-EU/NCSC-NL und das CSIRTs-Netzwerk der ENISA nutzen ihn ebenfalls. Wundern Sie sich also nicht, wenn Hoster oder Medien nur von „PHP-Sicherheitslücke“ oder „PHP-Schwachstelle“ sprechen: Gemeint ist dasselbe.
• Wird es schon ausgenutzt? Die Aussagen gehen auseinander, deshalb nach Quelle (nicht alle Quellen sprechen von Angriffen): Die PHP Group hält das Risiko für mod_php am höchsten und spricht von einem gezeigten Exploit. CERT-EU schreibt, erste Proofs of Concept (Machbarkeitsnachweise) seien im Umlauf, was die Wahrscheinlichkeit von Angriffen erhöhe (CERT-EU 2026-018). Die japanische IPA (Vorabmeldung, vor Veröffentlichung der Updates) schreibt, sie habe bislang keine Angriffe bestätigt, die diese beiden Lücken ausnutzen. Eine Folgemeldung der IPA vom 22. Oktober (Hinweis) nennt die Fixversionen und enthält keine Aussage, dass Angriffe beobachtet wurden. Das kanadische Cyber Centre (AL26-026) hat nach eigenen Angaben aus offenen Quellen von einem verfügbaren Proof of Concept erfahren, aber keine aktive Ausnutzung festgestellt, „but that can change quickly“. Die PHP Foundation nennt in einem Blogbeitrag vom 21. Oktober eine zunehmende Verbreitung von PoCs am 21. Oktober; das PHP-Sicherheitsteam habe zum Zeitpunkt der Veröffentlichung keine funktionsfähigen Exploits gefunden. Die CISA-Bewertung (SSVC, in der NVD hinterlegt, 21. Oktober 14:34 UTC) führt bei beiden CVEs „exploitation: none“. Im KEV-Katalog der US-Behörde CISA (bekannte ausgenutzte Lücken) waren die CVEs nicht gelistet; bei unserer letzten Prüfung am 22. Oktober (gegen 12:36 UTC) war weiterhin der Katalog 2026.10.21 (freigegeben am 21. Oktober um 14:04 UTC) der aktuelle, und er führte keine der beiden CVEs. Prüfen Sie den aktuellen Stand selbst und behandeln Sie die Sache in jedem Fall als dringend.

Was sagt das BSI / CERT-Bund?

Das BSI führt die Lücken im CERT-Bund-Portal unter WID-SEC-2026-4055 (Titel inzwischen „PHP: Mehrere Schwachstellen ermöglichen Codeausführung“, zuerst „… ermöglichen nicht spezifizierten Angriff“), eingestuft als kritisch, erstmals am 21. Oktober 2026 geführt und am 22. Oktober 2026 um 11:15 UTC aktualisiert. Die Meldung nennt beide CVE-Nummern. Das Portal lädt seine Inhalte per JavaScript; wir haben Titel, Datum und CVE-Nummern über die öffentliche WID-Liste bestätigt, nicht den Volltext der Seite. Der Eintrag erschien erstmals vor der Veröffentlichung der Updates (11:40 UTC, die Fixes kamen um 13:30 UTC). Konkrete Handlungsschritte finden Sie bei der PHP Group und bei Ihrem Hoster bzw. Ihrer Distribution.

Weitere Stellen mit deutschsprachigen Hinweisen:

• Österreich: Die ENISA-Liste verweist auf eine Meldung von CERT.at; den Inhalt dieser Seite haben wir nicht geprüft.
• EU: CERT-EU 2026-018 „Critical Vulnerabilities in PHP“ (englisch). Nennt als Veröffentlichung der Fixes den 21. Oktober 2026, 13:30 UTC.
• Schweiz: Infomaniak als Schweizer Hoster steht in der Tabelle unten. Zu Schweizer Behörden haben wir keine Quelle geprüft.

Bin ich betroffen? Wer jetzt handeln muss

Die PHP Group nennt „alle PHP-Installationen, die Webanfragen bedienen, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed“. Maßgeblich ist die PHP-Version auf dem Server, nicht die Version Ihrer Anwendung. WordPress, Shopware, TYPO3, Nextcloud, Laravel oder ein selbstgeschriebenes Skript: Alles, was über PHP ausgeliefert wird, hängt an dieser einen Zahl.

Betroffene und gepatchte PHP-Versionen

Quellen: php.net-Hinweis und Supported Versions. Die Angaben der PHP Group (CNA-Eintrag und GitHub-Advisory) führen 8.2.* bis 8.5.* unterhalb dieser Versionen als betroffen. Die CPE-Konfiguration der NVD geht weiter: Sie nennt jede PHP-Version unter 8.2.35 (ohne Untergrenze, also auch 8.1 und älter) sowie 8.3.0 bis unter 8.3.36, 8.4.0 bis unter 8.4.27 und 8.5.0 bis unter 8.5.12. Das Datum der Veröffentlichung ist der 21. Oktober 2026 (php.net-Release-Liste und CERT-EU); die ChangeLog-Seite von php.net zeigt „22 Oct 2026“. Die vollständige Tabelle mit Distributionspaketen finden Sie unter Gepatchte Versionen.

Hinweis zu PHP 8.2: Dieser Zweig bekommt nur noch bis zum 31. Dezember 2026 Sicherheitsupdates. Für neue Umstellungen ist 8.3 oder höher sinnvoller. PHP 8.6 ist noch nicht erschienen (laut php.net aktuell Release Candidate, „DO NOT use this version in production“) und gilt daher nicht als Ausweg.

Linux-Pakete behalten alte Nummern

Debian, Ubuntu und Co. übernehmen Korrekturen meist per Backport in ihre bestehende Version. Deshalb sieht ein gepatchtes Paket „alt“ aus. Vergleichen Sie mit der gepatchten Paketversion Ihrer Distribution, nicht mit der PHP-Nummer von php.net. Beispiele aus unseren geprüften Daten:

• Ubuntu 24.04 LTS: php8.3 8.3.6-0ubuntu0.24.04.13; Ubuntu 22.04 LTS: php8.1 8.1.2-1ubuntu2.28 (Ubuntu CVE-Seite).
• Debian 13 (trixie): php8.4 8.4.27-1~deb13u1 (DSA-6574-1). Debian 12 (bookworm): php8.2 8.2.35-1~deb12u1 (DLA-4848-1).
• Red Hat Enterprise Linux: Red Hat hat korrigierte Pakete veröffentlicht. RHEL 10: php (PHP 8.3) 8.3.36-1.el10_2 (RHSA-2026:87070) und php8.4 8.4.27-1.el10_2 (RHSA-2026:87071). RHEL 9: php (PHP 8.0) 8.0.30-8.el9_8.1, Modul php:8.2 8.2.35-1.module+el9.8.0+25111+a1450321, Modul php:8.3 8.3.36-1.module+el9.8.0+25109+6886e21a; für php:8.4 führt Red Hat noch „Affected“ (betroffen) ohne Advisory. RHEL 8: Modul php:7.4 7.4.33-8.module+el8.10.0+25117+30337cca und Modul php:8.2 8.2.35-1.module+el8.10.0+25110+f67151d2. Quelle: Red-Hat-CVE-Seite.
• Rocky Linux und Oracle Linux haben eigene Advisories mit denselben Upstream-Versionen (Rocky 10, 9 und 8, Oracle 10, 9 und 8; Beispiel Rocky 10: php8.4 8.4.27-1.el10_2, RLSA-2026:87071). Rocky 8: Modul php:8.2 8.2.35-1.module+el8.10.0+40394+d21b33fb (RLSA-2026:87073). Oracle Linux 9: Modul php:8.2 8.2.35-1.module+el9.8.0+91079+4ad1bd7f (ELSA-2026-87072) und Modul php:8.3 8.3.36-1.module+el9.8.0+91082+c865dc1a (ELSA-2026-87079). Oracle Linux 8: Modul php:7.4 7.4.33-8.module+el8.10.0+91080+9785160d (ELSA-2026-87080) und Modul php:8.2 8.2.35-1.module+el8.10.0+91081+33b5c645 (ELSA-2026-87073). Für Rocky 9 php:8.4, andere Rocky-8-Streams und andere Oracle-Linux-8-Streams haben wir noch keinen Advisory gefunden. AlmaLinux hat Advisories veröffentlicht: AlmaLinux 10 php (8.3) 8.3.36-1.el10_2 (ALSA-2026:87070) und php8.4 8.4.27-1.el10_2 (ALSA-2026:87071), AlmaLinux 9 php:8.3 8.3.36-1.module_el9.8.0+330+fdc30075 (ALSA-2026:87079) und AlmaLinux 8 php:7.4 7.4.33-8.module_el8.10.0+4321+cf5fd4bb (ALSA-2026:87080). Für andere Builds (auf AlmaLinux 9 auch php:8.2, dessen Advisory nur php-pecl-Pakete auflistet) haben wir keine Bestätigung (Errata); „keine Bestätigung“ heißt aber nicht, dass das Paket verwundbar ist oder nicht.
• Amazon Linux 2023: php8.2 8.2.35-1.amzn2023.0.1, php8.3 8.3.36-1.amzn2023.0.1, php8.4 8.4.27-1.amzn2023.0.1, php8.5 8.5.12-1.amzn2023.0.1 (ALAS2023-2026-3301 bis 3304); php8.1 steht bei Amazon auf „No Fix Planned“ (keine Korrektur geplant). Amazon Linux 2: der PHP-8.2-Extras-Stream ist mit 8.2.35-1.amzn2.0.1 behoben (ALAS2PHP8.2-2026-015), das php-Paket im Core-Repository steht auf „No Fix Planned“ (keine Korrektur geplant) (Amazon CVE-Seite).
• Alpine 3.24 und edge: php83 8.3.36-r0, php84 8.4.27-r0, php85 8.5.12-r0. Bei Alpine 3.24 stehen diese Versionen laut Prüfung auf allen Architekturen; bei edge ist die Version im x86_64-Index als behoben geführt, aber nicht jede Architektur war aktualisiert: Bei unserer Prüfung (22.10., gegen 03:55 UTC) führten x86, ppc64le, s390x und riscv64 noch 8.3.35-r0, 8.4.26-r0 bzw. 8.5.11-r0. Führen Sie apk upgrade aus und prüfen Sie die installierte Version. Alpine 3.23, 3.22 und 3.21: Alpine führt hier für php83 8.3.36-r0, php84 8.4.27-r0 und php85 8.5.12-r0 (3.23), php82 8.2.35-r0, php83 8.3.36-r0 und php84 8.4.27-r0 (3.22) sowie php82 8.2.35-r0 (3.21) behobene Pakete, obwohl der Community-Zweig dieser Releases laut Alpine bereits ausgelaufen ist. Für php83 und php84 unter 3.21 erwartet Alpine kein Sicherheitsupdate. Debian sid hat 8.4.27-1; Debian forky liefert noch 8.4.26-1, das der Debian-Tracker als verwundbar führt.

Die vollständige Liste mit Paketnamen, Streams und Quellen finden Sie unter Gepatchte Versionen.

Das Remi-RPM-Repository (rpms.remirepo.net) wird ehrenamtlich gepflegt. Die PHP Group schrieb am Veröffentlichungstag, das Repository werde an diesem Tag keine Updates haben, und riet dazu, auf Distributionspakete umzusteigen oder aus dem Quelltext zu bauen. Inzwischen enthält Remis Repository für Enterprise Linux 8, 9 und 10 Builds von PHP 8.2.35 bis 8.5.12 mit Datum 21. Oktober, zum Beispiel 8.3.36-1.el9.remi; Remi nennt die CVEs allerdings nicht.

Veraltete PHP-Zweige (8.1, 8.0, 7.4)

Laut php.net erhalten PHP 8.1 und älter keine Updates mehr vom PHP-Projekt. Für 7.4, 8.0 und 8.1 hat das Sicherheitsteam lediglich minimale Backports im Quelltext bereitgestellt, für Leute, die selbst kompilieren oder keinen LTS-Anbieter haben. Es gibt dafür weder ein Release-Archiv noch eine Versionsnummer. Für 7.3 und älter kündigt php.net nichts an. Das französische CERT-FR führt alle Versionen 5.x, 6.x, 7.x, 8.0.x und 8.1.x als betroffen (CERTFR-2026-ALE-014).

Die eigentliche Lösung: auf einen unterstützten Zweig wechseln (8.3 oder höher). Wenn das nicht sofort geht, fragen Sie Ihren Hoster oder Ihre Distribution nach einem Paket mit Backport oder nach erweitertem Support. Beispiele: Red Hat liefert für RHEL 8 (php:7.4) und RHEL 9 (php 8.0) korrigierte Pakete, Ubuntu 22.04 LTS für php8.1 8.1.2-1ubuntu2.28. Für Debian 11 (bullseye) hat Debian selbst keinen php7.4-Eintrag (LTS endete am 31. August 2026); Freexians kostenpflichtiges Extended LTS nennt 7.4.33-1+deb11u14 (ELA-1853-1), geliefert nur über das private Repository für Abonnenten. Bei Plesk unter Linux behalten 7.4.33, 8.0.30 und 8.1.34 ihre Nummern, die am 21.10.2026 gebauten Versionen enthalten laut Plesk die Fixes, die Nummer verrät das also nicht. Die von php.net genannten Zwischenmaßnahmen (Konfigurationsgrenzen) verringern laut php.net nur die Angriffsfläche und ersetzen das Update nicht. Nutzen Sie sie höchstens als Notbehelf.

Die 3 Schritte: prüfen, aktualisieren, kontrollieren

Legen Sie vorher ein Backup oder einen Snapshot an. Das ist besonders wichtig, wenn Sie auf einen neuen PHP-Zweig wechseln (etwa von 8.1 auf 8.3) statt nur ein Patch-Update innerhalb des Zweigs einzuspielen.

Schritt 1: Version prüfen

Mit SSH-Zugang (vServer, Root-Server):

php -v                                  # PHP in der Konsole, kann vom Web-PHP abweichen
ls /usr/sbin/php-fpm* 2>/dev/null       # FPM-Binaries, dann z. B. php-fpm8.3 -v
dpkg -l | grep -E '^ii +php'            # Debian / Ubuntu
rpm -qa | grep -i '^php'                # RHEL, AlmaLinux, Rocky

Der Webserver kann ein anderes PHP nutzen als die Konsole. Entscheidend ist das PHP, das Ihre Website ausliefert.

Ohne SSH (Webhosting, WordPress): In WordPress zeigt Werkzeuge → Website-Zustand → Info → Server die PHP-Version der Website. Weitere Wege, auch fürs Kundenmenü des Hosters: PHP-Version prüfen. Tragen Sie die Zahl dann in den Versions-Check ein und vergleichen Sie sie mit den gepatchten Versionen. Bei Distributionspaketen zählt die Paketversion Ihrer Distribution.

Schritt 2: Aktualisieren

Debian / Ubuntu (8.3 durch Ihren Zweig ersetzen):

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade 'php8.3*'

RHEL-Familie (bei RHEL, Rocky, Oracle und AlmaLinux gibt es korrigierte Pakete für einen Teil der Streams, für andere Streams wie php:8.4 unter RHEL 9 bisher nicht; die Paketversion danach mit der Tabelle unter Gepatchte Versionen vergleichen):

sudo dnf check-update 'php*'
sudo dnf upgrade 'php*'

Docker: Image mit aktuellem Basisimage neu bauen, Container neu erstellen. Die offiziellen php-Images für 8.2 bis 8.5 enthalten bei unserer Registry-Abfrage (21.10., 17:11 UTC) die gepatchten Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12; für 8.1 und älter gibt es kein offizielles korrigiertes Image. Prüfen Sie das Ergebnis nach dem Pull mit php -v.

docker build --pull --no-cache -t myapp:patched .
docker compose up -d --force-recreate

Webhosting mit Kundenmenü: Suchen Sie im Kundenmenü die Einstellung für die PHP-Version (die Bezeichnung unterscheidet sich je Anbieter). Eine neuere Auswahl wie „8.3“ bedeutet nicht automatisch, dass der Hoster die gepatchte Unterversion 8.3.36 installiert hat. Ob die Korrektur schon aktiv ist, steht in der Mitteilung des Hosters; die laufende Version sehen Sie wie in Schritt 1 beschrieben. Auf WordPress-Seiten testen Sie nach dem Wechsel Plugins und Theme, siehe WordPress und php2shell.

Selbst gebaut oder Drittanbieter-Repository: Nehmen Sie 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 von den php.net-Downloads.

Schritt 3: Neu starten und kontrollieren

Ein Update wirkt erst, wenn der laufende PHP-Prozess neu gestartet wurde.

sudo systemctl restart php8.3-fpm       # Ihr FPM-Dienst; unter RHEL: php-fpm
sudo systemctl restart apache2          # nur bei mod_php (RHEL: httpd)
php -v
dpkg -l | grep -E '^ii +php8.3'         # Paketversion mit der Ihrer Distribution vergleichen

Kontrollieren Sie dann drei Dinge: Die installierte Version entspricht der gepatchten Version Ihres Anbieters, der Dienst läuft ohne Fehler (systemctl status php8.3-fpm) und Ihre Website lädt. Bei Containern: docker exec <container> php -v im neuen Container. Zum Schluss die Version erneut im Versions-Check eingeben.

Was sagen IONOS, Hetzner, netcup und Co.?

Stand 22. Oktober 2026, nach den eigenen Statusseiten der Anbieter. Hoster aktualisieren diese Seiten laufend, öffnen Sie deshalb den Link, bevor Sie sich auf etwas verlassen. „Wird ausgerollt“ oder „Schutzmaßnahme“ heißt nicht, dass Ihr Tarif schon auf einer gepatchten PHP-Version läuft.

Weitere Anbieter und Details finden Sie unter Hoster-Status, eine Einordnung nach Hostingart in der Hosting-Anleitung. Kunden von Webhostern haben oft nur das Kundenmenü zur Verfügung: Dort lässt sich meist die PHP-Version wählen, aber selten sehen Sie, ob die Unterversion schon gepatcht ist. Fragen Sie bei Unklarheit schriftlich nach der konkret installierten Version.

Verlassen Sie sich nicht auf Plugins oder eine Firewall

Sicherheits-Plugins und Web Application Firewalls (Filter vor Ihrer Website) können eine zusätzliche Schicht sein, ersetzen aber das PHP-Update nicht. Die PHP Group sagt klar, dass es keine vollständige Notlösung gibt. Cloudflare (Blog) und Sucuri (Statusmeldung) betonen ausdrücklich, dass ihre Filterregeln das PHP-Update nicht ersetzen. Und: WordPress-Autoupdates beheben diese Lücken nicht, weil sie in PHP liegen, nicht in WordPress (laut Wordfence nach der Veröffentlichung der Updates). In einem Folgebeitrag vom 22. Oktober (Wordfence) schreibt Wordfence: „For these vulnerabilities, updating and restarting PHP is essential.“

Wie geht es weiter?

• Versions-Check: Ihre PHP-Version eintippen und mit dem Fix vergleichen.
• Gepatchte Versionen: alle Zweige und Distributionspakete.
• Hoster-Status: was die Anbieter sagen, mit Datum der Prüfung.
• PHP-Version prüfen: alle Wege, auch ohne SSH.
• WordPress und php2shell: Website-Zustand, Plugins, Hoster.
• Hosting-Anleitung: Webhosting, Managed Server und Root-Server im Vergleich.

Persönliche Hilfe bei Ihrem Setup

Wenn Sie die Schritte für Ihren Hoster und Ihre Anwendung nicht selbst herausfinden möchten: Wir bieten einen persönlichen Patch-Plan für 49 US-Dollar an. Sie erhalten schriftliche Schritte für genau Ihr Setup per E-Mail innerhalb von 24 Stunden. Wir melden uns nie auf Ihrem Server an: Sie führen die Schritte selbst aus. Nur für Websites, die Ihnen gehören oder für die Sie verantwortlich sind. Details unter Patch-Plan.