Zwei kritische Lücken in PHP erlauben Angreifern, ohne Anmeldung Code auf Webservern auszuführen. Geben Sie Ihre Webadresse ein. Wir zeigen Ihnen, ob die Website PHP verwendet und ob die erkennbare Version schon abgesichert ist.
Wir rufen nur die öffentliche Startseite ab, wie bei einem normalen Besuch im Browser. Es wird nichts angegriffen. Bitte prüfen Sie nur Websites, für die Sie verantwortlich sind.
PHP2Shell ist der Name für zwei kritische Sicherheitslücken im PHP-Interpreter selbst: CVE-2026-109618 und CVE-2026-109619. Beide erlauben es Angreifern, ohne Anmeldung eigenen Code auf dem Server auszuführen – mit den Rechten des Webserver-Kontos.
Weil die Lücken nicht in einer bestimmten Anwendung, sondern in PHP stecken, ist jede Website betroffen, die eine ungepatchte PHP-Version ausführt: WordPress, Joomla, Drupal, TYPO3, Shopware, Online-Shops, Foren und selbst entwickelte Anwendungen gleichermaßen. Updates der Anwendung helfen nicht – aktualisiert werden muss PHP.
Die Details wurden am 20. Oktober 2026 vor der geplanten, koordinierten Veröffentlichung bekannt. Das PHP-Projekt hat am 21. Oktober 2026 korrigierte Versionen veröffentlicht. Ausnutzungsversuche wurden bereits beobachtet. Die britische Cybersicherheitsbehörde NCSC rät, Systeme vom Netz zu nehmen, die sich nicht sofort aktualisieren lassen.
Speicherbeschädigung bei Speichermangel (Out-of-Memory)
Läuft PHP während einer Anfrage der Speicher aus, kann der Interpreter unterbrochen werden, während interne Anfragedaten erst teilweise initialisiert sind. Die anschließende Aufräumroutine behandelt diese ungültigen Daten als gültig. Angreifer können das ohne Anmeldung zur Ausführung von eigenem Code nutzen. Bei Apache mit mod_php lässt sich die Lücke auslösen, bevor überhaupt Anwendungscode läuft.
Veralteter globaler Zustand zwischen Anfragen
Interner Zustand, der zu einer Anfrage gehört, kann bestehen bleiben, nachdem sein Speicher bereits freigegeben wurde. Eine spätere Anfrage an denselben PHP-Worker kann diesen veralteten Zustand verwenden, bevor er regulär zurückgesetzt wird. Auch das ermöglicht Codeausführung ohne Anmeldung.
Betroffen sind alle PHP-Versionen vor den korrigierten Releases. Wie weit die Lücken in ältere Versionen zurückreichen, ist noch nicht abschließend bestätigt. Gehen Sie davon aus, dass jede ältere Version verwundbar ist.
| Versionszweig | Korrigiert ab | Hinweis |
|---|---|---|
| PHP 8.5 | 8.5.12 | Offiziell unterstützt |
| PHP 8.4 | 8.4.27 | Offiziell unterstützt |
| PHP 8.3 | 8.3.36 | Offiziell unterstützt |
| PHP 8.2 | 8.2.35 | Support endet am 31.12.2026 – Umstieg planen |
| PHP 8.1, 8.0, 7.4 | kein Release | Nur Quellcode-Backports; ohne LTS-Anbieter auf einen unterstützten Zweig wechseln |
| Ältere Versionen | keine Korrektur | Dringend aktualisieren |
Distributionen wie Debian, Ubuntu, RHEL oder AlmaLinux liefern Korrekturen oft als Backport aus – die angezeigte PHP-Versionsnummer bleibt dann alt, obwohl das Paket gepatcht ist. Maßgeblich ist der Sicherheitshinweis Ihrer Distribution.
Bei Shared Hosting und verwalteten Servern ist Ihr Hoster zuständig. Plesk meldet, dass alle mitgelieferten PHP-Versionen betroffen sind. Auch Geräte und Software mit eingebautem PHP (z. B. Firewalls, Appliances) können betroffen sein.
Installieren Sie PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. das korrigierte Paket Ihrer Distribution. Updates werden nicht automatisch eingespielt. Nutzen Sie Shared Hosting, fragen Sie Ihren Hoster, ob PHP bereits aktualisiert wurde.
Starten Sie PHP-FPM bzw. Apache nach dem Update neu, damit keine alten Worker weiterlaufen.
Prüfen Sie die laufende Version über eine echte Webanfrage – die Kommandozeile (php -v) kann eine andere Version zeigen als der Webserver.
Entfernen Sie eine dafür angelegte phpinfo()-Seite anschließend sofort wieder.
Nehmen Sie aus dem Internet erreichbare PHP-Anwendungen offline oder stellen Sie sie hinter eine Zugangskontrolle auf Netzwerkebene (z. B. VPN oder ZTNA).
Diese Einstellungen senken das Risiko, ersetzen aber kein Update:
memory_limit = -1 – Hinweis: Einzelne Anfragen können dann unbegrenzt Speicher belegen, Server überwachen.session.upload_progress.enabled = 0fatal_error_backtraces = 0file_uploads = Off und Anfragen mit multipart/form-data am Webserver oder in der WAF blockieren.Bei Apache mit mod_php kann die Lücke ausgelöst werden, bevor Anwendungscode läuft – Schutzmaßnahmen innerhalb der Anwendung greifen dort nicht. Cloudflare hat erste WAF-Regeln für bekannte Angriffsmuster bereitgestellt.
Da Ausnutzungsversuche schon vor der Veröffentlichung beobachtet wurden, sollten Sie Webserver-Logs ab dem 1. August 2026 auf Auffälligkeiten prüfen: unbekannte PHP-Dateien im Webverzeichnis, ungewöhnliche Prozesse des Webserver-Benutzers, neue Cronjobs oder unerwartete ausgehende Verbindungen.
Das PHP-Projekt erhält die ersten Meldungen zu den Schwachstellen.
Amazon Threat Intelligence registriert in einem Honeypot einen Ausnutzungsversuch – vier Tage vor der Veröffentlichung.
Details zu beiden Lücken gelangen vor der koordinierten Veröffentlichung an die Öffentlichkeit.
Das PHP-Projekt veröffentlicht PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie Quellcode-Backports für 7.4, 8.0 und 8.1.
Bis zu diesem Tag melden weitere Hersteller betroffene Produkte mit eingebautem PHP, darunter Plesk und Palo Alto Networks (PAN-OS).
Nein. PHP2Shell steckt im PHP-Interpreter, nicht in WordPress oder Plugins. Entscheidend ist, dass die PHP-Version auf dem Server aktualisiert wird.
Viele Server verbergen die PHP-Version – das ist gute Praxis. Die Version finden Sie im Kundenmenü Ihres Hosters, in Plesk oder cPanel
oder über eine kurzzeitig angelegte phpinfo()-Seite, die Sie danach sofort wieder löschen.
Nein, nicht automatisch. Wir prüfen nur die Startseite. Server, CDNs und Caches können PHP vollständig verbergen, und auf Unterseiten, Subdomains oder Verwaltungsoberflächen kann trotzdem PHP laufen. Fragen Sie im Zweifel Ihren Dienstleister.
Linux-Distributionen liefern Korrekturen oft als Backport aus, ohne die Versionsnummer zu erhöhen. Ebenso kann ein vorgeschalteter Proxy eine veraltete Angabe liefern. Prüfen Sie den Paketstand anhand des Sicherheitshinweises Ihrer Distribution.
Wir rufen die Startseite der angegebenen Adresse einmalig ab und werten HTTP-Header, Cookies und den HTML-Quelltext aus – etwa die Angabe
X-Powered-By, typische Pfade von WordPress oder Joomla und Meta-Angaben. Es werden keine Angriffe oder Exploits ausgeführt.
Sind Sie unsicher, wie Sie die PHP-Version auf Ihrem Server prüfen? Kontaktieren Sie uns, wir helfen Ihnen gern.
Kontakt aufnehmenStand der Informationen: 23. Oktober 2026.