# Laravel-Sicherheitslücke PHP2Shell: Anwendungen richtig absichern > Laravel nach PHP2Shell absichern: PHP mit artisan about prüfen, Queue-Worker und Octane neu starten, .env, APP_KEY und storage kontrollieren. Quelle: https://phpsos.de/plattformen/laravel/ Stand: 25.10.2026 Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6 **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](https://phpsos.de/server/frankenphp/). ## 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. ```bash # 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](https://phpsos.de/php2shell/docker-container-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. > **Wichtig:** > `APP_DEBUG` 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_DEBUG=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](https://phpsos.de/leistungen/sicherheitsaudit-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. ## Quellen - [php.net: Sicherheitsmeldungen](https://www.php.net/) - [Laravel](https://laravel.com/) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)