Zwei kritische PHP-Lücken und was das für Laravel-Projekte bedeutet

• PHP 8.1 ist seit dem 31. Dezember 2025 End of Life. Letztes Release war 8.1.34.

• Sicherheitsupdates vom PHP-Team gibt es nur für 8.2 und neuer.

• Laravel 10 unterstützt PHP 8.1 bis 8.3 – es ist die jüngste Laravel-Version, die überhaupt noch auf 8.1 läuft.

• Laravel 10 bekommt seit dem 4. Februar 2025 keine Sicherheitsfixes mehr, Laravel 11 seit dem 12. März 2026.

• Wer auf PHP 8.1 steht, steht damit höchstwahrscheinlich auf zwei abgelaufenen Supportzyklen gleichzeitig.

Die Supportzyklen von PHP sind öffentlich und berechenbar: zwei Jahre aktiver Support, danach zwei Jahre nur noch Sicherheitsfixes.

Wer bei einer Laravel-Anwendung die PHP-Version anheben will, kann das meistens nicht isoliert tun. Jede Laravel-Version unterstützt nur eine bestimmte Spanne an PHP-Versionen. Laravel 10 endet bei PHP 8.3 – für alles darüber muss erst Laravel selbst auf eine neuere Version aktualisiert werden.

Daraus folgt etwas, das in der Praxis oft untergeht. Eine Anwendung auf PHP 8.1 läuft zwangsläufig auf Laravel 10 oder älter. Und Laravel 10 hat seit Februar 2025 keinen Sicherheitssupport mehr. Das Projekt hat also nicht ein Update-Problem, sondern zwei, die sich gegenseitig blockieren: PHP lässt sich nicht heben, ohne das Framework zu heben, und umgekehrt.

Was in solchen Projekten erfahrungsgemäß tatsächlich bremst, ist selten Laravel selbst. Es sind die Pakete drumherum – ein Payment-Adapter, der nie auf Laravel 11 portiert wurde. Eine selbstgebaute Package-Abhängigkeit, die seit drei Jahren niemand angefasst hat. Ein Shared-Hosting-Tarif, der 8.2 gar nicht anbietet.

Die Frage ist weniger trivial, als sie klingt, weil auf einem Server mehrere PHP-Versionen parallel installiert sein können und die CLI nicht zwingend das ausliefert, was der Webserver nutzt.

Verlässlich ist der Weg über den Webserver. Eine kurzlebige Datei im Web-Root anlegen, die PHP_VERSION ausgibt – und danach sofort löschen. Den Paketstand prüft ihr auf Debian und Ubuntu mit dpkg -l | grep -i php, in der RHEL-Familie mit rpm -qa | grep -i php.

Ein verbreiteter Irrtum: php -i auf der Kommandozeile spiegelt die Konfiguration eurer PHP-FPM-Pools nicht zuverlässig wider. Pool-Einstellungen überschreiben die globale php.ini. Wer nur die CLI prüft, prüft unter Umständen etwas anderes als das, was im Web läuft.

Möglicherweise auch betroffen: Alte Staging-Umgebungen, ein Plesk- oder cPanel-Server, eine Appliance mit eingebettetem PHP, das Legacy-Tool, das seit Jahren unverändert läuft. Zum Zeitpunkt des Oktober-Releases meldeten laut Shodan-Auswertungen rund 884.000 öffentlich erreichbare Hosts PHP 8.1 oder älter – etwa 59 Prozent aller Hosts, die überhaupt eine Version preisgaben. Das sind Banner-Angaben, keine bestätigt verwundbaren Systeme. Die Größenordnung sagt trotzdem genug.

Realistisch gibt es drei Wege, und nur einer davon löst das Problem:

Distributions-Backport prüfen. Debian, Ubuntu LTS und RHEL pflegen eigene PHP-Pakete und portieren Sicherheitsfixes teilweise in Versionen zurück, die upstream längst EOL sind. Für ein akutes CVE ist das oft die einzige kurzfristige Patch-Quelle. Verlasst euch nicht darauf: Welche Fixes zurückportiert werden und wie schnell, entscheidet die Distribution, nicht ihr. Für 7.4 und älter gibt es diesen Weg praktisch nicht mehr.

Angriffsfläche verkleinern. Anwendung hinter VPN oder WAF, Zugriff aus dem öffentlichen Netz einschränken, auffällige Prozessstarts überwachen – wenn php-fpm oder apache2 plötzlich Shells oder Download-Tools startet, ist das ein Alarm. Das kauft Zeit und schließt keine Lücke.

Upgraden. Der einzige Weg, der die Lage tatsächlich ändert.