PHP2Shell: Ist meine Website betroffen? Prüfen, beheben, absichern

Schnellcheck: Ist meine PHP-Version betroffen?

Tragen Sie die Versionsnummer ein, die Ihr Hosting oder WordPress anzeigt, zum Beispiel 8.3.36. Der Check vergleicht sie mit den korrigierten Versionen vom 21. Oktober 2026. Er läuft vollständig in Ihrem Browser; es wird nichts übertragen.

Worum es bei PHP2Shell geht

PHP2Shell ist der Name, unter dem zwei Fehler im PHP-Interpreter selbst geführt werden: CVE-2026-109618 und CVE-2026-109619, bewertet mit CVSS 9,2 von 10. PHP ist die Software, die auf dem Webserver WordPress, WooCommerce, Joomla, TYPO3, Shopware, Nextcloud und Laravel-Anwendungen ausführt. Die Fehler liegen also unter Ihrer Website, nicht in ihr. Bei einer passend gebauten Anfrage räumt PHP den Arbeitsspeicher nicht sauber auf, und eine spätere Anfrage im selben Prozess kann diesen Speicher nutzen, um eigene Befehle auszuführen. Dafür braucht der Angreifer kein Passwort und keine Mitwirkung von Ihnen.

Das PHP-Projekt hat die Korrekturen am 21. Oktober 2026 um 16 Uhr deutscher Zeit außerplanmäßig veröffentlicht, einen Tag früher als geplant, weil Einzelheiten vorher durchgesickert waren. Das Bundesamt für Sicherheit in der Informationstechnik warnte am selben Tag. Die Hintergründe, den Ablauf und die Reaktion von Hostern habe ich im Blogbeitrag PHP2Shell: Warum das WordPress-Update gegen die kritische PHP-Lücke nichts hilft beschrieben. Diese Seite hier ist die Werkbank dazu: prüfen, entscheiden, handeln.

Welche Versionen betroffen sind

Nach Angaben von Automattic und den Entdeckern reichen die Fehler bis PHP 5.4 zurück, also bis ins Jahr 2012. Praktisch heißt das: Jede PHP-Installation, die nicht ausdrücklich korrigiert wurde, ist betroffen. Korrigierte Versionen gibt es für die vier gepflegten Zweige:

Eine Besonderheit bei eigenen Servern mit Debian, Ubuntu oder Red Hat: Die Distributionen spielen die Korrektur in ihre bestehenden Pakete ein, ohne die PHP-Versionsnummer zu ändern. Ubuntu 22.04 zeigt nach dem Update weiter PHP 8.1.2, ist mit der Paketversion 8.1.2-1ubuntu2.28 aber geschützt; Debian 12 liefert 8.2.35-1~deb12u1, Red Hat 9 den Fix als php-8.0.30-8.el9_8.1. Dort zählt die Paketversion, nicht die Anzeige im Schnellcheck. Bei Shared Hosting und Managed WordPress ist das selten der Fall; da stimmt die Versionsnummer in der Regel.

Prüf-Skript: die laufende PHP-Version direkt vom Webspace lesen

Manche Hoster zeigen die Version nur als Zweig an („PHP 8.3“), manche gar nicht, und bei Agenturen oder Baukästen fehlt der Zugang zum Kundenmenü. Dann hilft eine kleine Datei, die Sie auf den Webspace legen. Sie gibt die tatsächlich laufende Version, die Betriebsart und das Ergebnis der Prüfung als Text aus. Sie ruft kein phpinfo() auf und verrät keine Pfade oder Passwörter. Trotzdem gilt: nach der Prüfung wieder löschen.

1. Datei herunterladen oder den Code unten kopieren und als php2shell-check.php speichern.
2. Per FTP, SFTP oder Dateimanager des Hosters in das Verzeichnis Ihrer Website laden, dort, wo auch wp-config.php oder index.php liegt.
3. Im Browser https://ihre-domain.de/php2shell-check.php aufrufen und das Ergebnis lesen.
4. Datei wieder löschen.

<?php
// php2shell-check.php: prüft, ob die laufende PHP-Version die Korrekturen
// für CVE-2026-109618 und CVE-2026-109619 (PHP2Shell) enthält.
// Hochladen, im Browser aufrufen, Ergebnis lesen, Datei wieder löschen.
// Quelle und Anleitung: https://konrad-griesser.de/php2shell/
header('Content-Type: text/plain; charset=utf-8');
header('X-Robots-Tag: noindex, nofollow');
header('Cache-Control: no-store');

$fixed  = ['8.5' => '8.5.12', '8.4' => '8.4.27', '8.3' => '8.3.36', '8.2' => '8.2.35'];
$v      = PHP_VERSION;
$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;

