DE
Kontakt
Kontakt

Insights

Supportende für PHP 8.2 am 31. Dezember 2026: was Sie in der verbleibenden Zeit tun können

Veröffentlicht amStand der Daten und Versionen: 25. Oktober 2026.

Das PHP-Projekt liefert für PHP 8.2 noch bis zum 31. Dezember 2026 Sicherheitsupdates (php.net, Supported Versions). Die Version erschien am 8. Dezember 2022, der aktive Support endete am 31. Dezember 2024, seitdem gibt es nur noch Sicherheitsupdates. Aktuell ist 8.2.35 vom 21. Oktober 2026. Nach dem 31. Dezember veröffentlicht php.net kein weiteres 8.2-Release. Alle Termine zum Supportende von PHP, Laravel und Symfony finden Sie in unserem EOL-Kalender.

Das Oktober-Release war keine Routine. Laut Sicherheitsmeldung auf php.net vom 21. Oktober 2026 schließt PHP 8.2.35 zwei kritische Sicherheitslücken, CVE-2026-109618 und CVE-2026-109619, die eine Codeausführung aus der Ferne ohne Anmeldung ermöglichen können. Dieselben Fixes kamen mit 8.3.36, 8.4.27 und 8.5.12. Auf php.net heißt es dazu, es gebe keine vollständigen Gegenmaßnahmen, ein Update sei die einzige sichere Wahl. Wird eine solche Lücke im Januar gefunden, kommt der Fix für 8.2 nicht mehr.

Dieser Artikel zeigt, was sich am 1. Januar ändert, wie Sie herausfinden, was Ihre Anwendung auf 8.2 festhält, auf welche Version Sie wechseln sollten und was zu tun ist, wenn Sie es nicht rechtzeitig schaffen.

Was sich am 1. Januar 2027 ändert

Abgeschaltet wird nichts. Die Anwendung läuft genauso weiter wie bisher. Anders wird es erst, wenn jemand die nächste Sicherheitslücke in PHP selbst findet, so wie im Oktober: Der Fix erscheint für die unterstützten Versionszweige, nicht für 8.2. Schon in der Phase, in der es nur noch Sicherheitsupdates gibt, veröffentlicht php.net Releases nur bei Bedarf („on an as-needed basis“). Sie verlieren also jeden Fix, der nach dem 31. Dezember nötig wird, egal wie viele es sind.

Derselbe Termin ist noch in drei weiteren Punkten wichtig.

  • PHP 8.4 verlässt den aktiven Support am 31. Dezember 2026 und bekommt danach nur noch Sicherheitsupdates, bis zum 31. Dezember 2028. Ab Januar erhalten nur noch 8.5 und 8.6 reguläre Bugfixes. Laut Release-Plan für PHP 8.6 (wiki.php.net) ist die finale Version für den 19. November 2026 vorgesehen.
  • Plattformen haben eigene Termine. Google App Engine Standard beendet den Support für die Runtime php82 am 31. Dezember 2026 und nimmt sie am 31. Dezember 2027 außer Betrieb; ab dann funktionieren Deployments auf dieser Runtime nicht mehr. AWS Elastic Beanstalk listet die Plattform PHP 8.2 zur Abschaltung am 31. März 2027. Manche Hoster verlangen einen Aufpreis, wenn sie eine alte Version weiter anbieten, die das PHP-Projekt nicht mehr patcht: mittwald berechnet derzeit 5 € netto pro PHP-Version, Projekt und Monat für Versionen, die die Community nicht mehr pflegt (heute 8.1 und älter), und 15 € in einer zweiten Phase ohne garantierte Fixes.
  • Distributionspakete richten sich nicht nach php.net. Debian 12 liefert PHP 8.2 als Standard-PHP aus und pflegt ein eigenes Paket php8.2. Der Long Term Support für Debian 12 läuft planmäßig bis zum 30. Juni 2028 (Debian-LTS-Wiki). Kommt Ihr PHP aus den Debian-Repositories, sehen Sie im Debian Security Tracker nach php8.2, bevor Sie mit dem 31. Dezember planen. Ihr Stichtag ist dann womöglich der von Debian, nicht der von php.net.

