
Via twee kritieke kwetsbaarheden in PHP kunnen aanvallers servers op afstand overnemen. Vandaag om 16.00 uur verschijnt de beveiligingsupdate. Wat er speelt, hoe ernstig het is en welke stappen je nu zet.
Wat is er aan de hand?
PHP is een programmeertaal die op heel veel servers draait: volgens W3Techs gebruikt 69 procent van alle websites waarvan de techniek bekend is PHP. Niet alleen onder websites (WordPress, Drupal, Joomla, TYPO3) en webshops (WooCommerce, Magento, Shopware), maar ook onder bestandsdeling als Nextcloud, klantportalen, leeromgevingen, intranetten, bedrijfsapplicaties (vaak gebouwd met Laravel), de servers achter sommige mobiele apps, hostingpanelen als cPanel en Plesk, en software van leveranciers. Zie je het zelf nergens, dan kan het toch op de achtergrond draaien. En een toepassing hoeft geen zichtbare uploadknop te hebben om geraakt te kunnen worden; of een toepassing echt misbruikbaar is, hangt af van de instellingen, de bereikbaarheid en de precieze voorwaarden van het lek.
In PHP zijn twee ernstige lekken gevonden. Volgens beveiligingsbedrijf watchTowr kan een aanvaller daarmee van buitenaf eigen opdrachten laten uitvoeren op de server waar PHP draait. Daarmee kan hij in feite de server overnemen.
De makers van PHP brengen vandaag, woensdag 21 oktober, om 16.00 uur Nederlandse tijd een extra beveiligingsupdate uit die de kwetsbaarheden verhelpt. Normaal blijven zulke lekken geheim tot de oplossing er is. Dit keer lekte het bestaan ervan gisteren al uit. PHP kondigde de update daarop zelf aan, een dag eerder dan de geplande bekendmaking.
Hoe erg is dit?
PHP beoordeelt beide kwetsbaarheden met een score van 9,2 op 10, de categorie kritiek. Vier factoren maken de situatie ernstig:
- Het zit in PHP zelf, niet in je software. WordPress, plug-ins, je webshop of je applicatie updaten helpt niet. Alleen een nieuwe PHP-versie op de server lost het op.
- Oude PHP krijgt geen oplossing. Alleen PHP 8.2, 8.3, 8.4 en 8.5 krijgen de update. Beveiligingsbedrijf Mallory telde op internet ruim 880.000 servers die aangeven PHP 8.1 of ouder te draaien. Volgens Hadrian draait bijna de helft van alle PHP-websites (48,5 procent, op basis van W3Techs) op een versie waarvoor geen officiële fix wordt verwacht. Of die ook kwetsbaar zijn, is nog niet bekend, maar een patch komt er voor hen niet.
- AI maakt aanvallen sneller. AI-modellen zijn de afgelopen tijd veel capabeler en breed beschikbaar geworden. Daarmee kan iemand een aanval veel sneller nabouwen dan een paar jaar geleden. Zodra PHP vanmiddag de oplossing publiceert, kunnen aanvallers met AI ook razendsnel uitzoeken wat er is veranderd en daar een aanval van maken.
- Aanvallers zijn snel. Online circuleren al zelfgemaakte aanvalsprogramma's, al betwijfelen experts of die werken. Cloudflare-CTO Dane Knecht meldt op X dat de eerste aanvalspogingen beginnen. SecurityWeek en Sansec waarschuwen voor massaal misbruik. Bevestigd misbruik is er officieel nog niet. Sommige partijen nemen het zekere voor het onzekere: 4chan staat vanochtend uit voorzorg op alleen-lezen, en de makers van WordPress-plug-in The SEO Framework hebben hun servers offline gehaald tot de PHP-update er is.

