--- title: "PHP2Shell: Altes PHP aktualisieren oder migrieren?" canonical: https://wavect.io/de/blog/php2shell-legacy-php-upgrade-migration/ language: de description: "PHP2Shell trifft auch alte PHP-Anwendungen. Prüfe gepatchte Versionen, Backports und Upgrade-Hürden. Wavect hilft beim PHP-Upgrade oder Wechsel zu Node.js." image: "https://wavect.io/img/blog/headers/header_php2shell-legacy-php-upgrade-migration.png" author: ["Kevin Riedl"] published: "2026-10-21" updated: "2026-10-21" reviewed: "2026-10-21" --- # PHP2Shell: Altes PHP aktualisieren oder zu Node.js wechseln? [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min Lesezeit · 21. Okt. 2026 Zuletzt geprüft 21. Oktober 2026 [**Weiter**](/de/blog/software-project-takeover-provider-change/) TL;DR Für PHP2Shell sind seit 21. Oktober 2026 die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 verfügbar. PHP 8.1 und ältere Zweige erhalten keine regulären PHP-Sicherheitsreleases mehr; für 7.4, 8.0 und 8.1 gibt es jedoch minimale Quellcode-Backports und gegebenenfalls Anbieterpakete. Prüfe zuerst den tatsächlich laufenden PHP-Dienst und schließe die akute Lücke. Wavect behebt Kompatibilitätsprobleme und migriert alte Anwendungen auf eine unterstützte, gepatchte PHP-Version. Wenn Produkt und Team davon profitieren, planen wir auch einen schrittweisen Wechsel zu Node.js/TypeScript oder einem anderen passenden Stack. Verbleibende PHP-Komponenten müssen weiterhin abgesichert werden. **Für die kritischen PHP-Lücken gibt es einen Patch. Schwierig wird es, wenn deine Geschäftsanwendung mit der neuen Version nicht läuft.** Halten ein altes Framework, eine eigene Erweiterung oder ein nicht mehr gepflegtes Plugin dein Unternehmen auf PHP 7.4, 8.0 oder 8.1 fest, kann ein Klick im Hosting-Menü die Anwendung lahmlegen. Du brauchst eine nachweislich wirksame Lösung für die aktuelle Lücke und einen machbaren Weg zu Software, die dein Team langfristig warten kann. **Wavect hilft Unternehmen, ältere PHP-Anwendungen auf die neueste gepatchte und unterstützte PHP-Version zu bringen.** Wir beheben Kompatibilitätsprobleme, testen die entscheidenden Abläufe und planen die Umstellung im laufenden Betrieb. Wenn ein größerer Wechsel zum Unternehmen passt, migrieren wir PHP-Anwendungen auch zu Node.js/TypeScript,.NET, Java oder einem anderen geeigneten, gepflegten Stack. *Quellen geprüft am 21. Oktober 2026. Die folgenden Versionsnummern zeigen den Stand an diesem Tag. Prüfe bei der Umsetzung, welcher unterstützte Patch dann aktuell ist.* ## Was steckt hinter der neuen PHP-Sicherheitslücke PHP2Shell? **PHP2Shell bezeichnet zwei kritische Schwachstellen in der PHP-Laufzeitumgebung: CVE-2026-109618 und CVE-2026-109619. Sie wurden am 21. Oktober 2026 zusammen mit den Korrekturen veröffentlicht.** Ein Angreifer kann darüber unter Umständen ohne Anmeldung Code auf einem betroffenen Server ausführen. Die [PHP-Sicherheitswarnung von CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-018) fordert zum sofortigen Einspielen der Updates auf und nennt PHP-Installationen, die Webanfragen verarbeiten, als gefährdet. | Schwachstelle | Was schiefläuft | | --- | --- | | [CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) | PHP kann eine fehlgeschlagene Speicherzuweisung falsch behandeln und später Anfragedaten verarbeiten, die nie vollständig initialisiert wurden. | | [CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) | Eine spätere Anfrage kann auf interne Zustände zugreifen, die nach dem Freigeben des Speichers einer früheren Anfrage zurückgeblieben sind. | Die offizielle Warnung umfasst Apache mit `mod_php`, PHP-FPM, `php-cgi`, FrankenPHP und LiteSpeed. Das PHP-Team bewertet das Risiko bei `mod_php` am höchsten: Dort wurde die Ausnutzung bereits nachgewiesen, bevor Anwendungscode läuft. Welche Angriffswege möglich sind, hängt von der Konfiguration ab. Auch ein Betrieb mit Nginx und PHP-FPM muss geprüft werden. Ein Update von WordPress, Laravel, Symfony oder einer anderen Anwendung aktualisiert nicht automatisch die darunterliegende PHP-Laufzeitumgebung. Prüfe beide Ebenen. ## Welche PHP-Versionen beheben PHP2Shell? **Die ersten gepatchten stabilen Releases sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.** Installiere das passende unterstützte Update oder ein nachweislich korrigiertes Anbieterpaket. Ein Patch innerhalb deines bereits unterstützten Versionszweigs kann die akute Lücke schließen, während ein größeres Upgrade vorbereitet wird. | PHP-Zweig | Erstes korrigiertes Release | Sicherheits-Support bis | | --- | --- | --- | | 8.5 | 8.5.12 | 31. Dezember 2029 | | 8.4 | 8.4.27 | 31. Dezember 2028 | | 8.3 | 8.3.36 | 31. Dezember 2027 | | 8.2 | 8.2.35 | 31. Dezember 2026 | | 8.1 und älter | Verifizierte Backports prüfen oder upgraden | Regulärer Support durch das PHP-Projekt beendet | Die Fristen stammen aus dem [offiziellen PHP-Supportplan](https://www.php.net/supported-versions.php). PHP 8.2 erhält für diesen Vorfall noch eine Korrektur. Wegen des nahenden Supportendes eignet es sich aber nur als kurzfristiges Ziel. Wer auf die neueste stabile PHP-Version wechseln möchte, hat am Veröffentlichungstag mit **PHP 8.5.12** ein verifiziertes Ziel, sofern die Anwendung damit kompatibel ist. Die [offiziellen PHP-Release-Ankündigungen](https://www.php.net/) führen auch PHP 8.6.0 RC4 mit Korrekturen auf. Sie kennzeichnen diese Version ausdrücklich als Testrelease, das nicht im Produktivbetrieb eingesetzt werden soll. ## Was tun, wenn du noch PHP 7.4, 8.0 oder 8.1 nutzt? **Für diese Zweige veröffentlicht das PHP-Projekt keine regulären Sicherheitsreleases mehr. Trotzdem kann es auch für eine alte Installation eine Korrektur geben.** Die PHP-Ankündigungen verlinken ausnahmsweise minimale Quellcode-Backports für 7.4, 8.0 und 8.1. Auch Linux-Distributionen und Anbieter von Langzeit-Support können gepatchte Pakete bereitstellen. Ein Backport überträgt eine Fehlerbehebung auf einen älteren Codebestand. Das kann die Zeit überbrücken, in der die Anwendung für eine neue PHP-Version angepasst wird. Ein solcher Patch macht aus einem abgekündigten Zweig jedoch kein regulär gepflegtes PHP-Release. Maßgeblich bleibt die [PHP-Liste der Versionen mit beendetem Support](https://www.php.net/eol.php). Frage deinen Hoster, welches genaue Paket **beide CVEs** behebt, ob es in deinem Tarif verfügbar ist und wer es einspielt. Anbieterpakete können weiterhin eine ältere PHP-Versionsnummer anzeigen. Deshalb zählen auch die Paketrevision und die zugehörige Sicherheitsmeldung. Bei einem Quellcode-Backport muss außerdem jemand das Paket bauen, testen, ausrollen und künftig warten. Gibt es für deine Installation weder ein verifiziertes, unterstütztes Paket noch einen nutzbaren Backport, kann Wavect die Hindernisse prüfen und die Anwendung auf einen unterstützten, gepatchten PHP-Zweig migrieren. Dazu gehören die Anwendung und ihre Abhängigkeiten genauso wie die Serverkonfiguration. ## Was sollte ein Unternehmen sofort tun? 1. **Alle PHP-Installationen erfassen.** Dazu gehören Kundenportal, Website, Verwaltungsoberflächen, alte Subdomains, Container und eingekaufte Produkte. Die [PHP2Shell-Bestandshinweise des NCSC-NL](https://github.com/NCSC-NL/php2shell) weisen auch auf Software und Geräte hin, die PHP mitbringen. 2. **Den tatsächlich laufenden Webdienst prüfen.** `php -v` im Terminal kann eine andere Installation anzeigen als die, die PHP-FPM oder Apache verwendet. Lass dir für jede Instanz die PHP-Laufzeitumgebung, Paketquelle und tatsächlich laufende Version bestätigen. Halte Diagnoseseiten privat. 3. **Die Korrektur einspielen und kontrollieren.** Aktualisiere die betroffenen Pakete oder Images, starte die betroffenen Worker neu oder ersetze sie und prüfe jede Instanz. Ein geänderter Image-Tag reicht nicht, solange die alten Container weiterlaufen. 4. **Die wichtigen Geschäftsabläufe testen.** Prüfe Anmeldung, Berechtigungen, Zahlungen, Uploads, geplante Aufgaben und die tatsächlich genutzten Schnittstellen. 5. **Bei blockiertem Update über die Erreichbarkeit entscheiden.** Folge den aktuellen offiziellen Empfehlungen zur Begrenzung des Risikos. CERT-EU empfiehlt, die Trennung von öffentlichen Netzen in Betracht zu ziehen, wenn ein erreichbarer Dienst nicht zeitnah gepatcht werden kann. Die vorläufigen Konfigurationsmaßnahmen des PHP-Teams decken bestimmte Angriffswege ab. Eine WAF-Regel oder eine geänderte Einstellung belegt nicht, dass die Laufzeitumgebung korrigiert ist. Gibt es Hinweise auf einen Einbruch, veranlasse parallel zum Patchen eine Untersuchung. Ein Update allein beweist nicht, dass ein System frei von Schadcode ist. ## Warum kann ein PHP-Upgrade eine ältere Anwendung lahmlegen? **Ein Upgrade von altem PHP erfordert oft Anpassungen an der Anwendung.** Die [PHP-Migrationshinweise von 7.4 auf 8.0](https://www.php.net/manual/en/migration80.incompatible.php) dokumentieren geändertes Verhalten und entfernte Funktionen. Auch der [Migrationsleitfaden für PHP 8.5](https://www.php.net/manual/en/migration85.php) empfiehlt, Inkompatibilitäten vor der Umstellung im Produktivbetrieb zu testen. Bevor wir die Zielversion festlegen, prüfen wir fünf typische Hindernisse: - **Framework und CMS:** Unterstützen die installierte Version, Themes und Plugins die gewünschte PHP-Version? - **Abhängigkeiten:** Welche Versionsgrenzen setzt Composer? Welche Pakete werden nicht mehr gepflegt, welche Bibliotheken müssen ersetzt werden? - **Erweiterungen und Hosting:** Passen Datenbanktreiber, Bildverarbeitung, eigene Module und die beim Hoster tatsächlich verfügbaren Pakete? - **Geschäftslogik:** Funktionieren Berechnungen, Eingabeprüfungen, Sitzungen, Berechtigungen und Schnittstellen weiterhin korrekt? - **Kontrollierte Veröffentlichung:** Gibt es eine brauchbare Testumgebung, Backups, Überwachung und einen Rückweg, der neue Daten schützt? Bei einem Wechsel von PHP 7.4 auf 8.5 gehören auch die Migrationsleitfäden der Zwischenversionen dazu. Diese Änderungen lassen sich in isolierten Testumgebungen prüfen, ohne jede veraltete Zwischenversion öffentlich in Betrieb zu nehmen. ## PHP aktualisieren oder zu Node.js migrieren? **Bleib bei PHP, wenn sich die Anwendung auf einer unterstützten Version wirtschaftlich warten lässt. Prüfe einen schrittweisen Wechsel, wenn Produktanforderungen, Abhängigkeiten oder die Fähigkeiten deines Teams dafür sprechen.** Schließe die aktuelle Lücke, bevor du die akute Absicherung von einem vollständigen Neubau abhängig machst. | Ausgangslage | Praktischer Weg | Was nachgewiesen werden muss | | --- | --- | --- | | Unterstütztes PHP, kompatible Anwendung | Den Patch im aktuellen Versionszweig einspielen und spätere Upgrades planen. | Die korrigierte Version läuft überall, wichtige Geschäftsabläufe bestehen die Tests. | | Altes PHP, weiterhin brauchbare Anwendung | Wenn verfügbar, einen verifizierten Backport nutzen. Dann Kompatibilität herstellen und PHP aktualisieren. | Eine unterstützte Zielversion, funktionierende Abhängigkeiten und ein festes Ende der Übergangslösung. | | Altes PHP, zusätzliche Gründe für einen Ersatz | Die aktuelle Laufzeitumgebung absichern und anschließend Funktionen schrittweise migrieren. | Geschäftsregeln und Daten bleiben korrekt. Ersetzte PHP-Pfade werden tatsächlich entfernt. | Node.js/TypeScript kann zu einem Team passen, das bereits JavaScript-Anwendungen entwickelt..NET oder Java können sich in eine bestehende Unternehmensumgebung einfügen. Auch andere gepflegte Stacks kommen infrage. Entscheidend sind Schnittstellen, Hosting, vorhandenes Wissen und Betriebskosten. Für Node.js empfiehlt der [offizielle Release-Leitfaden](https://nodejs.org/en/about/previous-releases) für den Produktivbetrieb Versionen mit Active LTS oder Maintenance LTS. **Wird PHP aus einer Komponente entfernt, entfällt für diese Komponente die Gefährdung durch genau diese PHP-Laufzeitlücken.** Node.js und andere Alternativen können weiterhin eigene Schwachstellen haben. Ein neues React-Frontend, eine JavaScript-API vor PHP oder ein Headless-WordPress-System lässt weiterhin PHP-Komponenten zurück, die gewartet werden müssen. Unsere [Web-App-Entwicklung](/de/services/web-apps/) übernimmt die Umsetzung nach dieser Architekturentscheidung. Die Technologie muss zum Produkt passen, das dein Unternehmen betreiben möchte. ## Beispiel: Ein Bestellportal hängt auf PHP 7.4 fest *Ein beispielhaftes Szenario, keine Kundenfallstudie:* Ein Händler betreibt ein Bestellportal mit individuellen Preisen, kundenspezifischen Berechtigungen und einer ERP-Anbindung. Ein nicht mehr gepflegtes Modul verhindert das direkte Upgrade. Zuerst braucht die PHP-Laufzeitumgebung eine verifizierte Korrektur. Ist das nicht sofort möglich, wird die Erreichbarkeit des betroffenen Dienstes eingeschränkt, während die Behebung vorbereitet wird. Anschließend prüfen wir, ob sich die Anwendung durch den Austausch des Moduls mit aktuellem PHP weiterbetreiben lässt. Wenn ja, kann ein PHP-Upgrade jahrelang bewährte Geschäftslogik erhalten. Plant das Unternehmen ohnehin größere Produktänderungen, können wir eine klar abgegrenzte Funktion zu Node.js verlagern, während das abgesicherte PHP-System weiterläuft. Jeder Schritt braucht eindeutige Zuständigkeiten für Datenänderungen, passende Berechtigungen und Prüfungen auf fehlende oder doppelte Bestellungen. Die Migration ist erst abgeschlossen, wenn die ersetzten PHP-Routen und ihre Abhängigkeiten stillgelegt sind. Verglichen werden die Kosten eines gepflegten PHP-Produkts mit Kosten und Nutzen eines schrittweisen Ersatzes. Dazu gehört auch die Phase, in der beide Systeme parallel laufen. ## Wie Wavect bei PHP-Upgrades und Migrationen hilft Wir helfen Unternehmen in Österreich, der DACH-Region und international, aus einem dringenden PHP-Update einen umsetzbaren Plan zu machen. Ist die vorhandene Codebasis oder der Update-Weg unklar, beginnen wir mit unserer [Software-Übernahme und Bestandsprüfung](/de/services/software-takeover/). | Arbeit | Was dein Unternehmen erhält | | --- | --- | | Installation prüfen | Bestandsliste von Laufzeitumgebungen und Abhängigkeiten, erkannte Risiken, Kompatibilitätshindernisse und eine Empfehlung zum weiteren Vorgehen. | | PHP auf eine unterstützte Version bringen | Anpassungen an Anwendung und Abhängigkeiten für die vereinbarte gepflegte Version, einschließlich Tests wichtiger Geschäftsabläufe. | | PHP durch einen anderen Stack ersetzen | Schrittweise Umsetzung mit Node.js/TypeScript oder einem anderen geeigneten Stack, mit klaren Grenzen für Daten und Schnittstellen. | | Produktivbetrieb vorbereiten | Getesteter Umstellungsplan, geprüfte Backups und Wiederherstellung, Überwachung und festgelegte Bedingungen für einen Rollback. | | Ergebnis übergeben | Nachweise zur Version und Ausrollung, Testergebnisse, Betriebsanleitung und nächster Wartungstermin. | Unsere [Software-Qualitätssicherung](/de/services/software-quality-assurance/) kann prüfen, ob die neue Version die vereinbarten Geschäftsabläufe erfüllt. Für den gesamten Verantwortungswechsel hilft der [Leitfaden zur Übernahme eines Softwareprojekts](/de/blog/software-project-takeover-provider-change/). Kosten und Dauer hängen vom Framework, nicht mehr unterstützten Abhängigkeiten, Schnittstellen, vorhandenen Tests und dem möglichen Wartungsfenster ab. Den Umfang vereinbaren wir nach Prüfung dieser Punkte. Ein Rollback muss neue Transaktionen erhalten und darf keine bekanntermaßen verwundbare PHP-Laufzeitumgebung wieder öffentlich erreichbar machen. ## Welche Nachweise zeigen, dass das PHP-Upgrade abgeschlossen ist? Fordere vor dem Abschluss diese Nachweise an: - **Laufzeitumgebung:** Genaue PHP-Version oder Anbieterpaket, Nachweis der Korrektur beider CVEs und Prüfung jeder Instanz, die Webanfragen verarbeitet. - **Ausrollung:** Alte Worker wurden ersetzt oder neu gestartet. Alte Container-Instanzen erhalten keine Anfragen mehr. - **Geschäftsabläufe:** Vereinbarte Tests für Berechtigungen, Transaktionen und benötigte Schnittstellen sind bestanden. Relevante Fehler wurden nach der Umstellung geprüft. - **Beim Wechsel weg von PHP:** Eine Übersicht zeigt, welche PHP-Dienste stillgelegt wurden und welche weiterhin gepatcht und gewartet werden, einschließlich Verwaltungsoberflächen und CMS-Backends. **Schick uns deine PHP-Version, dein Framework oder CMS, das Hosting-Setup und den Ablauf, der unbedingt weiter funktionieren muss.** Kennst du die Version nicht, nenne uns den Hoster. Damit können wir den nötigen Umfang für Upgrade oder Migration klären. ## Häufige Fragen zu PHP2Shell und zur Migration alter PHP-Anwendungen ### Gibt es einen PHP2Shell-Patch für PHP 7.4 oder PHP 8.1? Für diese nicht mehr unterstützten Zweige gibt es kein reguläres neues Release des PHP-Projekts. PHP hat ausnahmsweise minimale Quellcode-Backports für 7.4, 8.0 und 8.1 veröffentlicht. Einige Anbieter liefern gepatchte Pakete. Prüfe, ob beide CVEs behoben sind, und plane den Wechsel auf einen gepflegten Zweig. ### Was ist die neueste gepatchte PHP-Version? Am 21. Oktober 2026 ist PHP 8.5.12 die neueste stabile Version. Auch PHP 8.4.27, 8.3.36 und 8.2.35 beheben beide PHP2Shell-Schwachstellen. Prüfe beim Ausrollen den dann aktuellen unterstützten Patch. PHP 8.6 RC4 ist ein Testrelease. ### Sind Installationen mit Nginx und PHP-FPM betroffen? Ja. Die PHP-Warnung umfasst PHP-FPM ebenso wie mod_php, php-cgi, FrankenPHP und LiteSpeed. Mögliche Angriffswege hängen von Konfiguration und Anwendungsverhalten ab. Der Einsatz von Nginx belegt nicht, dass die PHP-Laufzeitumgebung sicher ist. ### Behebt ein WordPress- oder Laravel-Update PHP2Shell? Ein Anwendungsupdate allein beweist nicht, dass auch die separate PHP-Laufzeitumgebung gepatcht wurde. Lass dir Paket und Ausrollung vom Hoster bestätigen und prüfe im Zuge der Umstellung auch die Kompatibilität der Anwendung. ### Sollten wir wegen PHP2Shell von PHP zu Node.js wechseln? Schließt zuerst die akute Lücke. Bleibt bei PHP, wenn eine unterstützte Version die Anforderungen des Produkts erfüllt. Eine schrittweise Node.js-Migration kommt infrage, wenn Abhängigkeiten, künftige Anforderungen oder das Wissen im Team den Aufwand rechtfertigen. Verbleibende PHP-Dienste benötigen weiterhin ihre eigene Korrektur. ### Kann Wavect helfen, wenn unsere alte PHP-Anwendung nach einem Upgrade nicht mehr läuft? Ja. Wavect kann den Fehler untersuchen, Framework, Abhängigkeiten und Erweiterungen kompatibel machen, Geschäftsabläufe testen und eine kontrollierte Umstellung planen. Passt die weitere Wartung mit PHP nicht mehr, können wir eine schrittweise Migration zu einem anderen Stack ausarbeiten. ### Ist eine PHP-Migration ohne Ausfallzeit möglich? Manche Änderungen lassen sich laufend oder schrittweise ausrollen, andere brauchen ein Wartungsfenster. Datenänderungen, Sitzungen, Schnittstellen und Hosting bestimmen, was möglich ist. Vereinbart Umstellung, Wiederherstellung und Rollback, bevor ihr eine bestimmte Ausfallzeit zusagt. Architektur und Plattformen ## Weiterlesen Framework-, Plattform- und Systementscheidungen mit langfristiger Delivery-Wirkung. [Hier starten**Smart-City-Architektur: MQTT, LoRaWAN, Kubernetes und Terraform**](/de/blog/smart-city-architecture-best-practices-2026/) - [git-ai: Parallele Agenten-Merges und Verifikation](/de/blog/git-ai-concurrent-agents-merge-verification/) - [Enterprise-Software: Spezialisten neben dem Systemintegrator einbinden](/de/blog/enterprise-software-specialist-system-integrator/) - [NVIDIA Run:ai Open Source: GPU-Flotte und Softwarefabrik](/de/blog/nvidia-runai-open-source-gpu-software-factory/) - [GitButler für parallele KI-Agenten: Mehrere Branches, ein Build](/de/blog/gitbutler-parallel-ai-agents-one-workspace/) - [Vendo für SaaS: Mandantentrennung und Freigaben](/de/blog/vendo-saas-tenant-isolation/) [Vorheriger Artikel**git-ai: Parallele Agenten-Merges und Verifikation**](/de/blog/git-ai-concurrent-agents-merge-verification/) [Nächster Artikel**Enterprise-Software: Spezialisten neben dem Systemintegrator einbinden**](/de/blog/enterprise-software-specialist-system-integrator/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min Lesezeit · 21. Okt. 2026 Zuletzt geprüft 21. Oktober 2026 [**Weiter**](/de/blog/software-project-takeover-provider-change/)