Schritt 1: Prüfen, was wirklich läuft

Prüfen Sie das auf dem Produktivsystem, und zwar sowohl auf der Kommandozeile als auch im Prozess, der die Webanfragen bedient. Die beiden können unterschiedliche Versionen haben:

php -v
php -m
ps aux | grep -E "php-fpm" | head -3

Unter Debian und Ubuntu zeigt der PHP-FPM-Masterprozess den Pfad seiner Konfiguration, zum Beispiel /etc/php/8.2/fpm/php-fpm.conf. Das ist die Version, auf die Ihre Nutzer treffen. Notieren Sie auch, woher das Binary kommt: aus einem Distributionspaket, aus einem Repository eines Drittanbieters, über ein Docker-Image-Tag oder über eine Einstellung im Hosting-Panel. Jeder dieser Wege hat seinen eigenen Upgrade-Pfad und sein eigenes Supportende.

Schritt 2: Herausfinden, was Sie auf 8.2 hält

Die meisten Anwendungen bleiben auf 8.2, weil ein Framework oder eine Abhängigkeit sie dort festhält. Welche, verrät Composer:

composer why-not php 8.4

Der Befehl listet die installierten Pakete, deren PHP-Versionsanforderung 8.4 ausschließt. Das ist der Mindestumfang der Arbeit: Ein Paket mit offener Anforderung wie >=7.2 taucht hier nicht auf und kann unter 8.4 trotzdem brechen.

Prüfen Sie danach das Framework, denn es setzt die Obergrenze:

FrameworkUnterstützte PHP-VersionenSicherheitsupdates bis
Laravel 108.1 bis 8.3beendet am 4. Februar 2025
Laravel 118.2 bis 8.4beendet am 12. März 2026
Laravel 128.2 bis 8.524. Februar 2027
Laravel 138.3 bis 8.517. März 2028
Symfony 6.48.1 oder neuerNovember 2027
Symfony 7.48.2 oder neuerNovember 2029

Quellen: laravel.com/docs/13.x/releases und symfony.com/releases, beide geprüft am 25. Oktober 2026.

Eine Anwendung mit Laravel 10 kommt höchstens auf PHP 8.3, und Laravel 10 selbst bekommt seit Februar 2025 keine Sicherheitsupdates mehr. In diesem Fall sind PHP-Upgrade und Framework-Upgrade ein einziges Projekt, und es ist günstiger, sie auch als eines zu planen.

Bleiben die Extensions. Mit PHP 8.4 sind IMAP, OCI8, PDO_OCI und PSpell aus der PHP-Distribution nach PECL umgezogen. Listet php -m die Extension imap und ruft Ihr Code imap_open() auf, lösen Sie das zuerst. Ein Shared Hoster, der Sie auf 8.4 umstellt, bietet die PECL-Version womöglich gar nicht an.

Schritt 3: Die Zielversion wählen

ZielSicherheitsupdates bisWas Sie ab Januar 2027 gewinnen
8.331. Dezember 2027ein Jahr, schon jetzt nur noch Sicherheitsupdates
8.431. Dezember 2028zwei Jahre
8.531. Dezember 2029drei Jahre, Bugfixes bis Ende 2027

In den meisten Codebasen ist der Schritt von 8.2 auf 8.4 kaum mehr Arbeit als der auf 8.3, deshalb lohnt sich der Umweg über 8.3 selten. Wir nehmen standardmäßig 8.4 und wählen 8.5, wenn alle Abhängigkeiten es bereits zulassen; das zeigt composer why-not php 8.5. Ein Release, das erst wenige Wochen alt ist, wie 8.6 im Dezember, ist ein schlechtes Ziel, wenn eine Frist drängt. Geben Sie den Bibliotheken Zeit, nachzuziehen.

