PHP 8.2 End of Life am 31.12.2026: Das müssen Sie tun

PHP 8.2 erreicht am 31. Dezember 2026 das Support-Ende (End of Life). Nach diesem Datum veröffentlicht das PHP-Projekt keine Sicherheitsupdates mehr dafür. Ihre Website läuft weiter, aber der nächste schwere PHP-Fehler, wie PHP2Shell im Oktober, wird für 8.2 nicht mehr behoben. Die Lösung ist der Wechsel auf PHP 8.4 (Sicherheitsupdates bis 31. Dezember 2028) oder auf 8.3 (bis 31. Dezember 2027), wenn ein Plugin oder Framework, auf das Sie angewiesen sind, noch nicht für 8.4 bereit ist. Bei einer WordPress-Website mit aktuellen Plugins sind das meist ein paar Stunden Testen. Alter Individualcode, verwaiste Plugins und Docker-Images brauchen länger, beginnen Sie also im November und nicht am 30. Dezember.

Was Support-Ende bedeutet und was nicht

• Ihre Website bleibt am 1. Januar nicht stehen. PHP 8.2 läuft weiter. Was aufhört, sind die Fixes von php.net, und die offiziellen Docker-Images bekommen keine Updates mehr.
• Das Risiko wächst mit der Zeit. Jede Sicherheitslücke, die nach dem 31. Dezember in PHP gefunden wird, bleibt in 8.2 offen. Im Oktober 2026 zeigte PHP2Shell, wie schnell das zählt: Die Angriffe begannen an dem Tag, an dem der Fix erschien.
• Ihr Hoster kann Sie umstellen. Viele Hoster stellen Websites nach dem Support-Ende auf eine neuere PHP-Version um, manchmal mit wenig Vorlauf, und einige berechnen Aufpreis, um eine alte Version weiterlaufen zu lassen. Eine erzwungene Umstellung bei einer nie getesteten Website führt zu einer Meldung über einen kritischen Fehler statt Ihrer Website.
• Linux-Distributionen sind ein Sonderfall. Manche Distributionen patchen ihr eigenes PHP-8.2-Paket weiter, solange sie die Distribution selbst unterstützen. Läuft PHP auf Ihrem Server aus den Paketen Ihrer Distribution, prüfen Sie den Security Tracker dieser Distribution. Das gilt nicht für php.net-Builds, die offiziellen Docker-Images oder die meisten Hosting-Panels.

PHP-Versionen und ihre Enddaten

Version	Veröffentlicht	Bugfixes bis	Sicherheitsfixes bis
PHP 8.1 und älter	2021 oder früher	Beendet	Beendet (8.1 am 31. Dezember 2025)
PHP 8.2	8. Dezember 2022	Beendet am 31. Dezember 2024	31. Dezember 2026
PHP 8.3	23. November 2023	Beendet am 31. Dezember 2025	31. Dezember 2027
PHP 8.4	21. November 2024	31. Dezember 2026	31. Dezember 2028
PHP 8.5	20. November 2025	31. Dezember 2027	31. Dezember 2029

Jede PHP-Version erhält zwei Jahre lang Bugfixes und danach zwei Jahre lang nur Sicherheitsfixes. Wenn Sie 8.1 oder älter einsetzen, sind Sie bereits ohne Fixes: Planen Sie dieses Upgrade zuerst.

Auf welche Version sollten Sie wechseln?

• PHP 8.4 für die meisten Websites. Es wird bis Ende 2028 unterstützt, Sie müssen das Ganze also nächstes Jahr nicht wiederholen. WordPress 6.8 und neuer unterstützen es.
• PHP 8.3, wenn etwas 8.4 blockiert. Ein altes Plugin, ein Theme oder eine Bibliothek, die nicht aktualisiert wurde. Es verschafft Ihnen ein Jahr, bis zum 31. Dezember 2027.
• PHP 8.5, wenn Sie neu anfangen oder Ihr Stack aktuell ist. WordPress unterstützt es ab 6.9; Laravel 12 und 13 unterstützen es. Viele Plugins werden später auf 8.5 getestet als auf 8.4.

