Kort gezegd: Het Laravel-beveiligingslek waarnaar veel ontwikkelaars nu zoeken, is PHP2Shell en zit in PHP zelf. Een Laravel-update sluit het niet. Belangrijk zijn een gepatchte PHP, de herstart van alle processen inclusief queue-workers en Octane, en een controle van .env, storage en public.
Wat PHP2Shell betekent voor Laravel-applicaties
Laravel is het fundament van veel eigen ontwikkelingen: klantenportalen, interne hulpmiddelen, boekingssystemen, API's voor apps. De PHP-kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 maken het volgens het PHP-team mogelijk om op afstand en zonder inloggen schadelijke code uit te voeren. Hoe schoon de Laravel-code is, speelt daarbij geen rol.
Getroffen zijn de uitvoeringsmodi PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Laravel Octane kan FrankenPHP als server gebruiken; dan zit PHP in het FrankenPHP-programma of in het containerimage en wordt daarmee bijgewerkt. Hoe dat er bij FrankenPHP uitziet, beschrijft FrankenPHP beveiligen.
Laravel-beveiligingslek: PHP-versie en processen controleren
Op de opdrachtregel toont php artisan about de PHP-versie, de Laravel-versie en belangrijke instellingen zoals omgeving en debugmodus. Dat is echter de versie van de CLI-PHP. De webverzoeken worden afgehandeld door PHP-FPM of Octane, en dat kan een andere versie zijn. Laat de beheerder bij twijfel bevestigen welke pakketstatus op alle wegen draait.
Verholpen upstreamversies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35, backports kunnen oudere nummers dragen. Welke PHP-versies uw Laravel-versie ondersteunt, controleert u volgens de systeemeisen in de documentatie op laravel.com.
Na de update komt het onderdeel dat bij Laravel het vaakst wordt vergeten: de langlevende processen.
# Versies en configuratie weergeven
php artisan about
# Queue-workers opdragen zich na de huidige job te beëindigen
php artisan queue:restart
# Horizon beëindigen zodat de procesmanager het opnieuw start
php artisan horizon:terminate
De workers starten daarna alleen opnieuw als een procesmanager zoals Supervisor of systemd ze bewaakt. Octane-servers en containers moeten volledig opnieuw worden gestart of met een nieuw image worden uitgerold. Voor containeropstellingen geldt PHP in Docker-containers patchen.
Waar Laravel-applicaties kwetsbaar zijn
| Plek | Inhoud | Controlepunt |
|---|---|---|
.env |
APP_KEY, database, mail, API-sleutels |
mag nooit via het web opvraagbaar zijn |
bootstrap/cache/config.php |
gecachete configuratie met geheimen | rechten, wijzigingsdatum |
public/ |
Documentroot met index.php |
extra PHP-bestanden |
storage/app/public |
Uploads, bereikbaar via public/storage |
geen PHP-bestanden |
storage/logs/ |
laravel.log, vaak met verzoekgegevens |
veiligstellen, niet openbaar |
vendor/ |
Composer-pakketten | composer audit, vergelijking met composer.lock |
De map storage/app/public is via een symbolische link bereikbaar onder public/storage. Een daar geplaatst PHP-bestand kan afhankelijk van de serverconfiguratie rechtstreeks worden uitgevoerd. Blokkeer dat op webserverniveau.
APP_DEBUG moet in productie op false staan. Een foutpagina met debuguitvoer kan omgevingsvariabelen, paden en delen van de code tonen en maakt het werk van elke aanvaller makkelijker.
Beheerinterfaces en pakketten als risico
Laravel-applicaties hebben geen uniforme beheerinterface. Vaak zijn het eigen onderdelen of pakketten zoals Filament of Nova. Controleer wie beheerdersrechten heeft, of de aanmelding een tweestapsverificatie kent en of beheerroutes van buitenaf bereikbaar moeten zijn. Ook API-tokens, bijvoorbeeld uit Sanctum of Passport, moeten bij een vermoeden worden ingetrokken en opnieuw uitgegeven.
Controleer bovendien of hulpmiddelen uit de ontwikkeling in productie bereikbaar zijn, zoals debugbalken, Telescope of testroutes. Ze tonen vaak verzoeken, queries en configuratie en horen achter een aanmelding of helemaal uit de productieomgeving te worden verwijderd.
Composer-pakketten vormen het tweede grote blok. Elke afhankelijkheid brengt eigen code mee, en pakketten zonder onderhoud blokkeren later PHP-upgrades. composer audit toont bekende kwetsbaarheden, maar vervangt geen controle van de eigen code.
Wat een Laravel-update wel en niet kan
Een update van Laravel of afzonderlijke pakketten dicht bekende fouten in die code. Ze patcht PHP niet, herstart geen workers, vernieuwt geen weggelekte APP_KEY en verwijdert geen bestanden uit storage of public. Of er vóór de patch iets is gebeurd, is alleen vast te stellen door logs, bestanden en database te controleren.
Voor teams met een deploymentpipeline geldt: de PHP-update hoort ook in de buildomgeving en in de basisimages, anders brengt de volgende deployment weer een oude versie mee. Controleer bovendien of staging- of reviewomgevingen openbaar bereikbaar zijn. Ze draaien vaak met APP_DEBUG=true en echte gegevens en worden bij beveiligingsupdates makkelijk over het hoofd gezien.
Hoe helpt PHP SOS concreet?
- Wij controleren de web-, CLI- en worker-PHP van uw Laravel-applicatie en begeleiden de geordende herstart van alle processen.
- Wij maken een kopie van logs vanaf 20-10-2026, database en codestatus en vergelijken die met uw repository.
- Wij controleren
.env, configuratiecache,storage,public, adminaccounts en API-tokens. - Voor een diepere controle van de eigen code bemiddelen wij via gespecialiseerde partners een beveiligingsaudit of penetratietest.
Veelgestelde vragen
Moet ik Laravel vanwege PHP2Shell bijwerken?
Een Laravel-update sluit PHP2Shell niet, omdat de kwetsbaarheid in de PHP-interpreter zit. Houd Laravel toch actueel. Voor PHP2Shell hebt u een gepatchte PHP nodig en de herstart van alle PHP-processen, ook van de workers.
Waarom volstaat een herstart van PHP-FPM bij Laravel vaak niet?
Queue-workers, Horizon, Octane en de scheduler draaien als eigen PHP-processen via de opdrachtregel. Ze laden PHP eenmalig bij het starten en werken daarna met de oude versie in het geheugen door, tot ze opnieuw worden gestart.
Wat te doen als het .env-bestand kan zijn weggelekt?
Dan moet u APP_KEY, het databasewachtwoord en alle sleutels voor externe diensten vernieuwen. Houd er rekening mee dat een nieuwe APP_KEY bestaande sessies beëindigt en met de oude sleutel versleutelde gegevens onleesbaar maakt; plan dat met uw ontwikkelaars.