Update 21 oktober, 21:40 · Brewless gepatcht
Om 20:17 verschenen de gepatchte FrankenPHP-images. We hebben de basis-images van Brewless direct opnieuw gebouwd op PHP 8.5.12, 8.4.27 en 8.3.36 en de applicaties op Brewless opnieuw gedeployd. Ze draaien nu op de gepatchte versie; dat hebben we per applicatie gecontroleerd.
Update 21 oktober, 16:20 · opgelost
De patch kwam rond 15:35, eerder dan de aangekondigde 16:00. PHP heeft de lekken verholpen in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, en elke applicatie die wij beheren draait inmiddels op een gepatchte versie. Je hoeft zelf niets te doen.
Wat doen we aan het PHP2Shell-lek?
Kort antwoord
Er zat een kritiek lek in PHP, de taal waarin jouw applicatie draait. Vóór de patch hadden we op alle servers waar dat kan al een functie uitgezet die een van de aanvalsroutes blokkeert. Daarna hebben we de patch per platform toegepast, en inmiddels draait elke applicatie die we beheren op een gepatchte versie. Je hoeft zelf niets te doen.
Vandaag heeft het PHP-team een noodpatch uitgebracht voor twee kritieke lekken. Het gaat om PHP zelf, dus vrijwel elke PHP-applicatie ter wereld is geraakt, ook de applicaties die wij voor onze klanten bouwen en beheren. In deze update lees je wat er speelt, wat we hebben gedaan en hoe we hebben gepatcht.
Wat is er aan de hand?
Op 20 oktober kondigde het PHP-team een kritieke beveiligingsrelease aan voor 21 oktober om 16:00 Nederlandse tijd. Dezelfde dag lekten er details uit, inclusief een aanvalstool met de naam PHP2Shell. Op 21 oktober kwam de release eerder dan gepland, rond 15:35, samen met een beveiligingsadvies dat uitlegt wat er precies mis was.
Het gaat om twee lekken met een CVSS-score van 9.2, op een schaal tot 10. Allebei laten ze een aanvaller zonder in te loggen code uitvoeren op de server:
- CVE-2026-109618: als PHP tijdens het verwerken van een verzoek zonder geheugen komt te zitten, kan het blijven werken met gegevens die maar half zijn opgebouwd. Een aanvaller kan dat uitlokken.
- CVE-2026-109619: interne gegevens van een verzoek kunnen blijven bestaan nadat het geheugen al is vrijgegeven. Een volgend verzoek op dezelfde server kan die oude gegevens dan gebruiken. Eén van de bevestigde routes loopt via de functie die de voortgang van uploads in de sessie bijhoudt.
Volgens het PHP-team loopt elke installatie risico die webverzoeken verwerkt: PHP-FPM, Apache met mod_php, FrankenPHP, LiteSpeed en php-cgi. Het risico is het grootst bij mod_php, waar een aanval al werkt voordat er ook maar één regel applicatiecode draait.
Het werd breed serieus genomen: onder meer Tweakers, de Tweede Kamer en het NCSC haalden hun site volgens Sansec preventief offline tot de patch er was. Voor onze klanten is dat niet nodig, daarover hieronder meer. Sansec verwachtte dat aanvallers binnen een kwartier na de release massaal gaan scannen. Daarom hebben we direct na de release gepatcht.
Het lek zit niet in jouw code of in Laravel, maar in PHP zelf. Daarom ligt de oplossing bij de servers en platformen, en daar zorgen wij voor.
Wat we vóór de patch al hebben gedaan
We wilden niet wachten tot de patch er was. Op alle servers waar we de PHP-configuratie zelf beheren, hebben we de voortgangsfunctie voor uploads uitgezet:
session.upload_progress.enabled = OffGeen van onze applicaties gebruikt die functie, dus je merkt er niets van: uploaden werkt gewoon. We hebben per server gecontroleerd dat de instelling ook echt actief is in de webserver, en niet alleen in de configuratie staat.
Het beveiligingsadvies van PHP bevestigt dat dit de goede eerste stap was: het blokkeert de bevestigde sessieroutes van CVE-2026-109619. Het dekt niet alles af, en tegen CVE-2026-109618 helpt het niet. Het PHP-team zegt er ook duidelijk bij dat alleen updaten een volledige oplossing is. Dat hebben we gedaan, en de noodmaatregel laten we als extra laag staan.
Hoe we hebben gepatcht
De gepatchte versies zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Per platform hebben we gecontroleerd wanneer die versie beschikbaar was, en hem toegepast zodra dat zo was. Dat ging niet overal op hetzelfde moment, want de patch moest na PHP nog door een tussenschakel: een pakketbron, een runtime of een container-image. Per applicatie hebben we dit gedaan:
- Gekeken of de gepatchte versie beschikbaar was voor het platform waar jouw applicatie draait.
- Geüpdatet en PHP herstart.
- Gecontroleerd welke versie de webserver na de update echt draait.
- De noodmaatregel laten staan als extra laag.
Je hebt daar hooguit een herstart van een paar seconden van gemerkt.
Hoe het patchen per platform werkt
Niet elke applicatie draait op dezelfde plek. Het verschil zit vooral in wie de gepatchte PHP levert en wie de update uitvoert.
Laravel Forge
Met Forge beheren we servers die bij een provider zoals DigitalOcean of Hetzner draaien. Forge installeert PHP via de pakketbron van Ondřej Surý, maar patcht niet zelf: Laravel meldt in zijn update over het lek dat je de PHP-versie handmatig bijwerkt via het dashboard van de server. Dat hebben we voor elke server gedaan, zodra de gepatchte pakketten er waren.
Laravel Vapor
Op Vapor draait je applicatie serverless op AWS Lambda, zonder eigen server. De PHP-versie zit in de runtime die Laravel levert. Volgens Laravel worden applicaties op PHP 8 automatisch opnieuw gedeployd zodra de patch er is. Wij hebben daarna gecontroleerd of de gepatchte versie ook echt draait. Voor PHP 7 komt er op Vapor geen patch. Draait een applicatie van jou nog op PHP 7, dan nemen we contact met je op over een directe overstap naar PHP 8.
DigitalOcean
Bij DigitalOcean huur je virtuele servers (Droplets). DigitalOcean raakt de software op die servers niet aan, dus het patchen van PHP ligt bij de beheerder. Voor de Droplets die wij via Forge beheren, betekende dat: dezelfde update als hierboven. Alleen op App Platform, het beheerde product van DigitalOcean, levert DigitalOcean zelf de nieuwe PHP-versie en bouw je daarna opnieuw.
Hetzner
Hetzner verhuurt cloudservers en dedicated machines in Europese datacenters. Net als bij DigitalOcean beheert Hetzner de software op die servers niet. Servers die wij bij Hetzner via Forge beheren, hebben we dus zelf gepatcht, op dezelfde manier en op hetzelfde moment.
Brewless
Brewless is ons eigen serverless platform voor Laravel. Je applicatie draait als serverless container in je eigen account bij Scaleway, op een openbaar basis-image met FrankenPHP. FrankenPHP valt volgens het PHP-team ook onder de getroffen installaties. Hier moest de patch door twee schakels: eerst bouwt FrankenPHP een nieuw image met de gepatchte PHP, daarna bouwen wij ons basis-image daarop. De images van FrankenPHP verschenen om 20:17, later dan de patch op de andere platformen.
Tot die tijd stond de noodmaatregel in het basis-image: de voortgangsfunctie voor uploads uit, en tijdelijk geen geheugenlimiet voor PHP, zodat de route van CVE-2026-109618 via een vol geheugen niet bereikbaar was. De container zelf had wel een grens. Toen de images er waren, hebben we het basis-image opnieuw gebouwd op PHP 8.5.12, 8.4.27 en 8.3.36. Een build op een oudere PHP weigert het sindsdien, en de geheugenlimiet staat weer op 256 MB. Daarna hebben we de applicaties op Brewless opnieuw gedeployd en per applicatie gecontroleerd welke PHP-versie draait. Elke release is een vast image, dus mocht er iets misgaan, dan staat de vorige versie direct weer klaar.
| Platform | Wie levert de gepatchte PHP | Wat wij hebben gedaan | Wat jij merkt |
|---|---|---|---|
| Forge | Pakketbron van Ondřej Surý | PHP per server bijgewerkt via Forge | Een herstart van enkele seconden |
| Vapor | Laravel, als nieuwe runtime | Gecontroleerd na de automatische deploy van Laravel | Niets |
| DigitalOcean | Pakketbron op de server | Bijgewerkt via Forge | Een herstart van enkele seconden |
| Hetzner | Pakketbron op de server | Bijgewerkt via Forge | Een herstart van enkele seconden |
| Brewless | Basis-image met FrankenPHP | Basis-image opnieuw gebouwd, daarna opnieuw gedeployd | Niets, terugrollen kan direct |
Moet je zelf iets doen?
Draait je applicatie bij ons, dan niet. De patch is toegepast, en als er toch iets van je nodig is, laten we het je weten. Dat kan bijvoorbeeld zijn als een applicatie nog op een PHP-versie draait die geen officiële update meer krijgt: PHP 8.1 en ouder vallen buiten de ondersteuning.
Je applicatie offline halen, zoals sommige grote sites vandaag deden, is niet nodig. De noodmaatregel staat en de patch is toegepast. Vragen? Neem contact op.