Bei Laravel gehören die PHP-Version und die Laravel-Version zusammen. Laravel 11 läuft auf PHP 8.2 bis 8.4, aber seine eigenen Sicherheitsfixes endeten am 12. März 2026. Laravel 12 läuft auf 8.2 bis 8.5, mit Sicherheitsfixes bis 24. Februar 2027. Laravel 13 braucht PHP 8.3 oder neuer. Eine App auf Laravel 10 oder 11 ist ein guter Zeitpunkt, beides gemeinsam zu aktualisieren.

Prüfen, welche PHP-Version Sie nutzen

• WordPress: Werkzeuge, Website-Zustand, Bericht, dann zeigt der Abschnitt Server die PHP-Version.
• Hosting-Panel: cPanel, Plesk, DirectAdmin und die meisten Managed-Hoster zeigen sie unter den PHP-Einstellungen oder bei „Select PHP version“.
• Ihr eigener Server: php -v auf der Kommandozeile. Der Webserver kann eine andere Version nutzen als die Kommandozeile, prüfen Sie deshalb auch eine phpinfo()-Seite und löschen Sie sie gleich danach.
• Docker: Sehen Sie sich die FROM-Zeile in Ihrem Dockerfile an (zum Beispiel php:8.2-fpm) oder führen Sie docker run --rm your-image php -v aus.

Unser MigrateXtoY-Leitfaden zum Support-Ende von PHP 8.2 geht genauer darauf ein, was je Plattform bricht (WordPress, WooCommerce, Magento, Laravel, Drupal), und nennt hilfreiche Tools.

Was beim Upgrade kaputtgehen kann

Der Schritt von 8.2 auf 8.3 oder 8.4 ist klein im Vergleich zum Sprung von PHP 7 auf 8. Die meisten Änderungen sind neue Deprecation-Warnungen, die Ihre Logs füllen, die Website aber nicht stoppen. Was eine Website tatsächlich bricht:

• Plugins und Themes, die jahrelang nicht aktualisiert wurden. Sie sind die häufigste Ursache für einen weißen Bildschirm oder einen kritischen Fehler nach einem PHP-Wechsel.
• Entfernte Erweiterungen. PHP 8.4 liefert IMAP, OCI8, PDO_OCI und Pspell nicht mehr mit; sie sind nach PECL umgezogen. Ein Plugin, das mit imap_open() ein Postfach ausliest, oder eine App, die mit Oracle spricht, braucht die Erweiterung separat oder einen Ersatz.
• Individualcode mit ignorierten Warnungen. Deprecations aus früheren Versionen werden in späteren zu Fehlern. Wenn Ihre Logs voll davon sind, beheben Sie sie jetzt.
• Composer-Abhängigkeiten mit striktem PHP-Bereich. composer why-not php 8.4 listet die Pakete auf, die das Upgrade blockieren.

So upgraden Sie ohne Ausfallzeit

1. Erstellen Sie ein Backup von Dateien und Datenbank, gespeichert außerhalb des Servers.
2. Aktualisieren Sie zuerst alles andere: den WordPress-Core, Plugins und Themes oder Ihre Laravel- und Composer-Pakete. Entfernen Sie Plugins, die Sie nicht nutzen.
3. Testen Sie auf einer Kopie. Die meisten Hoster bieten eine Staging-Website. Stellen Sie die Kopie auf die neue PHP-Version um und aktivieren Sie das Fehler-Logging (WP_DEBUG_LOG in WordPress, das Laravel-Log bei Laravel).
4. Klicken Sie durch alles, was Geld einbringt: Formulare, Checkout, Zahlungen, Login, Suche, geplante Aufgaben und die E-Mails, die Ihre Website versendet.
5. Lesen Sie das Fehlerlog. Beheben Sie schwere Fehler vor dem Livegang; notieren Sie die Deprecations für später.
6. Stellen Sie die Live-Website zu einer ruhigen Zeit um und lassen Sie die alte Version im Hosting-Panel wählbar, damit Sie schnell zurück können.
7. Bei Docker: Ändern Sie die FROM-Zeile, bauen Sie mit docker build --pull neu, prüfen Sie vor dem Build den freien Speicherplatz und deployen Sie jeden Container neu.

