Kort sagt: Den Laravel-sårbarhet som många utvecklare söker efter just nu är PHP2Shell och finns i själva PHP. En Laravel-uppdatering stänger den inte. Viktigt är ett patchat PHP, omstart av alla processer inklusive kö-workers och Octane samt en kontroll av .env, storage och public.
Vad PHP2Shell betyder för Laravel-applikationer
Laravel är grunden för många egenutvecklingar: kundportaler, interna verktyg, bokningssystem, API:er för appar. PHP-sårbarheterna CVE-2026-109618 och CVE-2026-109619 gör det enligt PHP-teamet möjligt att köra skadlig kod på distans utan inloggning. Hur ren Laravel-koden är spelar ingen roll för detta.
Berörda är driftformerna PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. Laravel Octane kan använda FrankenPHP som server; då ligger PHP i FrankenPHP-programmet eller i container-imagen och uppdateras tillsammans med den. Hur det ser ut hos FrankenPHP beskrivs i Skydda FrankenPHP.
Laravel-sårbarhet: kontrollera PHP-version och processer
På kommandoraden visar php artisan about PHP-versionen, Laravel-versionen och viktiga inställningar som miljö och felsökningsläge. Det är dock versionen av CLI-PHP. Webbanropen hanteras av PHP-FPM eller Octane, och det kan vara en annan version. Låt vid tveksamhet driftansvariga bekräfta vilken paketstatus som körs på alla vägar.
Åtgärdade upstream-versioner är 8.5.12, 8.4.27, 8.3.36 och 8.2.35, backports kan bära äldre nummer. Vilka PHP-versioner er Laravel-version stöder kontrollerar ni enligt systemkraven i dokumentationen på laravel.com.
Efter uppdateringen kommer den del som hos Laravel oftast glöms bort: de långlivade processerna.
# Visa versioner och konfiguration
php artisan about
# Be kö-workers avsluta sig efter det aktuella jobbet
php artisan queue:restart
# Avsluta Horizon så att processhanteraren startar om det
php artisan horizon:terminate
Workers startar därefter bara om om en processhanterare som Supervisor eller systemd övervakar dem. Octane-servrar och containrar måste startas om helt respektive rullas ut med en ny image. För containeruppsättningar gäller Patcha PHP i Docker-containrar.
Var Laravel-applikationer är sårbara
| Plats | Innehåll | Kontrollpunkt |
|---|---|---|
.env |
APP_KEY, databas, e-post, API-nycklar |
får aldrig vara åtkomlig via webben |
bootstrap/cache/config.php |
cachad konfiguration med hemligheter | Rättigheter, ändringsdatum |
public/ |
Dokumentrot med index.php |
ytterligare PHP-filer |
storage/app/public |
Uppladdningar, nåbara via public/storage |
inga PHP-filer |
storage/logs/ |
laravel.log, ofta med förfrågningsdata |
säkra, inte offentligt |
vendor/ |
Composer-paket | composer audit, jämförelse med composer.lock |
Mappen storage/app/public är nåbar via en symbolisk länk under public/storage. En PHP-fil som lagts där kan beroende på serverkonfigurationen köras direkt. Spärra det på webbserversnivå.
APP_DEBUG måste vara false i produktion. En felsida med debug-utdata kan visa miljövariabler, sökvägar och delar av koden och underlättar arbetet för varje angripare.
Administrationsgränssnitt och paket som risk
Laravel-applikationer har inget enhetligt administrationsgränssnitt. Ofta är det egna områden eller paket som Filament eller Nova. Kontrollera vem som har administratörsrättigheter, om inloggningen har ett tvåfaktorssteg och om administratörsvägar behöver vara nåbara utifrån. Även API-token, till exempel från Sanctum eller Passport, bör vid misstanke återkallas och utfärdas på nytt.
Kontrollera dessutom om verktyg från utvecklingen är nåbara i produktion, till exempel debug-listen, Telescope eller testrutter. De visar ofta förfrågningar, frågor och konfiguration och hör hemma bakom en inloggning eller ska tas bort helt ur produktionsmiljön.
Composer-paket är det andra stora blocket. Varje beroende har egen kod, och paket utan underhåll blockerar senare PHP-uppgraderingar. composer audit visar kända sårbarheter men ersätter inte en granskning av den egna koden.
Vad en Laravel-uppdatering klarar och inte klarar
En uppdatering av Laravel eller enskilda paket stänger kända fel i den koden. Den patchar inte PHP, startar inga workers om, förnyar ingen läckt APP_KEY och tar inte bort filer ur storage eller public. Om något hänt före patchen kan bara klarläggas genom en granskning av loggar, filer och databas.
För team med en driftsättningspipeline gäller: PHP-uppdateringen hör hemma även i byggmiljön och i basimagerna, annars för nästa driftsättning med sig en gammal version igen. Kontrollera dessutom om staging- eller review-miljöer är offentligt nåbara. De körs ofta med APP_DEBUG=true och riktiga data och förbises lätt vid säkerhetsuppdateringar.
Hur hjälper PHP SOS konkret?
- Vi kontrollerar webb-, CLI- och worker-PHP för er Laravel-applikation och följer med vid den ordnade omstarten av alla processer.
- Vi säkrar loggar från och med den 20 oktober 2026, databas och kodläge och jämför det med ert repository.
- Vi kontrollerar
.env, konfigurationscache,storage,public, administratörskonton och API-token. - För en djupare granskning av den egna koden förmedlar vi via specialiserade partner en säkerhetsgranskning eller ett penetrationstest.
Vanliga frågor
Måste jag uppdatera Laravel på grund av PHP2Shell?
En Laravel-uppdatering stänger inte PHP2Shell, eftersom sårbarheten finns i PHP-tolken. Håll ändå Laravel aktuellt. För PHP2Shell behöver ni ett patchat PHP och omstart av alla PHP-processer, även workers.
Varför räcker det ofta inte att starta om PHP-FPM hos Laravel?
Kö-workers, Horizon, Octane och Scheduler körs som egna PHP-processer via kommandoraden. De laddar PHP en gång vid start och arbetar därefter med den gamla versionen i minnet tills de startas om.
Vad ska man göra om .env-filen kan ha läckt?
Då bör ni förnya APP_KEY, databaslösenordet och alla nycklar för externa tjänster. Observera att en ny APP_KEY avslutar befintliga sessioner och gör data som krypterats med den gamla nyckeln oläsliga; planera det med era utvecklare.