Behandeln Sie PHP 5 als betroffen und ungepatcht
PHP 5.6, der letzte 5.x-Zweig, hat am 31. Dezember 2018 sein Supportende erreicht. Das letzte Release war 5.6.40. Die früheren 5.x-Zweige endeten Jahre davor.
Für PHP2Shell nennt das PHP-Projekt Fixes für 8.2 bis 8.5 und veröffentlicht Quellcode-Backport-Zweige für 7.4, 8.0 und 8.1. Für 5.x hat es nichts veröffentlicht, auch keine Stellungnahme.
Ob 5.x dieselben Fehler enthält, hat das PHP-Projekt nicht gesagt. Einige Sekundärquellen behaupten, jeder Build ab PHP 5 sei betroffen. Die offiziellen Advisories nennen nur 8.2 bis 8.5, und die Versionsbereiche im NVD-Eintrag erfassen formal auch ältere Builds. Keine der beiden Lesarten können wir für 5.x bestätigen, und einen vertrauenswürdigen öffentlichen Test kennen wir nicht.
Die sichere Annahme: PHP 5 ist betroffen, es gibt keinen Upstream-Fix, und es kommt auch keiner.
PHP 5 war schon vorher unsicher
Ein Server mit PHP 5.6 bekommt seit Anfang 2019 keine Sicherheitsfixes mehr. Die Empfehlung lautete schon vorher, PHP 5 zu verlassen. PHP2Shell verkürzt die Zeit, die Ihnen dafür bleibt.
Wer noch PHP-5-Builds verkauft
Einige Anbieter patchen alte PHP-Versionen weiter, nachdem das PHP-Projekt aufgehört hat. Soweit wir es gefunden haben, hat keiner bestätigt, dass seine PHP-5-Builds diese beiden CVEs abdecken. Stand bei unserer letzten Prüfung am 21. Oktober 2026:
| Quelle | Abdeckung von PHP 5 | PHP2Shell-Stand für PHP 5 |
|---|---|---|
| TuxCare ELS | Produktseite nennt PHP ab 5.2 | Im Tracker fanden wir zu keiner der beiden CVEs einen Eintrag |
| CloudLinux alt-php | Builds für 5.2 bis 8.5 | Laut CloudLinux sind die Builds „in Vorbereitung“. Nur Builds von alt-php74 waren als ausgeliefert gelistet |
| Ubuntu Pro mit Legacy Support | 14.04 liefert php5 5.5.9, 16.04 liefert php7.0 | In USN-8948-2 als behoben gelistet. Achtung: 5.5.9, nicht 5.6 |
| HeroDevs NES | Beginnt bei PHP 7.2 | Nicht abgedeckt |
Die Angaben von Red Hat zu RHEL 6 und RHEL 7, die PHP-5.x-Builds ausliefern, sind uneinheitlich. RHEL 6 gilt dort als nicht betroffen von CVE-2026-109618, für CVE-2026-109619 steht „no fix planned“, und zu RHEL 7 gibt es widersprüchliche Aussagen. Eine Entwarnung ist das nicht. Die Angaben betreffen nur Red Hats eigene alte Builds, und die Frage bleibt offen.
Eine allgemeine Zusage „Abdeckung für 5.x“ sagt nichts über CVE-2026-109618 und CVE-2026-109619 aus. Fragen Sie den Anbieter nach jeder CVE-Nummer einzeln und lassen Sie sich die Antwort schriftlich geben. Ausführlicher verglichen unter Alte PHP-Versionen.
Was Sie diese Woche tun sollten
- Klären, wer PHP betreibt. Auf dem eigenen Server führen Sie
php -vaus und notieren die SAPI. Bei Shared Hosting öffnen Sie die PHP-Einstellungen im Kundenmenü. Ist PHP 5 dort die einzige Wahl, hängt der Hoster hinterher. Lesen Sie die Anleitung für Shared Hosting und stellen Sie die Fragen aus der Einschätzung. - Die Angriffsfläche verkleinern, wo es geht. Muss die Website nicht öffentlich sein, stellen Sie sie am Proxy hinter eine Anmeldung oder ein VPN. Das verkleinert die Angriffsfläche, behebt aber nichts.
- Den Umstieg planen. Für 5.x gibt es nichts zum Patchen, der Umstieg ist also der Fix.
- Nach Schäden suchen. Alte Stacks haben viele weitere offene Lücken. Suchen Sie deshalb nach Spuren eines früheren Einbruchs. Siehe Nach dem Patchen und für WordPress Was tun, wenn die Seite gehackt wurde.
Wenn Sie den Server selbst verwalten und diese Woche nicht umsteigen können: Die PHP2Shell-Meldung von WordPress.org rät Betreibern, die ihren eigenen Server verwalten und Versionen älter als 8.2 einsetzen, den Server während des Umstiegs vom Netz zu nehmen. WordPress.org beruft sich dabei auf das britische NCSC. Der Rat stammt von WordPress.org.
Ein realistischer Migrationspfad
Direkt von 5.6 auf 8.4 klappt selten. Teilen Sie den Weg in zwei Etappen und halten Sie nach jeder eine funktionierende Kopie der Website bereit.
Etappe 1: 5.6 auf 7.4. Das ist der große Sprung. PHP 7.0 hat die alten mysql_*-Funktionen entfernt. Code, der sie noch aufruft, muss auf mysqli oder PDO umgestellt werden. Für Plugins, Themes und Bibliotheken aus der PHP-5-Zeit gibt es oft neuere Versionen. Wo nicht, ersetzen Sie sie. Arbeiten Sie mit dem Migrationsleitfaden von 5.6 auf 7.0 aus dem PHP-Handbuch und gehen Sie danach auf einer Testkopie Schritt für Schritt über 7.1 bis 7.4. PHP 7.4 hat selbst sein Supportende erreicht. Sehen Sie es als Zwischenstation und gehen Sie weiter.
Etappe 2: 7.4 auf 8.4. Siehe die Anleitung von 7.4 auf 8.4. 8.4 wird bis 31. Dezember 2028 unterstützt und enthält die Fixes für PHP2Shell ab 8.4.27.
Der aktuelle WordPress-Core nennt PHP 7.4 und neuer als lauffähigen Bereich und empfiehlt 8.3 oder neuer. Eine WordPress-Seite auf PHP 5.6 läuft vermutlich auch mit einem alten Core, der PHP-Umstieg und das WordPress-Update gehören also zusammen. Siehe PHP-Version prüfen und PHP-Version ändern.
Wenn eine Migration nicht realistisch ist
Wenn die Anwendung alt und ungepflegt ist und niemand sie reparieren kann:
- Neu aufbauen. Bei einer kleinen Website ist es oft billiger, die Inhalte in ein aktuelles CMS zu übernehmen, als jahrelang gewachsenen PHP-5-Code zu portieren.
- Einfrieren und isolieren. Machen Sie statische Seiten daraus, oder betreiben Sie die alte Anwendung in einem privaten Netz hinter einem VPN.
- Einen Anbieter-Build bezahlen, aber erst, wenn der Anbieter beide CVEs für die Version bestätigt, die Sie einsetzen.
Wofür Sie sich auch entscheiden, halten Sie das Datum der Entscheidung schriftlich fest. Die vollständige Liste der Optionen steht unter PHP End of Life.
Zuletzt geprüft am 22. Oktober 2026.