Inventar der Anwendung
PHP-Version, Erweiterungen, Bibliotheken und Abhängigkeiten, auch solche ohne Betreuer.
PHP-Update auf PHP 8, Schritt für Schritt und mit Tests
Für PHP 8.2 enden die Sicherheits-Updates am 31.12.2026, für PHP 8.1 und älter sind sie bereits beendet (Stand: 2026-10). Wir bringen gewachsene PHP-Anwendungen, auch mit Smarty-Templates und jQuery-Frontend, auf PHP 8.4 oder 8.5 und testen jede Stufe.
- PHP, Smarty und Slim seit 2012
- Antwort innerhalb eines Werktags
Wenn Hoster, Versicherung oder Audit nach Ihrer PHP-Version fragen
Viele PHP-Anwendungen laufen jahrelang ohne Pflege, bis jemand nach der Version fragt. Das sind typische Anlässe für ein Update:
- Der Hoster berechnet einen Aufschlag für Ihre PHP-Version oder kündigt an, sie abzuschalten.
- Ein Kunde, ein Audit oder die Versicherung fragt nach unterstützten Versionen.
- Ein früherer Update-Versuch ist gescheitert, seitdem fasst niemand die Anwendung an.
- Der Entwickler ist gegangen, und die Anwendung läuft noch auf PHP 7.4 oder älter.
Welche Version läuft, zeigt das Hosting-Panel oder der Befehl php -v auf dem Server. Die Support-Termine aller Versionen stehen weiter unten und unter PHP-Versionen und Support-Termine.
Warum laufende PHP-Updates zählen: PHP2Shell im Oktober 2026
Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Korrekturen für zwei kritische Lücken im PHP-Kern, bekannt als PHP2Shell. Details kursierten schon einen Tag vorher im Netz. Betroffen war jede PHP-Installation, die Webanfragen beantwortet, ob mit PHP-FPM, Apache mod_php, php-cgi, FrankenPHP oder LiteSpeed. Ein Angreifer brauchte weder Konto noch Zugangsdaten, nur eine Anfrage an den Webserver.
- CVE-2026-109618, Codeausführung aus der Ferne nach Speichermangel: Geht PHP während einer Anfrage der Speicher aus, kann es mitten im Aufbau interner Anfragedaten abbrechen. Die Aufräumroutine behandelt die halbfertigen Daten danach als gültig.
- CVE-2026-109619, Codeausführung aus der Ferne über veralteten Zustand: Interner Zustand einer Anfrage kann bestehen bleiben, nachdem sein Speicher freigegeben wurde. Eine spätere Anfrage an denselben Worker kann ihn nutzen, bevor er neu gesetzt wird.
Noch am selben Tag wurden Angriffsversuche beobachtet. Weil aktualisierte Pakete für viele Server fehlten, nahmen Behörden, Polizeiportale und ein großes Universitätsklinikum in Deutschland ihre Websites vorsorglich vom Netz, ebenso Organisationen in anderen europäischen Ländern. Das BSI hatte empfohlen, Websites bis zum Update abzuschalten.
Auf einer unterstützten Version genügte ein kleines Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Für PHP 8.1 und älter gab es keine offizielle Version, nur minimale Korrekturen im Quellcode oder Pakete von LTS-Anbietern (Stand: 2026-10).
Quellen: Sicherheitshinweis des PHP-Projekts vom 21.10.2026 (öffnet in einem neuen Fenster), GHSA-w8hw-w9fx-j79w (öffnet in einem neuen Fenster) und GHSA-6wmf-4rv5-p3rp (öffnet in einem neuen Fenster).
Fazit: Wer laufend aktualisiert, testet eine neue Unterversion in Stunden und spielt sie ein. Ein Sprung über mehrere Versionen braucht Tage bis Wochen.
Wie die Migration auf PHP 8 abläuft: vom Inventar bis zum Umschalten
-
Review: was sich in der Anwendung für PHP 8 ändern muss
Wir erfassen Version, Erweiterungen, Bibliotheken, Smarty, jQuery, Datenbank und Server. Wir prüfen den Code auf Inkompatibilitäten und zeigen, was unter PHP 8 bricht. Das Ergebnis ist ein Stufenplan mit Aufwand in Arbeitstagen.
-
Testumgebung und Testfälle
Wir richten eine Testumgebung mit einer Kopie von Code und Datenbank ein und lassen Ihr Produktivsystem unverändert. Für die kritischen Abläufe legen wir vor jeder Änderung Testfälle an, damit Abweichungen sichtbar werden.
-
Update in Stufen
Wir heben die Anwendung in Stufen an, meist eine Version nach der anderen, etwa von 7.4 über 8.0 und 8.1 bis zur Zielversion. Nach jeder Stufe laufen die Testfälle, damit die Anwendung lauffähig bleibt.
-
Umschalten mit Rückweg
Wir stellen die Produktion in einem ruhigen Zeitfenster um und halten einen geprüften Rückweg bereit. Danach beobachten wir Fehler-Logs und Antwortzeiten und beheben, was auffällt.
Was das Ergebnis des Reviews enthält
-
-
Liste der Inkompatibilitäten
Stellen im Code, die unter PHP 8 brechen, geordnet nach Risiko und Aufwand.
-
Stufenplan mit Zielversion
Reihenfolge der Schritte, Zielversion 8.4 oder 8.5 und Aufwand in Arbeitstagen.
-
Testbericht nach jeder Stufe
Was geprüft wurde, was sich verändert hat und was noch offen ist.
-
Rückweg und Übergabe
Ablauf des Umschaltens, der geprüfte Weg zurück und die Dokumentation des neuen Stands.
Bis wann welche PHP-Version Sicherheits-Updates erhält
| Datum | Ereignis | Quelle |
|---|---|---|
| 2018-12-31 | PHP 5.6: Ende der Sicherheits-Updates. | php.net (öffnet in einem neuen Fenster) |
| 2019-01-10 | PHP 7.0: Ende der Sicherheits-Updates. | php.net (öffnet in einem neuen Fenster) |
| 2019-12-01 | PHP 7.1: Ende der Sicherheits-Updates. | php.net (öffnet in einem neuen Fenster) |
| 2020-11-30 | PHP 7.2: Ende der Sicherheits-Updates. | php.net (öffnet in einem neuen Fenster) |
| 2021-12-06 | PHP 7.3: Ende der Sicherheits-Updates. | php.net (öffnet in einem neuen Fenster) |
| 2022-11-28 | PHP 7.4: Ende der Sicherheits-Updates. | php.net (öffnet in einem neuen Fenster) |
| 2023-11-26 | PHP 8.0: Ende der Sicherheits-Updates. | php.net (öffnet in einem neuen Fenster) |
| 2025-12-31 | PHP 8.1: Ende der Sicherheits-Updates. | php.net (öffnet in einem neuen Fenster) |
| 2026-12-31 | PHP 8.2: Ende der Sicherheits-Updates. | php.net (öffnet in einem neuen Fenster) |
| 2027-12-31 | PHP 8.3: Ende der Sicherheits-Updates. | php.net (öffnet in einem neuen Fenster) |
| 2028-12-31 | PHP 8.4: Ende der Sicherheits-Updates. Mögliche Zielversion. | php.net (öffnet in einem neuen Fenster) |
| 2029-12-31 | PHP 8.5: Ende der Sicherheits-Updates. Mögliche Zielversion. | php.net (öffnet in einem neuen Fenster) |
Was beim Versionssprung typischerweise bricht
| Versionssprung | Was typischerweise bricht | Was wir prüfen |
|---|---|---|
| Von PHP 5.6 auf 7.x | Die alte mysql-Schnittstelle und die ereg-Funktionen sind entfernt, mcrypt liegt ab 7.2 nicht mehr im Kern. Die Datenbankschicht braucht mysqli oder PDO. | Alle Datenbankzugriffe, Verschlüsselung und Hilfsbibliotheken. |
| Von PHP 7.4 auf 8.0 | Vergleiche von Zahlen und Text liefern andere Ergebnisse, etliche frühere Warnungen werden zu Fehlern, und Funktionen wie each() und create_function() sind entfernt. | Validierung, Fehlerbehandlung, Datenbankzugriffe und Konstruktoren im alten PHP-4-Stil. |
| Zwischen PHP 8.1 und 8.5 | Meist läuft die Anwendung weiter, im Log erscheinen aber Hinweise auf veraltete Konstrukte, zum Beispiel null als Funktionsargument, dynamische Eigenschaften oder utf8_encode(). | Wir sammeln die Hinweise und beseitigen sie, bevor die Konstrukte entfernt werden. |
| Rund um den Code | Zeichenkodierung (latin1 oder utf8mb4), Bibliotheken ohne Betreuer für PDF, Excel oder SOAP, geplante Aufgaben und die Datenbankversion. | Diese Punkte prüfen wir schon im Inventar, nicht erst im Test. |
Smarty, jQuery und Datenbank prüfen wir mit
Smarty. Das Smarty-Projekt liefert Sicherheitskorrekturen nur für die jeweils neueste Unterversion von Smarty 4 und 5, Smarty 2 und 3 werden nicht mehr gepflegt (Stand: 2026-10). Der Aufwand steckt meist in Templates mit eigenen Plugins oder {php}-Blöcken.
jQuery. Es läuft im Browser und hängt nicht an PHP, steckt aber oft in denselben Templates. jQuery 1.x und 2.x werden nicht mehr unterstützt (Stand: 2026-10). Meist genügt der Weg über jQuery 3 oder 4 mit jQuery Migrate.
Datenbank. Wir prüfen die Version von MySQL oder MariaDB im selben Inventar wie den Code und nennen eine unterstützte Zielversion.
Alle Änderungen je Version listen die Migrationsleitfäden des PHP-Handbuchs (öffnet in einem neuen Fenster) (englisch). Mehr zur Arbeit unserer Ingenieure mit PHP finden Sie auf der Seite PHP-Anwendungen übernehmen, aktualisieren und weiterbetreiben, die Systemtypen unter Erfahrung.
Erfahrung unserer Ingenieure mit PHP, Smarty und Datenbanken
- PHP
- Seit 2012, mit Smarty, Slim und WordPress
- Full Stack und DevOps
- Seit 2012, vom Code bis zum Server
- Datenbanken
- MySQL und MariaDB, auch im Galera-Cluster; Migrationen etwa von Firebird nach MariaDB
- Server
- Linux, Nginx, Apache und Docker
So starten wir das PHP-Update
- Code, Zugangsdaten und Dokumentation bleiben bei Ihnen.
- Am Ende erhalten Sie eine Übergabe, mit der auch ein anderer Dienstleister weiterarbeiten kann.
- Wir sagen Ihnen auch, wenn sich ein Update nicht lohnt, etwa weil die Anwendung bald abgelöst wird.
Und wenn bei uns jemand ausfällt? Die Dokumentation erstellen wir auf Wunsch. Das Repository liegt in der Regel bei Ihnen. Eine Vertretung stellen wir auf Wunsch.
Das PHP-Update gehört zu unserer Leistung Migration und Modernisierung.
Der erste Schritt: Legacy-Review oder PHP-8-Kompatibilitätsscan
Legacy-Review
Für Unternehmen mit einem System, das niemand mehr genau kennt: vor einem Update, vor einer Migration oder beim Wechsel des Dienstleisters.
- Inventar der Versionen und Abhängigkeiten
- Landkarte aus Anwendung, Datenbank, Server und E-Mail
- Risikoregister zu Sicherheit, Support und Wissen
- Bewertung der Backups und der Wiederherstellung
- Empfehlung „bleiben, Version anheben oder migrieren“ mit Optionsmatrix, die auch „in den Container“ und „als API bereitstellen“ enthält
- Aufwandsschätzung in Tagen
Der Preis gilt für ein System, also eine Anwendung mit ihrer Datenbank und ihrem Server. Weitere Systeme bepreisen wir einzeln.
Was das Ergebnis enthält
Ein schriftlicher Bericht mit Bestandsaufnahme, Risikoregister, Empfehlung und Aufwandsschätzung. Der Bericht gehört Ihnen.
PHP-8-Kompatibilitätsscan
Für Unternehmen mit einer gewachsenen PHP-Anwendung, die vor dem Update auf PHP 8 wissen wollen, was bricht und wie viel Arbeit es macht.
- Inventar von PHP-Version, Erweiterungen, Bibliotheken und Datenbank
- Prüfung des Codes auf Stellen, die unter PHP 8 nicht mehr laufen
- Smarty-Templates und jQuery-Frontend im selben Durchgang
- Liste der Inkompatibilitäten nach Risiko und Aufwand
- Stufenplan bis zur Zielversion mit Aufwandsschätzung in Arbeitstagen
Umfang und Preis legen wir im Erstgespräch fest und bestätigen sie schriftlich, bevor wir beginnen. Das Update selbst folgt auf Wunsch als eigener Auftrag.
Was das Ergebnis enthält
Eine schriftliche Liste der Inkompatibilitäten mit Stufenplan und Aufwandsschätzung. Die Liste gehört Ihnen.
Ein Fall aus unserer Arbeit
-
PHP 8.2 und das 30-Sekunden-Limit: Seiten warteten auf die Sitzungssperre
Internetportale · 4 Stunden
Nach dem Update von PHP 7.4 auf PHP 8.2 lud dieselbe Seite einmal normal und brach einmal nach 30 Sekunden ab. Wir haben beide Versionen nebeneinander nachgestellt und die Ursache gefunden: Rund 20 parallele AJAX-Aufrufe eines Nutzers warteten nacheinander auf die Sperre der Sitzungsdatei. Behoben mit einer Zeile pro Skript, ohne die Anwendung umzuschreiben.
Fragen zum Update auf PHP 8
Müssen wir unsere PHP-Anwendung für PHP 8 neu schreiben?
Meistens nicht. Liegt das Problem nur an der PHP-Version, aktualisieren wir die Anwendung in Stufen und lassen ihre Logik unverändert. Ein Neuschreiben lohnt sich selten.
Es kommt infrage, wenn das Framework nicht mehr gepflegt wird, es keine Tests gibt und sich die Geschäftsregeln aufschreiben lassen. Ob das bei Ihnen zutrifft, zeigt der Legacy-Review mit einer Empfehlung und einer Aufwandsschätzung in Arbeitstagen.
Was kostet das Update auf PHP 8, und wie lange dauert es?
Eine belastbare Zahl gibt es erst nach dem Blick in Ihre Anwendung. Aufwand und Dauer hängen vom Zustand ab, nicht von der Größe allein. Entscheidend sind die Ausgangsversion, Erweiterungen und Bibliotheken ohne Betreuer, Smarty, Datenbank, Zeichenkodierung und vorhandene Tests.
Feste Preise nennen wir für die Einstiegsprodukte, hier den Legacy-Review mit PHP-8-Inventar. Er liefert die Aufwandsschätzung in Arbeitstagen. Danach machen wir Ihnen ein Angebot für das Update: zum Festpreis, wenn der Umfang klar ist, sonst nach Aufwand.
Läuft die Anwendung nach dem Update genauso wie vorher?
Das ist das Ziel, und die Tests belegen es für die geprüften Abläufe. Bevor wir etwas ändern, legen wir Testfälle für die kritischen Funktionen an. Nach jeder Stufe laufen sie erneut, Abweichungen sehen wir sofort.
Eine Garantie für Abläufe, die niemand geprüft hat, gibt es bei gewachsener Software nicht. Deshalb gehören Testumgebung und Rückweg fest zum Vorgehen. Die Produktion wird erst umgestellt, wenn die Testfälle bestehen, und der Rückweg zum alten Stand bleibt bis zum stabilen Betrieb offen.
Was passiert, wenn das Update nicht rechtzeitig fertig wird?
Die Anwendung läuft weiter. Für PHP 8.2 erscheinen nach dem 31.12.2026 aber keine Sicherheits-Updates mehr (Stand: 2026-10), und mit jeder später bekannt werdenden Lücke wächst das Risiko.
Reicht die Zeit nicht für das ganze Update, gibt es zwei Überbrückungen. Ein Zwischenziel wie PHP 8.3 erhält Sicherheits-Updates bis zum 31.12.2027 (Stand: 2026-10) und verschafft ein Jahr. Zusätzlich lassen sich Zugriffe einschränken, eine WAF vorschalten und der Administrationszugang auf VPN begrenzen. Das senkt das Risiko, beseitigt es aber nicht.
Ist der Extended Support meines Hosters eine Alternative zum Update?
Kurzfristig kann er Zeit verschaffen, eine Alternative zum Update ist er nicht. Er gilt nur beim jeweiligen Hoster, endet spätestens mit der Abschaltung der Version und sagt nichts darüber, ob Ihre Anwendung auf einer neuen Version läuft.
Der Aufschlag ist ein Warnsignal: Ihre Version gilt beim Hoster als Auslaufmodell. Wer ohnehin vom klassischen Hosting wegziehen will, findet den Weg unter Vom Hosting in den Container.
Reicht eine WAF aus?
Allein nicht. Eine WAF filtert typische Angriffe vor der Anwendung und verschafft Zeit, schließt aber keine Lücke im Code. Deshalb verbinden wir sie mit dem Beheben bekannter Schwachstellen, einer Segmentierung des Netzes und einem Administrationszugang nur per VPN.
Eine WAF mit Regeln für Ihre Anwendung löst weniger Fehlalarme aus und schützt realistischer als die Standardkonfiguration. Lässt sich der Code nicht schnell ändern, ist eine WAF mit Isolation eine Brücke bis zum Update. Das Risiko sinkt dann, ist aber nicht beseitigt.
Wann können Sie starten?
Eine erste Antwort erhalten Sie innerhalb eines Werktags. Wann wir mit der Arbeit beginnen, hängt von der aktuellen Auslastung und vom Umfang ab. Das sagen wir Ihnen im Erstgespräch verbindlich. Ist es dringend, beginnt die 48-Stunden-Einschätzung, sobald wir Zugriff auf das System haben.
Welche PHP-Version läuft bei Ihnen?
Nennen Sie uns Version, Hoster und Anlass in ein paar Sätzen. Wir antworten innerhalb eines Werktags und schlagen den passenden ersten Schritt vor.