Kurz gesagt: Die Laravel-Sicherheitslücke, nach der gerade viele Entwickler suchen, ist PHP2Shell und liegt in PHP selbst. Ein Laravel-Update schließt sie nicht. Wichtig sind ein gepatchtes PHP, der Neustart aller Prozesse einschließlich Queue-Worker und Octane sowie eine Prüfung von .env, storage und public.
Was PHP2Shell für Laravel-Anwendungen bedeutet
Laravel ist das Fundament vieler Eigenentwicklungen: Kundenportale, interne Werkzeuge, Buchungssysteme, APIs für Apps. Die PHP-Lücken CVE-2026-109618 und CVE-2026-109619 erlauben laut PHP-Team Schadcode aus der Ferne ohne Anmeldung. Wie sauber der Laravel-Code ist, spielt dafür keine Rolle.
Betroffen sind die Betriebsarten PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Laravel Octane kann FrankenPHP als Server nutzen; dann steckt PHP im FrankenPHP-Programm oder im Container-Image und wird mit diesem aktualisiert. Wie das bei FrankenPHP aussieht, beschreibt FrankenPHP absichern.
Laravel-Sicherheitslücke: PHP-Version und Prozesse prüfen
Auf der Kommandozeile zeigt php artisan about die PHP-Version, die Laravel-Version und wichtige Einstellungen wie Umgebung und Debug-Modus. Das ist allerdings die Version des CLI-PHP. Die Web-Anfragen bearbeitet PHP-FPM oder Octane, und das kann eine andere Version sein. Lassen Sie im Zweifel den Betreiber bestätigen, welcher Paketstand auf allen Wegen läuft.
Behobene Upstream-Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35, Backports können ältere Nummern tragen. Welche PHP-Versionen Ihre Laravel-Version unterstützt, prüfen Sie laut Systemanforderungen in der Dokumentation auf laravel.com.
Nach dem Update kommt der Teil, der bei Laravel am häufigsten vergessen wird: die langlebigen Prozesse.
# Versionen und Konfiguration anzeigen
php artisan about
# Queue-Worker anweisen, sich nach dem aktuellen Job zu beenden
php artisan queue:restart
# Horizon beenden, damit der Prozessmanager es neu startet
php artisan horizon:terminate
Die Worker starten danach nur neu, wenn ein Prozessmanager wie Supervisor oder systemd sie überwacht. Octane-Server und Container müssen vollständig neu gestartet beziehungsweise mit einem neuen Image ausgerollt werden. Für Container-Setups gilt PHP in Docker-Containern patchen.
Wo Laravel-Anwendungen verwundbar sind
| Ort | Inhalt | Prüfpunkt |
|---|---|---|
.env |
APP_KEY, Datenbank, Mail, API-Schlüssel |
darf nie über das Web abrufbar sein |
bootstrap/cache/config.php |
zwischengespeicherte Konfiguration mit Geheimnissen | Rechte, Änderungsdatum |
public/ |
Dokumentwurzel mit index.php |
zusätzliche PHP-Dateien |
storage/app/public |
Uploads, über public/storage erreichbar |
keine PHP-Dateien |
storage/logs/ |
laravel.log, oft mit Anfragedaten |
sichern, nicht öffentlich |
vendor/ |
Composer-Pakete | composer audit, Abgleich mit composer.lock |
Der Ordner storage/app/public ist über einen symbolischen Link unter public/storage erreichbar. Eine dort abgelegte PHP-Datei kann je nach Serverkonfiguration direkt ausgeführt werden. Sperren Sie das auf Webserver-Ebene.
APP_ATBUG muss in Produktion auf false stehen. Eine Fehlerseite mit Debug-Ausgabe kann Umgebungsvariablen, Pfade und Teile des Codes zeigen und erleichtert jedem Angreifer die Arbeit.
Admin-Oberflächen und Pakete als Risiko
Laravel-Anwendungen haben keine einheitliche Admin-Oberfläche. Häufig sind es eigene Bereiche oder Pakete wie Filament oder Nova. Prüfen Sie, wer Admin-Rechte hat, ob die Anmeldung eine Zwei-Faktor-Stufe hat und ob Admin-Routen von außen erreichbar sein müssen. Auch API-Tokens, etwa aus Sanctum oder Passport, sollten nach einem Verdacht widerrufen und neu ausgestellt werden.
Prüfen Sie außerdem, ob Werkzeuge aus der Entwicklung in Produktion erreichbar sind, etwa Debug-Leisten, Telescope oder Testrouten. Sie zeigen oft Anfragen, Abfragen und Konfiguration und gehören hinter eine Anmeldung oder ganz aus der Produktionsumgebung entfernt.
Composer-Pakete sind der zweite große Block. Jede Abhängigkeit bringt eigenen Code mit, und Pakete ohne Pflege blockieren später PHP-Upgrades. composer audit zeigt bekannte Lücken, ersetzt aber keine Prüfung des eigenen Codes.
Was ein Laravel-Update kann und was nicht
Ein Update von Laravel oder einzelnen Paketen schließt bekannte Fehler in diesem Code. Es patcht nicht PHP, startet keine Worker neu, erneuert keinen abgeflossenen APP_KEY und entfernt keine Dateien aus storage oder public. Ob vor dem Patch etwas passiert ist, lässt sich nur durch Prüfung von Logs, Dateien und Datenbank klären.
Für Teams mit Deployment-Pipeline gilt: Das PHP-Update gehört auch in die Build-Umgebung und in die Basis-Images, sonst bringt das nächste Deployment wieder eine alte Version mit. Prüfen Sie zudem, ob Staging- oder Review-Umgebungen öffentlich erreichbar sind. Sie laufen oft mit APP_ATBUG=true und echten Daten und werden bei Sicherheitsupdates leicht übersehen.
Wie hilft PHP SOS konkret?
- Wir prüfen Web-, CLI- und Worker-PHP Ihrer Laravel-Anwendung und begleiten den geordneten Neustart aller Prozesse.
- Wir sichern Logs ab dem 20.10.2026, Datenbank und Code-Stand und gleichen ihn mit Ihrem Repository ab.
- Wir prüfen
.env, Konfigurations-Cache,storage,public, Admin-Konten und API-Tokens. - Für eine tiefere Prüfung des eigenen Codes vermitteln wir ein Sicherheitsaudit oder einen Penetrationstest über spezialisierte Partner.
Häufige Fragen
Muss ich Laravel wegen PHP2Shell aktualisieren?
Ein Laravel-Update schließt PHP2Shell nicht, weil die Lücke im PHP-Interpreter liegt. Halten Sie Laravel trotzdem aktuell. Für PHP2Shell brauchen Sie ein gepatchtes PHP und den Neustart aller PHP-Prozesse, auch der Worker.
Warum reicht ein Neustart von PHP-FPM bei Laravel oft nicht?
Queue-Worker, Horizon, Octane und der Scheduler laufen als eigene PHP-Prozesse über die Kommandozeile. Sie laden PHP einmal beim Start und arbeiten danach mit der alten Version im Speicher weiter, bis sie neu gestartet werden.
Was tun, wenn die .env-Datei abgeflossen sein könnte?
Dann sollten Sie APP_KEY, Datenbankpasswort und alle Schlüssel für externe Dienste erneuern. Beachten Sie, dass ein neuer APP_KEY bestehende Sitzungen beendet und mit dem alten Schlüssel verschlüsselte Daten nicht mehr lesbar macht; planen Sie das mit Ihren Entwicklern.