# Laravel-sårbarhed PHP2Shell: sådan sikrer I applikationer korrekt > Sikr Laravel efter PHP2Shell: kontrollér PHP med artisan about, genstart queue-workers og Octane, og gennemgå .env, APP_KEY og storage. Kilde: https://phpsos.de/da/plattformen/laravel/ Status: 25.10.2026 Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6 **Kort sagt:** Den Laravel-sårbarhed, som mange udviklere pt. søger efter, er PHP2Shell og ligger i selve PHP. En Laravel-opdatering lukker den ikke. Vigtigt er et patchet PHP, genstart af alle processer inklusive queue-workers og Octane samt en kontrol af `.env`, `storage` og `public`. ## Hvad PHP2Shell betyder for Laravel-applikationer Laravel er fundamentet for mange egenudviklinger: kundeportaler, interne værktøjer, bookingsystemer, API'er til apps. PHP-sårbarhederne CVE-2026-109618 og CVE-2026-109619 gør det ifølge PHP-teamet muligt at køre skadelig kode på afstand uden login. Hvor ren Laravel-koden er, spiller ingen rolle for det. Berørt er driftsformerne PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. Laravel Octane kan bruge FrankenPHP som server; så sidder PHP i FrankenPHP-programmet eller i container-imaget og opdateres sammen med dette. Hvordan det ser ud ved FrankenPHP, beskriver [Sikring af FrankenPHP](https://phpsos.de/da/server/frankenphp/). ## Laravel-sårbarhed: kontrollér PHP-version og processer På kommandolinjen viser `php artisan about` PHP-versionen, Laravel-versionen og vigtige indstillinger som miljø og debug-tilstand. Det er dog versionen af CLI-PHP. Webforespørgslerne behandles af PHP-FPM eller Octane, og det kan være en anden version. Lad i tvivlstilfælde driftsleverandøren bekræfte, hvilken pakkestatus der kører på alle veje. Rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35, backports kan bære ældre numre. Hvilke PHP-versioner jeres Laravel-version understøtter, kontrollerer I ifølge systemkravene i dokumentationen på laravel.com. Efter opdateringen kommer den del, der ved Laravel oftest glemmes: de langlivede processer. ```bash # Vis versioner og konfiguration php artisan about # Bed queue-workers om at afslutte efter det aktuelle job php artisan queue:restart # Afslut Horizon, så proceshåndteringen genstarter det php artisan horizon:terminate ``` Workers starter bagefter kun igen, hvis en proceshåndtering som Supervisor eller systemd overvåger dem. Octane-servere og containere skal genstartes fuldstændigt hhv. udrulles med et nyt image. For container-opsætninger gælder [Patch PHP i Docker-containere](https://phpsos.de/da/php2shell/docker-container-patchen/). ## Hvor Laravel-applikationer er sårbare | Sted | Indhold | Kontrolpunkt | |---|---|---| | `.env` | `APP_KEY`, database, mail, API-nøgler | må aldrig kunne hentes via nettet | | `bootstrap/cache/config.php` | cachelagret konfiguration med hemmeligheder | Rettigheder, ændringsdato | | `public/` | Dokumentrod med `index.php` | ekstra PHP-filer | | `storage/app/public` | Uploads, tilgængelige via `public/storage` | ingen PHP-filer | | `storage/logs/` | `laravel.log`, ofte med forespørgselsdata | sikres, ikke offentlig | | `vendor/` | Composer-pakker | `composer audit`, afstemning med `composer.lock` | Mappen `storage/app/public` er tilgængelig via et symbolsk link under `public/storage`. En PHP-fil, der er lagt dér, kan afhængigt af serverkonfigurationen køres direkte. Spær det på webserverniveau. > **Vigtigt:** > `APP_DEBUG` skal stå på `false` i produktion. En fejlside med debug-output kan vise miljøvariabler, stier og dele af koden og letter enhver angribers arbejde. ## Admin-flader og pakker som risiko Laravel-applikationer har ingen ensartet admin-flade. Ofte er det egne områder eller pakker som Filament eller Nova. Kontrollér, hvem der har admin-rettigheder, om login har et totrinstrin, og om admin-ruter overhovedet skal kunne nås udefra. Også API-tokens, f.eks. fra Sanctum eller Passport, bør ved mistanke tilbagekaldes og udstedes på ny. Kontrollér desuden, om værktøjer fra udviklingen kan nås i produktion, f.eks. debug-bjælker, Telescope eller testruter. De viser ofte forespørgsler, forespørgsler til databasen og konfiguration og hører hjemme bag et login eller helt fjernet fra produktionsmiljøet. Composer-pakker er den anden store blok. Hver afhængighed medbringer egen kode, og pakker uden vedligeholdelse blokerer senere PHP-opgraderinger. `composer audit` viser kendte sårbarheder, men erstatter ikke en kontrol af egen kode. ## Hvad en Laravel-opdatering kan, og hvad den ikke kan En opdatering af Laravel eller enkelte pakker lukker kendte fejl i denne kode. Den patcher ikke PHP, genstarter ikke workers, fornyer ikke en udsivet `APP_KEY` og fjerner ikke filer fra `storage` eller `public`. Om der er sket noget før rettelsen, kan kun afklares ved at kontrollere logs, filer og database. For teams med deployment-pipeline gælder: PHP-opdateringen hører også hjemme i build-miljøet og i basis-imagene, ellers medbringer næste deployment igen en gammel version. Kontrollér desuden, om staging- eller review-miljøer er offentligt tilgængelige. De kører ofte med `APP_DEBUG=true` og rigtige data og overses let ved sikkerhedsopdateringer. ## Hvordan hjælper PHP SOS konkret? - Vi kontrollerer web-, CLI- og worker-PHP i jeres Laravel-applikation og følger den ordnede genstart af alle processer. - Vi sikrer logs fra 20.10.2026, database og kodestatus og afstemmer den med jeres repository. - Vi kontrollerer `.env`, konfigurationscache, `storage`, `public`, admin-konti og API-tokens. - Til en dybere kontrol af egen kode formidler vi et [sikkerhedsaudit eller en penetrationstest](https://phpsos.de/da/leistungen/sicherheitsaudit-penetrationstest/) via specialiserede partnere. ## Ofte stillede spørgsmål **Skal jeg opdatere Laravel på grund af PHP2Shell?** En Laravel-opdatering lukker ikke PHP2Shell, fordi sårbarheden ligger i PHP-fortolkeren. Hold alligevel Laravel aktuel. Til PHP2Shell har I brug for et patchet PHP og genstart af alle PHP-processer, også workers. **Hvorfor er en genstart af PHP-FPM ofte ikke nok ved Laravel?** Queue-workers, Horizon, Octane og scheduleren kører som egne PHP-processer via kommandolinjen. De indlæser PHP én gang ved start og arbejder derefter videre med den gamle version i hukommelsen, indtil de genstartes. **Hvad gør vi, hvis .env-filen kan være sivet ud?** Så bør I forny APP_KEY, databaseadgangskoden og alle nøgler til eksterne tjenester. Bemærk, at en ny APP_KEY afslutter eksisterende sessioner og gør data, der er krypteret med den gamle nøgle, ulæselige; planlæg det sammen med jeres udviklere. ## Kilder - [php.net: Sikkerhedsmeddelelser](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)