Schritt 4: Wissen, was zwischen 8.2 und 8.4 bricht

PHP 8.3 hat wenig geändert, was typische Webanwendungen betrifft. Die meiste Arbeit steckt in PHP 8.4, und der Großteil davon sind Deprecations:

  • Implizit nullable Parameter. function find(User $user = null) ist deprecated und wird zu ?User $user = null. In älteren Codebasen ist das mit großem Abstand die häufigste Änderung, und sie ist rein mechanisch.
  • Session-Einstellungen. session.sid_length und session.sid_bits_per_character sind deprecated. Prüfen Sie php.ini, .user.ini-Dateien und Aufrufe von ini_set().
  • trigger_error() mit E_USER_ERROR ist deprecated. Werfen Sie stattdessen eine Exception.
  • E_STRICT gibt es als Fehlerstufe nicht mehr, die Konstante ist deprecated. Alte, selbst geschriebene Error-Handler erwähnen sie oft.
  • Strengeres Verhalten. exit() wirft bei ungültigen Argumenttypen einen TypeError, round() lehnt ungültige Rundungsmodi ab, und PDO-MySQL-Attribute wie ATTR_EMULATE_PREPARES erwarten jetzt boolesche Werte.

Standardmäßig protokolliert PHP Deprecations und macht weiter. Prüfen Sie zuerst Ihren Error-Handler: Ältere Frameworks und viele selbst geschriebene set_error_handler()-Callbacks machen aus jeder Notice eine Exception, und dann wird die erste Deprecation zum Fatal Error. Auch mit dem Standard-Handler kann eine Anwendung unter 8.4 alle Tests bestehen und trotzdem Tausende Deprecation-Meldungen pro Stunde schreiben. Lassen Sie sie unter 8.4 im Staging laufen, mit Logging für E_DEPRECATED, klicken Sie sich gründlich durch und lesen Sie das Log, bevor Sie das Produktivsystem umstellen.

Schritt 5: Die mechanische Arbeit den Werkzeugen überlassen

Rector wendet PHP-Versionssets auf Ihren Code an, prüft dabei aber auch, auf welcher PHP-Version Ihr Projekt läuft, und überspringt jede Regel, die eine neuere braucht. Ohne withPhpVersion() nimmt Rector diese Version aus der Untergrenze von require.php in der composer.json. Deshalb verhält sich ->withPhpSets(php84: true) je nach Versionsanforderung unterschiedlich:

  • mit "php": "^8.2" wendet Rector nur die Regeln bis 8.2 an. Die 8.4-Regeln werden übersprungen, auch die, die nullable Parameter explizit macht;
  • mit "php": "^8.4" wendet Rector alles bis 8.4 an, auch Syntax, die es erst ab 8.3 und 8.4 gibt, etwa typisierte Klassenkonstanten. Dieser Code läuft unter 8.2 nicht.

Behalten Sie während der Umstellung "php": "^8.2" und führen Sie die eine 8.4-Regel, die Sie jetzt brauchen, mit einer separaten, kleinen Konfiguration aus: ->withRules([ExplicitNullableParamTypeRector::class])->withPhpVersion(PhpVersion::PHP_84). Das ?User, das sie schreibt, funktioniert ab PHP 7.1. Setzen Sie die Anforderung erst am Tag der Umstellung auf ^8.4 und lassen Sie dann das komplette php84-Set laufen. Starten Sie jedes Mal zuerst mit --dry-run und sehen Sie sich den Diff an. In einer großen Codebasis ist der Diff lang, und fast alles darin ist korrekt.

PHPStan 2 akzeptiert einen Bereich, phpVersion: {min: 80200, max: 80400}, und meldet dann einen guten Teil dessen, was auf einer der beiden Versionen bricht. Nehmen Sie 8.4 neben 8.2 in die CI-Matrix auf, damit bis zur Umstellung jede Änderung auf beiden Versionen getestet wird.