Geht die Website nach einem Wechsel trotzdem kaputt, behandelt unsere Checkliste zu einer WordPress-Website, die offline gegangen ist, den Wiederherstellungsmodus und den Weg zurück.

Aus unserer eigenen Arbeit: zwei Arten, wie eine PHP-Frist ankommt

Am 21. Oktober haben wir die Laravel-Plattform eines Kunden gegen PHP2Shell gepatcht. Sie läuft in Docker auf PHP 8.2, auf einem Cloud-Server. Für das Update waren zuerst drei Korrekturen nötig: Das offizielle Docker-Image hatte die gepatchte Version noch nicht, also haben wir das Basis-Image selbst gebaut; die Festplatte war zu 100 % voll, also haben wir sie von 15 auf 30 GB verdoppelt; und aus dem Internet war mehr als nur die Website erreichbar, also haben wir alle Ports außer 80 und 443 geschlossen. Noch am selben Tag lief die Plattform auf PHP 8.2.35. Aber 8.2.35 verschafft nur Zeit: Dieselbe Plattform hat jetzt die Frist 31. Dezember, und ein Upgrade ist im November leichter als beim nächsten Notfall.

Die zweite Art ist der Maßstab. Für eine niederländische Designagentur betreuen wir mehr als 50 WordPress-Websites unter ihrem Namen, seit Juli 2026 etwa 10 Stunden im Monat. Als PHP2Shell veröffentlicht wurde, haben wir innerhalb von Minuten auf ihren Websites gehandelt. Ein Support-Ende ist die langsame Version derselben Aufgabe: eine Liste von Websites, eine Frist und eine Prüfung pro Website. Ob Sie eine Website betreiben oder fünfzig, die Arbeit ist dieselbe: wissen, welche Version jede Website nutzt, testen, bevor Ihr Hoster für Sie umstellt, und einen Weg zurück behalten.

Mehr dazu, was im Oktober passiert ist: PHP2Shell: Was Sie jetzt für Ihre WordPress- oder Laravel-Website tun sollten.

Was es kostet

Option	Preis zzgl. MwSt.	Gut zu wissen
Selbst machen	Ihre Zeit	Passt für eine WordPress-Website mit aktuellen Plugins und einer Staging-Kopie bei Ihrem Hoster.
Ihr Hosting-Anbieter	Oft inklusive	Die meisten Hoster stellen die Version um; wenige testen Ihre Website oder beheben, was kaputtgeht.
WDDW-Stundenkontingent	€910 für 14 Stunden	Vorausbezahlte Stunden für Upgrade, Tests und Korrekturen, mit Restzeit für regelmäßige Updates.
WDDW-Soforthilfe	€75/Stunde, ohne Mindestabnahme	Wenn der Hoster bereits umgestellt hat und die Website down ist: Ein Senior-Entwickler startet am selben Tag.

Sollen PHP- und Plugin-Updates jeden Monat erledigt werden statt in Eile? Lesen Sie, was Website-Wartung kostet. Agenturen mit vielen Kundenwebsites lesen in WordPress Wartung für Agenturen, wie wir das unter ihrem Namen machen.

Upgraden Sie vor der Frist

Senden Sie uns Ihre Website-Adresse. Ein Senior-Entwickler prüft, welche PHP-Version läuft, testet auf einer Kopie mit PHP 8.4, behebt, was kaputtgeht, und stellt die Live-Website mit einem Weg zurück um. WordPress, WooCommerce, Laravel oder Docker: Wir arbeiten mit dem Hosting, das Sie haben. Kontaktieren Sie uns → oder, wenn die Website schon down ist, holen Sie sich Soforthilfe.

Sie führen eine Agentur? Wir upgraden die Websites Ihrer Kunden unter Ihrem Namen, unter NDA. Bis 31. Dezember: 2 Stundenkontingente kaufen, 1 gratis dazu. Zum Agenturangebot →

Fakten geprüft am 6. November 2026. Quellen: PHP supported versions, PHP 8.4 migration guide, WordPress PHP compatibility, Laravel support policy.