PHP 8.2 bekommt ab 2027 keine Sicherheitsupdates mehr: Ihre Optionen

Am 31.12.2026 enden die Sicherheitsupdates für PHP 8.2. Neue Lücken in 8.2 schließt das PHP Projekt danach nicht mehr. Wie schnell das zum Problem wird, hat PHP2Shell im Oktober gezeigt.

PHP2Shell: was im Oktober passiert ist

Am 20.10.2026 wurden Details zu zwei kritischen Lücken in PHP vorzeitig öffentlich: CVE-2026-109618 und CVE-2026-109619, zusammen PHP2Shell genannt. Ein Angreifer kann damit ohne Anmeldung Code auf dem Server ausführen. Am 21.10.2026 hat das PHP Projekt die Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 veröffentlicht. Für PHP 7.4, 8.0 und 8.1 gibt es nur noch Patches im Quellcode, aber keine offiziellen Releases.

Laut watchTowr gab es schon am Tag der Patches Angriffe auf die Lücken. Eine Einstellung, die vollständig schützt, gibt es laut PHP nicht. Sicher ist nur das Update. Danach müssen alle PHP Worker neu starten, sonst läuft der alte Code weiter.

So prüfen Sie, ob Ihr Server die korrigierte Version hat:

# Version auf der Kommandozeile, korrigiert ab 8.2.35, 8.3.36, 8.4.27 oder 8.5.12
php -v

# PHP FPM Dienste auf dem Server (Debian, Ubuntu)
systemctl list-units --type=service 'php*-fpm*'

# Nach dem Update: PHP FPM neu starten, hier für PHP 8.2 auf Debian
sudo systemctl restart php8.2-fpm

PHP 8.2 hat die Korrektur noch bekommen, weil es bis Jahresende Sicherheitsupdates hat. Wäre PHP2Shell im Jänner 2027 bekannt geworden, hätte es für PHP 8.2 keinen offiziellen Patch mehr gegeben.

Gefunden mit KI, und das war nicht das letzte Mal

Gefunden haben die Lücken Forscher von Calif im August, bei einem Audit des Quellcodes von PHP, das OpenAI finanziert hat. Sie arbeiteten dabei mit dem Modell GPT-5.6 Sol. Wenige Wochen später fand Wiz dieselben Lücken unabhängig davon, ebenfalls mit KI Modellen (The Next Web). Calif betont, dass das Wissen um die Geschichte von PHP wichtiger war als das Modell.

Wir gehen davon aus, dass solche Fälle häufiger werden. KI Modelle lesen große Mengen Code in kurzer Zeit und setzen ihn mit bekannten Schwachstellen und Angriffsmustern in Beziehung. Was früher Wochen an Handarbeit gebraucht hat, geht damit deutlich schneller, für Forscher genauso wie für Angreifer.

Dass es zuerst PHP getroffen hat, überrascht nicht. PHP gibt es seit 1995, es ist sehr weit verbreitet und gut dokumentiert, seine Fehler eingeschlossen. Betroffen sind auch Versionen, die mehr als zehn Jahre alt sind (Wikipedia). Spezifisch für PHP ist das aber nicht: Java, Node.js, Python und die Bibliotheken darunter haben genauso viel alten Code, den jetzt Modelle durchsuchen. Für Ihre Systeme heißt das zweierlei. Die Zeit zwischen dem Bekanntwerden einer Lücke und dem ersten Angriff wird kürzer. Und eine Version ohne Sicherheitsupdates bekommt im Ernstfall keinen Patch.

Wie lange eine PHP Version Updates bekommt

Das PHP Projekt pflegt jede Version zwei Jahre lang mit Fehlerkorrekturen und Sicherheitsupdates. Danach schließt es zwei weitere Jahre nur noch kritische Sicherheitslücken. So steht es auf der Seite Supported Versions von php.net. Für PHP 8.2 endet diese zweite Phase am 31.12.2026, für PHP 8.1 ist sie seit 31.12.2025 vorbei.

PHP Versionen und ihr Support
PHP Versionen und ihr Support
VersionVeröffentlichtAktiver Support bisSicherheitsupdates bis
PHP 8.125.11.202125.11.202331.12.2025
PHP 8.208.12.202231.12.202431.12.2026
PHP 8.323.11.202331.12.202531.12.2027
PHP 8.421.11.202431.12.202631.12.2028
PHP 8.520.11.202531.12.202731.12.2029

Quelle: php.net

Wer heute auf PHP 8.2 ist, hat also gut zwei Monate. Mit 8.1 oder älter laufen Sie schon jetzt ohne Updates vom PHP Projekt.

So finden Sie Ihre Version

Auf dem Server zeigt php -v die Version der Kommandozeile. PHP FPM kann eine andere Version nutzen, prüfen Sie deshalb auch die Dienste von PHP FPM wie oben. Mit Plesk laufen auf einem Server oft mehrere Versionen nebeneinander, und jede Domain kann eine andere nutzen:

