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.
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.
# 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.
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.
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 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.