echo "PHP2Shell-Check vom " . date('d.m.Y H:i') . "\n";
echo "PHP-Version:        $v\n";
echo "Betriebsart (SAPI): " . PHP_SAPI . "\n\n";

if (isset($fixed[$branch])) {
    if (version_compare($v, $fixed[$branch], '>=')) {
        echo "ERGEBNIS: GESCHÜTZT. Die Version enthält die Korrektur (ab {$fixed[$branch]}).\n";
    } else {
        echo "ERGEBNIS: VERWUNDBAR. Mindestens {$fixed[$branch]} ist nötig. Hoster kontaktieren\n";
        echo "oder im Kundenmenü auf eine korrigierte Version wechseln.\n";
        echo "Hinweis: Debian/Ubuntu/RHEL spielen die Korrektur ohne neue Versionsnummer ein;\n";
        echo "auf eigenen Servern zählt dann die Paketversion (dpkg -l / rpm -q).\n";
    }
} elseif (version_compare($v, '8.2.0', '<')) {
    echo "ERGEBNIS: Zweig $branch wird vom PHP-Projekt nicht mehr gepflegt.\n";
    echo "Es gibt keine offizielle Korrektur. Nur ein vom Hoster bestätigter Backport\n";
    echo "schützt; andernfalls auf PHP 8.3 oder 8.4 wechseln.\n";
} else {
    echo "ERGEBNIS: Zweig $branch ist neuer als diese Prüfung kennt, vermutlich geschützt.\n";
    echo "Bitte Änderungsprotokoll auf php.net prüfen.\n";
}

echo "\nÜbergangseinstellungen (nur wichtig, solange die Version verwundbar ist):\n";
foreach (['session.upload_progress.enabled', 'file_uploads', 'memory_limit', 'post_max_size', 'upload_max_filesize'] as $k) {
    printf("  %-32s %s\n", $k, var_export(ini_get($k), true));
}
echo "\nDiese Datei nach der Prüfung vom Server löschen.\n";

Was die Ausgabe bedeutet: GESCHÜTZT heißt, Sie können die Sache abhaken und sich den Protokollen zuwenden. VERWUNDBAR heißt, der Hoster hat noch nicht aktualisiert oder Sie haben im Kundenmenü eine alte Version gewählt. Steht bei session.upload_progress.enabled eine '0' oder '', ist eine der Übergangsmaßnahmen des PHP-Projekts bereits aktiv.

Was jetzt zu tun ist, in dieser Reihenfolge

1. Version prüfen mit dem Schnellcheck oder dem Skript. Für jede Website und jede Domain einzeln: Viele Hostingpakete erlauben je Domain eine eigene PHP-Version.
2. Verwundbar und Shared Hosting: Im Kundenmenü nachsehen, ob eine neuere Version wählbar ist, und umstellen. Fehlt sie, den Hoster anschreiben und nach der genauen Versionsnummer fragen, nicht nach „ist das Update drauf“. Hetzner, Mittwald, webgo und Host Europe haben ihre Plattformen nach eigenen Angaben am 21. Oktober aktualisiert; IONOS meldete den Rollout am Abend des 21. Oktober als laufend. Für All-Inkl, STRATO, domainfactory und Raidboxes lag mir am 22. Oktober keine abschließende Herstellerangabe vor. Ihre Versionsnummer ist die einzige Aussage, die zählt.
3. Noch auf 8.1 oder älter: Im Kundenmenü auf 8.3 oder 8.4 wechseln. Vorher mit einem frischen Backup prüfen, ob Theme und Plugins mitspielen. Dabei bricht gelegentlich ein altes Plugin; wie ich das abfange, steht auf der Seite WordPress-Wartung.
4. Eigener Server: Pakete der Distribution einspielen, PHP-FPM oder Apache neu starten, Paketversion mit dem Änderungsprotokoll abgleichen. Debian und Ubuntu haben die Fixes am 21. Oktober geliefert.
5. Übergangsmaßnahmen, wenn das Update noch aussteht: Das PHP-Projekt nennt session.upload_progress.enabled=0 und ein niedriges post_max_size in der Serverkonfiguration (nicht per ini_set() im Skript), Automattic zusätzlich file_uploads=Off und das Blockieren von Multipart-Anfragen am Webserver, wenn die Website keine Uploads braucht. Eine Web Application Firewall wie die von Cloudflare blockt bekannte Angriffsmuster seit dem 21. Oktober. Das alles verkleinert die Angriffsfläche, macht die Installation aber nicht sicher.
6. Protokolle ansehen, zurück bis mindestens zum 17. Oktober. Amazon hat an diesem Tag erste Ausnutzungsversuche in seinem Sensornetz gesehen, vier Tage vor der Veröffentlichung.

Woran Sie erkennen, ob jemand schon drin war