# Alle PHP Versionen, die Plesk auf diesem Server kennt
plesk bin php_handler --list

In der Anwendung steht die verlangte Version in der composer.json:

{
  "require": {
    "php": "^8.2"
  }
}

^8.2 erlaubt auch 8.3, 8.4 und 8.5. Steht dort ~8.2.0 oder 8.2.*, ist die Anwendung auf PHP 8.2 festgelegt, und das Upgrade braucht mehr als einen neuen Server. Ob die PHP Version auf dem Server zu den Anforderungen Ihrer Abhängigkeiten passt, zeigt Composer selbst:

composer check-platform-reqs

Wenn PHP bei Ihnen aus Plesk kommt

Plesk liefert eigene PHP Pakete und aktualisiert sie laufend. Laut Änderungsprotokoll von Plesk kam PHP 8.2 am 21.10.2026 auf Version 8.2.35. Welche Versionen Sie über den Plesk Installer installieren können, steht in der Wissensdatenbank von Plesk.

Am selben Tag hat Plesk die Korrektur für PHP2Shell auch in PHP 8.1.34 eingespielt, obwohl 8.1 beim PHP Projekt schon keinen Support mehr hat. Eine feste Zusage, dass Plesk das für Versionen ohne Support immer tut, haben wir in der Dokumentation nicht gefunden. Für diese Versionen bietet Plesk außerdem eine Erweiterung von TuxCare an, die für diese Versionen weiter Sicherheitsupdates liefert. Laut Plesk deckt sie mit Stand März 2026 PHP 5.6 bis 8.1 ab.

Wenn PHP bei Ihnen von Debian kommt

Debian 12 bringt PHP 8.2 als eigenes Paket mit. Debian schließt Lücken darin, solange Debian 12 selbst Updates bekommt: mit Debian LTS bis 30.06.2028. Die Termine dazu finden Sie in unserem EOL Kalender. Das gilt aber nur für das PHP aus den Paketen von Debian, nicht für PHP aus Plesk oder aus einer anderen Quelle auf demselben Server.

Drei Wege

1. Upgrade auf eine unterstützte Version

Der direkte Weg: PHP 8.4 bekommt Sicherheitsupdates bis 31.12.2028, PHP 8.5 bis 31.12.2029. Wie aufwendig das Upgrade ist, hängt von Framework, Bibliotheken und Tests ab. Wir prüfen zuerst die composer.json und die Abhängigkeiten, lassen die Tests gegen die neue Version laufen und stellen auf Staging um, bevor die Produktion folgt.

2. Die Pakete der Distribution nutzen

Läuft Ihre Anwendung auf Debian 12, können Sie beim PHP 8.2 von Debian bleiben und das Upgrade bis zum Ende von Debian 12 planen. So gewinnen Sie Zeit. Bibliotheken und Frameworks beenden ihren Support für PHP 8.2 trotzdem nach und nach.

3. Bezahlter Langzeitsupport

Anbieter wie Zend oder TuxCare liefern Sicherheitsupdates über das offizielle Ende hinaus. Auch das verschafft Ihnen Zeit für das Upgrade, ersetzt es aber nicht.

Patchen ist ein Kreislauf, kein ProjektPatch Management über den ganzen Lebenszyklus, mit ITIL® PraktikenPatchen ist ein Kreislauf, kein ProjektPatch Management über den ganzen Lebenszyklus, mit ITIL® Praktiken1 InventarWas läuft wo, welche VersionService Configuration Mgmt.2 BeobachtenEOL Kalender und CVEsIT Asset Management3 BewertenRisiko und DringlichkeitInformation Security Mgmt.4 PlanenChange und WartungsfensterChange Enablement5 Ausrollen & prüfenDeployment, FunktionstestDeployment Management6 NachweisenBericht, NISG § 32Service Level ManagementFester Taktjede Runde endet mit einem Nachweiskritisch: außer der Reihe

Fahren Sie mit der Maus über einen Schritt oder tippen Sie ihn an. Hervorgehoben bleiben der Schritt davor und der danach.

Welchen der drei Wege Sie auch wählen, er läuft durch denselben Kreislauf aus Inventar, Risiko, Change mit Rückweg und Nachweis im Bericht.
Welchen der drei Wege Sie auch wählen, er läuft durch denselben Kreislauf aus Inventar, Risiko, Change mit Rückweg und Nachweis im Bericht.

Wenn Sie Ihre Versionen nicht kennen

Der Legacy Check beginnt mit genau dieser Inventur: welche PHP Versionen bei Ihnen laufen, woher sie kommen und bis wann sie Updates bekommen. Er kostet 3.900 Euro zum Festpreis, den Bericht haben Sie nach zehn Tagen. Alle Termine finden Sie im EOL Kalender.