Was Ihnen die Werkzeuge nicht liefern, ist der Nachweis, dass die Anwendung noch tut, was sie bisher getan hat. Gibt es keine Tests für die Abläufe, mit denen Sie Geld verdienen (Login, Checkout, Rechnungsstellung, der nächtliche Export), schreiben Sie ein paar, die das heutige Verhalten festhalten, bevor Sie die Laufzeitumgebung darunter austauschen.

Wenn Sie es bis zum 31. Dezember nicht schaffen

Das kommt vor, und es gibt vernünftige Wege, damit umzugehen, in dieser Reihenfolge:

  1. Wenn Sie Distributionspakete nutzen, klären Sie, wie lange Ihre Distribution php8.2 patcht. Vielleicht haben Sie mehr Zeit, als php.net vermuten lässt.
  2. Kaufen Sie bewusst Zeit. Gepatchte PHP-Builds von Anbietern wie Freexian, TuxCare oder Zend oder der Extended Support eines Hosters versorgen den Interpreter weiter mit Sicherheitsupdates. Ihr Framework und Ihre Composer-Abhängigkeiten patchen sie nicht. Betrachten Sie sie deshalb als Brücke mit festem Enddatum.
  3. Verkleinern Sie die Angriffsfläche, solange Sie daran arbeiten. Halten Sie alles andere aktuell, lassen Sie composer audit jede Woche als geplanten CI-Job laufen, deaktivieren Sie PHP-Extensions, die Sie nicht nutzen, und legen Sie den Umstellungstermin fest.

Ein paar Wochen mit 8.2 im Januar sind ein beherrschbares Risiko, wenn der Termin für die Umstellung feststeht und schriftlich festgehalten ist.

Ein Plan für die verbleibenden Wochen

Ab Ende Oktober bleiben rund neun Wochen, und bei den meisten Teams fallen die letzten zwei in die Feiertage. Ein Plan, der passt: eine Woche für Schritt 1 und 2, eine Woche für die Entscheidung über die Zielversion und die Aktualisierung der Abhängigkeiten, zwei bis drei Wochen für Codeänderungen und Tests, ein bis zwei Wochen im Staging, dann die Umstellung des Produktivsystems vor Mitte Dezember, mit schriftlich festgelegtem Rollback. Steht auf der Liste aus Schritt 2 ein Framework-Upgrade, rechnen Sie damit, dass die Umstellung ins erste Quartal rutscht, und organisieren Sie die Brücke jetzt.

Wenn Sie zu dieser Liste eine zweite Meinung möchten, schicken Sie uns Ihre composer.lock. Wir antworten mit den Supportterminen für Ihre PHP- und Framework-Versionen und sagen Ihnen, wie viele bekannte Sicherheitsmeldungen und nicht mehr gepflegte Pakete die Datei zeigt, kostenlos und ohne Zugriff auf Ihren Code. Brauchen Sie das vollständige Bild, ergänzt der Debt Check (300 €) einen kurzen Fragebogen. Innerhalb von drei Arbeitstagen erhalten Sie einen Bericht: die Risiken nach Priorität, was den Wechsel auf eine unterstützte Version blockiert, und einen empfohlenen Weg mit Preisrahmen. Einen Takeover oder Care können wir auf dieser Grundlage oft direkt zum Festpreis anbieten; für ein Upgrade nennen wir den Festpreis nach einem Code Audit.

Quellen

Geprüft am 25. Oktober 2026.

Eine zweite Meinung zu Ihrer Anwendung?

Schicken Sie uns Ihre composer.lock. Wir antworten mit den Supportterminen für Ihre PHP- und Framework-Versionen und sagen Ihnen, wie viele bekannte Sicherheitsmeldungen und nicht mehr gepflegte Pakete die Datei zeigt, kostenlos und ohne Zugriff auf Ihren Code.

composer.lock senden Debt Check buchen