Ein erfolgreicher Angriff hinterlässt nicht immer eine Spur in den Anwendungsprotokollen. Diese Hinweise sind trotzdem die üblichen:

• Im Fehlerprotokoll gehäufte Meldungen „Allowed memory size … exhausted“, vor allem mit dem Zusatz „in Unknown on line 0“, und Serien von HTTP-500-Antworten nach ungewöhnlichen POST- oder Multipart-Anfragen. Das ist das Muster, das Wiz und Automattic beschreiben.
• Anfragen mit dem Feld PHP_SESSION_UPLOAD_PROGRESS im Zugriffsprotokoll, wenn Ihre Website diese Funktion nicht nutzt.
• Neue oder veränderte PHP-Dateien in Verzeichnissen, in denen keine hingehören: wp-content/uploads, Cache-Ordner, der Webspace-Stamm. Dateidaten vom 17. Oktober an aufwärts sind verdächtig.
• Unbekannte Administratorkonten, geänderte Weiterleitungen, fremde Links oder Texte, Warnungen in der Google Search Console unter „Sicherheitsprobleme“.

Finden Sie einen dieser Hinweise, behandeln Sie die Website als kompromittiert: Zugangsdaten ändern, Backup von vor dem 17. Oktober sichern, Hoster informieren und die Seite bereinigen lassen. Ein bloßes PHP-Update entfernt keine Hintertür, die schon liegt.

Warum das nicht das letzte Mal war

PHP2Shell ist die dritte PHP-Lücke in wenigen Jahren, die flächendeckend angegriffen wurde. CVE-2019-11043 in PHP-FPM und CVE-2024-4577 in PHP-CGI unter Windows stehen beide im Katalog der US-Behörde CISA für nachweislich ausgenutzte Schwachstellen, die zweite wurde von Ransomware-Gruppen genutzt. Neu ist das Tempo: Die Entdecker von PHP2Shell schreiben, dass die Fehler seit über einem Jahrzehnt im Code lagen und KI-Werkzeuge die Hürde deutlich gesenkt haben, aus so einem alten Fehler einen funktionierenden Angriff zu bauen. Die ersten Ausnutzungsversuche kamen vor dem Patch, die Massen-Scans am Tag der Veröffentlichung.

Rechnen Sie also damit, dass sich das wiederholt, bei PHP, bei WordPress-Plugins, bei Shopsystemen. Dazu kommt ein planbares Datum: PHP 8.2 bekommt ab dem 1. Januar 2027 keine Sicherheitsupdates mehr. Wer dann noch darauf läuft, steht bei der nächsten Lücke ohne Korrektur da, so wie heute die Betreiber auf 8.1. Eine Website braucht deshalb jemanden, der solche Meldungen liest, die Versionen kennt und am Tag der Veröffentlichung handelt, nicht erst beim nächsten Wartungsfenster.

Warum Sie das bei mir in guten Händen haben

Ich baue und betreue seit 1999 Websites, über 500 Projekte, die meisten auf WordPress, dazu Shops und Individualentwicklungen. Hosting, PHP-Versionen, Serverkonfiguration und Protokolle gehören bei mir zum Handwerk, nicht zur Weitergabe an eine Hotline. Bei meiner WordPress-Betreuung steht die PHP-Version bei jedem Wartungstermin auf der Liste, und bei einer Warnung wie der vom 21. Oktober gehe ich die betreuten Seiten am selben Tag durch, statt auf Kundenanfragen zu warten.

Für PHP2Shell biete ich drei Dinge an. Erstens die Prüfung: Ich lese die laufende Version, die Hosting-Einstellungen und die Protokolle und sage Ihnen, ob Sie geschützt sind. Zweitens den Versionswechsel: auf einer Kopie testen, Plugins und Theme anpassen, umstellen, nachkontrollieren. Drittens die Bereinigung, falls schon jemand drin war: Hintertüren entfernen, Zugänge erneuern, Google-Warnung aufheben lassen. Alles zum Festpreis vorab; die laufende Betreuung danach kostet je nach Umfang 30 bis 100 € im Monat, monatlich kündbar, Einzelheiten auf der Preisseite. Sie erreichen mich direkt, ohne Ticketsystem.

Quellen und Stand

Stand dieser Seite: 22. Oktober 2026. Grundlage sind das Security Advisory des PHP-Projekts, der Beitrag der PHP Foundation, die Warnung des BSI, die Mitteilung von Automattic, der Cloudflare-Blog, die Analyse von Wiz, der Bericht von Amazon Threat Intelligence sowie die Statusseiten von Hetzner, Mittwald, webgo, Host Europe und IONOS und die Sicherheitsmeldungen von Ubuntu und Debian. Ändert sich die Lage, aktualisiere ich diese Seite.