Op woensdag 21 oktober 2026 bracht het PHP-project spoedupdates uit voor twee kritieke kwetsbaarheden in PHP zelf, inmiddels bekend als PHP2Shell (CVE-2026-109618 en CVE-2026-109619). PHP is de programmeertaal waarop een groot deel van het web draait, van WordPress-sites en webshops tot maatwerkapplicaties in Laravel. Via deze lekken kon een aanvaller zonder in te loggen eigen code laten uitvoeren op de server.
Draait je website of applicatie op PHP, dan gold dit ook voor jou. Beheren wij je omgeving, dan hebben we dit op 21 oktober voor je afgehandeld. In dit artikel lees je wat er gebeurde en wat we precies hebben gedaan.
In het kort
- Op 21 oktober 2026 kwamen spoedupdates uit voor twee kritieke lekken in PHP, samen PHP2Shell genoemd. Alleen een update van PHP zelf lost ze op.
- Beheren wij je website of applicatie, dan is dit op 21 oktober voor je afgehandeld: sites uit voorzorg tijdelijk in onderhoud, servers bijgewerkt, gecontroleerd en teruggezet.
- Waar de pakketbron achterliep, hebben we zelf een gepatchte PHP-versie gebouwd uit de officiële broncode, tot de officiële pakketten die vervangen.
- Als klant van ons hoef je hier zelf niets voor te doen. Wordt je omgeving elders beheerd, dan kijken we graag met je mee.
Wat er aan de hand was
Op dinsdag 20 oktober kondigde het beveiligingsteam van PHP aan dat er de volgende dag om 14:00 uur UTC (16:00 uur Nederlandse tijd) een release zou komen voor twee kritieke kwetsbaarheden, allebei met een score van 9,2 op een schaal van 10. Diezelfde dag gingen er al details rond op internet, voordat er een oplossing was. Volgens beveiligingsbedrijf Sansec meldde Cloudflare op de ochtend van 21 oktober de eerste aanvallen, enkele uren voordat de updates verschenen.
De oplossing zit in PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Volgens PHP loopt elke installatie die webverzoeken afhandelt risico, op welke manier PHP ook aan de webserver gekoppeld is. Beide lekken zitten in de manier waarop PHP intern geheugen en gegevens tussen verzoeken beheert. Dat maakt ze zo lastig: de aanval vindt plaats voordat de applicatie zelf ook maar één regel code heeft uitgevoerd. Een beveiligingsplugin of zorgvuldig geschreven applicatiecode houdt dit dus niet tegen. Alleen een update van PHP zelf lost het op.
Waarom dit lek nu pas boven water kwam
Het lek is niet nieuw. Volgens Calif, het onderzoeksbureau dat het ontdekte, gaat het oudste kwetsbare pad terug tot PHP 5.4 uit 2012. De fout zat dus al ruim tien jaar in PHP. In 2024 zag een PHP-ontwikkelaar ook al de eerste tekenen van het onderliggende geheugenprobleem. Een werkende aanvalsroute werd toen niet gevonden, en over de oplossing werd het beveiligingsteam het niet eens: elke variant had een nadeel, van bestaande code die niet meer zou werken tot aanpassingen aan duizenden uitbreidingen. Het werk lag daardoor maandenlang stil. De PHP Foundation noemt dat achteraf zelf een structureel falen, door de manier van besluiten en door een tekort aan mensen: het beveiligingswerk rust op een kleine groep betaalde ontwikkelaars en wat vrijwillige hulp.
Wat de situatie veranderde, is AI. In augustus 2026 vond Calif het lek binnen enkele dagen, met AI-modellen die voor iedereen beschikbaar zijn, en het beveiligingsbedrijf Wiz kwam er los daarvan ook op uit. Met een werkende aanval op tafel was de urgentie er ineens wel. De PHP Foundation schrijft het zelf: tools vinden bugs sneller dan ooit, voor verdedigers en aanvallers. Fouten die jarenlang verborgen bleven, komen daardoor sneller boven, en het tempo waarin software bijgewerkt moet worden gaat omhoog. Wij zetten AI dagelijks in bij ons eigen werk; hoe we dat voor organisaties doen, lees je bij AI-implementatie.
Waarom patchen niet overal tegelijk kan
Zodra PHP een update publiceert, staat die nog niet op je server. Het PHP-project levert broncode; vrijwel elke server krijgt PHP via een tussenpartij: de Linux-distributie, een pakketbron, een hostingpartij of een Docker-image. Elke schakel moet de nieuwe versie bouwen, testen en publiceren, en op 21 oktober ging dat niet overal even snel. Distributies hadden de reparatie vooraf gekregen en een deel had de pakketten snel klaar; andere pakketbronnen volgden pas uren later, het officiële Docker-image voor PHP kwam pas aan het begin van de avond, en het hostingplatform ServerPilot had die dag geen update, net als een veelgebruikte bron voor Red Hat-achtige servers. Sommige distributies verwerken de reparatie bovendien in een ouder versienummer, zodat het versienummer alleen niets zegt.
Wanneer de reparatie van 21 oktober per stap beschikbaar was; de tijden zijn bij benadering.
“De patch is uit” betekent dus niet dat de patch op jouw server staat.
Wat we voor onze klanten deden
Onze onderhoudssystemen houden bij welke PHP-versies waar draaien en hoe PHP er geïnstalleerd is. Daardoor hadden we na de aankondiging direct in beeld waar we moesten zijn, en konden we per server bepalen via welke route de update zou binnenkomen en welke sites en applicaties ervan afhingen.
Tussen het uitlekken van de details en de beschikbaarheid van een update zat een periode waarin aanvallen mogelijk waren en een oplossing ontbrak. Het Britse NCSC adviseerde organisaties te overwegen systemen die niet direct gerepareerd konden worden offline te halen. Die afweging hebben we per site gemaakt: wat staat er op het spel als het misgaat (klantgegevens, betalingen, toegang tot achterliggende systemen) en wat kost een paar uur onbereikbaarheid? Op de ochtend van 21 oktober, toen de eerste aanvallen werden gemeld en de update er nog niet was, hebben we vrijwel alle sites uit voorzorg in onderhoudsmodus gezet. De gewone onderhoudsmodus van WordPress of van een applicatie helpt hier overigens niet: PHP verwerkt het verzoek al voordat de applicatie een onderhoudspagina kan tonen. Bescherming biedt alleen een statische pagina die de webserver toont zonder dat PHP eraan te pas komt, en dat is wat we hebben gedaan.
Waar dat zinvol was, hebben we de tijdelijke instellingen uit het advies van PHP toegepast. Ook onze eigen website stond een tijd in onderhoud, met extra bewaking op verdachte processen, onverwachte verbindingen en gewijzigde bestanden; dezelfde afweging geldt voor ons.
Zodra de updates beschikbaar waren, hebben we server voor server bijgewerkt, gecontroleerd en pas daarna de sites teruggezet. Waar de pakketbron achterliep, hebben we tijdelijk zelf een gepatchte PHP-versie gebouwd vanuit de officiële broncode. Die broncode hebben we op echtheid gecontroleerd en elke build is beoordeeld voordat hij live ging. Zodra de officiële pakketten verschijnen, vervangen die onze eigen builds. Voor PHP 7.4 en andere versies die geen updates meer krijgen, verschijnt geen reparatie. Sites op zo’n versie hebben we naar een ondersteunde versie gebracht of offline gehouden tot dat gebeurd is.
Waarom onderhoud hier het verschil maakte
Een lek als dit laat zien waarom onderhoud geen sluitpost is. Wie weet welke versies waar draaien, kan binnen een dag handelen. Wie dat eerst moet uitzoeken, verliest de uren die ertoe doen. Hetzelfde geldt voor verouderde versies: PHP 7.4 krijgt sinds eind 2022 geen updates meer, en PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer. Verouderde software is een risico dat zich stil opbouwt, net als een verouderde koppeling. Een upgrade plannen voordat het moet, is goedkoper dan improviseren wanneer het moet. Voor de klanten bij wie dat speelt, nemen we de upgrade naar een ondersteunde PHP-versie mee in het reguliere onderhoud. In doorontwikkeling en beheer lees je hoe we dat inrichten.
Beheren wij je website of applicatie, dan hoef je hier niets voor te doen; heb je toch vragen over je eigen omgeving, dan beantwoorden we die graag. Wordt je omgeving elders beheerd en weet je niet zeker of dit daar is opgepakt? We kijken graag met je mee.