PHP2Shell-Check: Ist deine Website von der PHP-Lücke betroffen?

Gib die Adresse deiner Website ein. Wir lesen aus, welche PHP-Version dein Server nach außen meldet, und vergleichen sie mit den Ständen, die die Lücke „php2shell“ schließen. Eine einzige Abfrage wie von einem Browser – ohne Anmeldung und ohne Angriff.

Was ist php2shell?

„php2shell“ ist der Name für zwei kritische Lücken im Kern von PHP, die am 21. Oktober 2026 veröffentlicht wurden: CVE-2026-109618 und CVE-2026-109619, beide mit der Höchstwertung 9,2 (CVSS 4.0). Nach Angaben der PHP-Entwickler lässt sich damit ohne Anmeldung über gewöhnliche Webanfragen Code auf dem Server ausführen, mit den Rechten des PHP-Prozesses.

Am leichtesten geht das bei Apache mit mod_php: Dort haben die Entwickler einen vollständigen Angriff gegen die Standardeinstellungen nachgewiesen. Bei PHP-FPM sind die Fehler nach ihrer Aussage ebenfalls erreichbar, einen vollständigen Angriff haben sie dort bisher nicht gezeigt. Laut einer Auswertung von Brandefense berichten mehrere Sicherheitsfirmen von Angriffsversuchen; wie belastbar die einzelnen Berichte sind, ist unterschiedlich (Stand: 26. Oktober 2026). Nimm die Lücke deshalb ernst, aber ohne Panik: Das Update schließt sie.

Welche PHP-Version brauchst du mindestens?

Betroffen sind laut der Schwachstellendatenbank NVD PHP-Versionen ab 5.4 (CVE-2026-109619) beziehungsweise ab 7.3 (CVE-2026-109618) bis unterhalb dieser Stände.

Was der Check kann – und was nicht

• Er sieht nur, was dein Server nach außen meldet: die PHP-Version in den Kopfzeilen der Startseite (X-Powered-By oder Server).
• Nennt dein Server die Version nicht (das ist die Regel und grundsätzlich gut), zeigen wir dir nur, woran wir PHP erkennen. Ob die Korrektur eingespielt ist, sehen wir dann nicht. „Nicht sichtbar“ heißt nicht „sicher“.
• Debian, Ubuntu, Red Hat und Co. liefern Korrekturen oft in Paketen mit alter Versionsnummer. Bei solchen Servern kann die gemeldete Version unter dem Stand liegen und die Korrektur trotzdem enthalten – du erkennst es am Changelog (Befehle unten).
• Wir prüfen nur die Startseite. Andere Domains auf demselben Server, andere PHP-Versionen je Domain (zum Beispiel bei Plesk) oder ein Proxy davor sehen wir nicht.

So prüfst du es selbst

Zählt die PHP-Version des Webservers – nicht die der Kommandozeile: php -v zeigt oft eine andere.

1. Version ermitteln: bei PHP-FPM mit php-fpm -v, sonst in der Verwaltung deines Hosters. Bei Plesk unter Websites & Domains → PHP-Einstellungen, bei WordPress unter Werkzeuge → Website-Zustand → Info → Server.
2. Sie muss mindestens 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 sein.
3. Liegt sie darunter, nutzt du aber Pakete deiner Linux-Distribution, nennt deren Changelog die Korrektur, sobald sie eingespielt ist. Bei Debian und Ubuntu:

   zgrep -l CVE-2026-109618 /usr/share/doc/php*/changelog.Debian.gz

   Bei Red Hat, Alma und Rocky:

   rpm -q --changelog php-common | grep CVE-2026-109618

   Gibt der Befehl eine Fundstelle aus, enthält das Paket die Korrektur.
4. Im Zweifel frag deinen Hoster, ob das Sicherheitsupdate vom 21. Oktober 2026 eingespielt ist.

Das sagen die PHP-Entwickler

Das Update ist nach den Sicherheitsmeldungen der PHP-Entwickler die einzige vollständige Lösung. Bis du es einspielen kannst, nennen sie diese Zwischenmaßnahmen – jede für sich verringert das Risiko nur:

• session.upload_progress.enabled=0 in der php.ini schaltet einen der betroffenen Wege ab (CVE-2026-109619).
• Bei PHP 8.5: fatal_error_backtraces=0 (CVE-2026-109619).
• Upload- und POST-Größen sowie die Zahl der Teile je Anfrage begrenzen und mehrteilige Anfragen (multipart) vorgelagert abweisen, wenn du sie nicht brauchst (CVE-2026-109618).
• Nach jeder Änderung die PHP-Prozesse neu starten.

Weitere Einzelheiten stehen in den beiden Meldungen der PHP-Entwickler (Links unter „Quellen“).

Häufige Fragen

Mein Hoster sagt, er kümmert sich darum. Reicht das?

Dann ist die Frage, wann. Frag nach dem Stand: Auf welche PHP-Version ist dein Server aktualisiert, und enthält sie die Korrektur gegen CVE-2026-109618 und CVE-2026-109619? Der Check oben zeigt dir, was von außen sichtbar ist; die Befehle unter „So prüfst du es selbst“ klären den Rest.

Mein Server nennt die PHP-Version nicht. Bin ich dann sicher?

Nein, das lässt sich so nicht sagen. Eine versteckte Version ist eine gute Gewohnheit, aber sie verrät nicht, ob das Update eingespielt ist. In einer öffentlichen Auswertung von Brandefense (21. bis 25. Oktober 2026, keine Zufallsstichprobe) nannten nur 3.532 von 12.943 PHP-Seiten ihre Version; bei 59 Prozent von ihnen war sie älter als der Stand der Korrektur.

Betrifft php2shell auch WordPress?

Ja, wenn die Seite auf einem betroffenen PHP läuft: WordPress ist ein PHP-Programm, und die Lücke steckt in PHP selbst. Ein WordPress-Update ersetzt das PHP-Update nicht.

Sind Seiten mit Node.js, Python oder ohne Programmcode betroffen?

Nein. Die Lücken stecken in PHP; Anwendungen auf Node.js oder Python und rein statische Seiten sind davon nicht betroffen. Läuft auf demselben Server aber irgendwo PHP (Kontaktformular, Verwaltungsprogramm), gilt es für dieses PHP.

Speichert ihr meine Adresse?

Nicht dauerhaft. Das Ergebnis liegt höchstens zwei Minuten im Arbeitsspeicher, damit eine Wiederholung nicht gleich noch einmal bei deinem Server anklopft. Deine IP-Adresse wird nur gezählt (höchstens 20 Prüfungen pro Stunde), um den Dienst vor Überlastung zu schützen.

Quellen

• PHP-Entwickler: Sicherheitsmeldung GHSA-w8hw-w9fx-j79w (CVE-2026-109618) und GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), beide vom 21. Oktober 2026
• Schwachstellendatenbank NVD: CVE-2026-109618 und CVE-2026-109619
• PHP-Projekt: Änderungsliste der PHP-8-Versionen
• Plesk: Hinweis zu CVE-2026-109618 und CVE-2026-109619 (englisch)
• Brandefense: Auswertung eines öffentlichen PHP2Shell-Checks vom 21. bis 25. Oktober 2026 (englisch)

Stand der Angaben: 26. Oktober 2026.