Op X zijn de signalen gemengd. Sommige onderzoekers stellen dat de lekken lastig te misbruiken zijn en dat het meevalt als je de update gewoon installeert. Anderen zeggen de aanval al te hebben nagebouwd, soms met hulp van AI-modellen. Dat is niet onafhankelijk bevestigd. Beveiligingsonderzoeker Wesley McGrew vat het nuchter samen: ernstig, maar niet ongekend. Grote, goed beheerde systemen worden snel bijgewerkt; het grootste risico zit in systemen die niemand op tijd bijwerkt, zoals verouderde websites, apparaten en appliances met PHP aan boord. Ons advies verandert er niet door: installeer de update zodra die er is.
Wat als je niets doet?
Zolang een systeem niet is bijgewerkt, blijft het kwetsbaar. Wordt het lek misbruikt, dan kan een aanvaller in het ergste geval:
- de website of applicatie aanpassen of onbereikbaar maken;
- gegevens inzien of meenemen;
- systemen versleutelen met ransomware.
Bij het vorige ernstige PHP-lek, in juni 2024, zag Akamai binnen 24 uur de eerste aanvalspogingen en werden ongeveer duizend servers getroffen door ransomware. Dat lek raakte alleen PHP op Windows. Het is daarom verstandig de update vandaag te laten installeren.
Wat moet je doen?
Laat je je systemen beheren door een hostingpartij, IT-leverancier of websitebouwer? Dat geldt voor de meeste bedrijven.
- Mail of bel ze vandaag nog. Vraag: "Draait er bij ons PHP, bijvoorbeeld onder onze website, webshop, portalen of applicaties? En wanneer installeren jullie de PHP-update van 21 oktober?"
- Vraag welke PHP-versie elk systeem gebruikt. Is dat 8.1 of ouder, vraag dan om een upgrade. Kan dat niet snel, vraag dan of het systeem tijdelijk van internet kan of achter extra beveiliging.
- Laat bevestigen dat de update geïnstalleerd is.
En plug-ins? De update van vandaag is een kleine beveiligingsupdate binnen dezelfde PHP-versie, bijvoorbeeld van 8.4.26 naar 8.4.27. Daarvoor hoef je plug-ins en thema's niet aan te passen: wat nu werkt, blijft werken. Anders ligt het als je van een oude PHP-versie (8.1 of ouder) naar een nieuwe moet. Oude of niet meer onderhouden plug-ins kunnen dan stuk gaan. Maak dan eerst een back-up, werk plug-ins en thema's bij, test bij voorkeur op een kopie van de site en vervang plug-ins die al jaren geen update meer kregen.
Staat je website achter Cloudflare? Cloudflare heeft voor alle klanten, ook met een gratis account, al beschermingsregels aangezet tegen de bekende aanvalsmethoden. Dat helpt, maar volgens Cloudflare zelf is het een noodmaatregel: de PHP-update blijft nodig.
Voor IT-verantwoordelijken en directie: leg per toepassing vandaag drie dingen vast. Wie beheert de PHP-installatie eronder (eigen IT, hoster of softwareleverancier)? Wie voert de update uit, en wanneer? En wie controleert daarna of alles nog werkt, zoals inloggen, gegevens opslaan en koppelingen met andere systemen? "Het is geregeld" is pas bruikbaar als duidelijk is wat er is gecontroleerd, welke actie nodig was en of die is afgerond.
Twijfel je of je PHP gebruikt? Ga ervan uit dat het zo is als je een WordPress-site, webshop, klantportaal of eigen webapplicatie hebt, en vraag het na.
Draai je bij een hostingpartij op PHP 8.3 of nieuwer? Dan is het risico kleiner: de meeste hosters installeren de update zelf. Vraag wel even na of en wanneer dat gebeurt.
Voor technici
- Wat bekend is: PHP-release vandaag 14:00 UTC voor twee kwetsbaarheden, beide CVSS v4.0 9,2. Volgens watchTowr remote code execution. Onderzoekers gebruiken CVE-2026-109618 en CVE-2026-109619 en de bijnaam php2shell; PHP noemt zelf nog geen nummers; ze zijn bij MITRE gereserveerd maar nog niet gepubliceerd. PHP kan eerder releasen als details uitlekken of misbruik opduikt.
- Versies: huidig zijn 8.5.11, 8.4.26, 8.3.35 en 8.2.34. Verwacht worden 8.5.12, 8.4.27, 8.3.36 en 8.2.35 (onder meer volgens Alpine Linux en Kevin Beaumont, niet bevestigd door PHP). 8.1 en ouder zijn end-of-life en krijgen geen fix. Let op: 8.2 krijgt na eind 2026 geen beveiligingsupdates meer.
- Inventaris:
php -vop elke host, plus containers, hostingpanelen (cPanel, Plesk), appliances en Windows-software metphp-cgi. - Na de release: pakketupdate via je distributie of een nieuwe image bouwen, daarna PHP-FPM of de webserver herstarten. Bij Laravel in containers: image opnieuw bouwen en uitrollen. Internetgerichte systemen eerst. Controleer of je distributie of hoster de fix backport.
- Tijdelijke maatregel (onofficieel): PHP heeft geen workaround gepubliceerd. Op X adviseren veel onderzoekers in afwachting van de update
session.upload_progress.enabled = Offte zetten inphp.iniof de FPM-pool en PHP daarna te herladen. Dat zou een deel van het risico wegnemen, niet alles, en vervangt de update niet. De makers van WordPress-plug-in The SEO Framework melden dat het uitzetten van sessies de aanval bij hen niet tegenhield; zij hebben hun servers offline gehaald tot de patch er is. Reken dus niet op deze instelling alleen. Verder delen we bewust geen technische details over de lekken: alleen wat al breed openbaar is en helpt om je te beschermen. - Blokkade aan de rand (grof, onofficieel): tot je gepatcht hebt kun je in je WAF of reverse proxy (Cloudflare, nginx, Caddy, Traefik) alle
multipart/form-data-verzoeken weigeren, en verzoeken met eenPHPSESSID-cookie of -parameter. Daarmee werken uploads en sommige formulieren tijdelijk niet. Volgens meerdere onderzoekers is dit op dit moment de sterkste tijdelijke maatregel, sterker dan alleen de php.ini-instelling. De multipart-blokkade is het belangrijkste deel; de cookieregel helpt alleen als je de standaardnaamPHPSESSIDgebruikt. Het beschermt niet als de server ook direct, buiten de proxy om, bereikbaar is. Zit je achter Cloudflare, dan staan hun eigen regels al aan. - Blootstelling beperken: beperk de toegang tot beheeromgevingen (bijvoorbeeld wp-admin) en zet PHP-diensten uit die je niet gebruikt. Wijs nu al eigenaren en een tijdvak aan, zodat je binnen enkele uren na de release kunt patchen.
- Kun je niet direct patchen: CERT-EU adviseert internetgerichte applicaties te overwegen af te schermen van het publieke netwerk tot de fix er is. Voor end-of-life: upgraden, offline halen, of achter een VPN of WAF.
- Detectie: alert op
php-fpm,php-cgi,httpdofapache2die een shell (sh,bash,cmd.exe), interpreter (python,perl) of downloadtool (curl,wget,nc) starten, en op patronen als/dev/tcp/ofmkfifo. Florian Roths process-watcher logt op Linux zonder EDR wat PHP opstart (hij voorkomt niets). - Bij een vondst (naar Huntress): server isoleren, web- en PHP-logs veiligstellen, zoeken naar webshells, nieuwe bestanden in de webroot, cronjobs, geplande taken en accounts.
Wat nog niet bekend is
Welke versies geraakt zijn, welk onderdeel van PHP, en of een aanval een bepaalde configuratie of inlog vereist, maakt PHP pas bij de release bekend. De ernstscore van 10,0 die online rondgaat komt uit het uitgelekte bericht; PHP zelf geeft 9,2. We werken dit bericht bij zodra de officiële informatie er is.
Beeld: PHP-logo door Colin Viebrock (CC BY-SA 4.0), door IBgids op een achtergrond geplaatst; achtergrond via Unsplash.
Bronnen: PHP, CERT-EU, W3Techs, Hadrian, The Hacker News, Huntress, Sansec, Beazley Security, SecurityWeek, Tweakers, Akamai, Censys, en berichten op X van The PHP Foundation en Dane Knecht (Cloudflare).












