Stand van 22 oktober 2026. Ik werk dit artikel bij zodra er nieuws is.
Op 21 oktober gingen DigiD, MijnOverheid en talloze andere websites uit voorzorg offline. De oorzaak: twee kritieke lekken in PHP, de programmeertaal onder WordPress, WooCommerce en een groot deel van het web. Draait jouw site op PHP, dan zit de oplossing niet in je WordPress-dashboard maar bij je hoster. Dit is wat er is gebeurd, wat het met je Google-posities doet en wat je vandaag regelt.
Het PHP-team kondigde op 20 oktober een beveiligingsupdate aan voor woensdag 21 oktober om 16.00 uur. Vóór de release was er al publieke code om de lekken te misbruiken, meldde het NCSC. Het NCSC adviseerde eigenaren van PHP-systemen om per systeem een risicoafweging te maken en ze zo nodig tijdelijk offline te halen. Dat deden veel organisaties: Overheid.nl, MijnOverheid.nl en DigiD, gemeenten, de VNG, ziekenhuizen en NCSC.nl zelf. De meeste sites van het Rijk bleven online omdat ze geen PHP gebruiken. Na de release waren veel sites binnen enkele uren terug.
De lekken heten CVE-2026-109618 en CVE-2026-109619 en scoren allebei 9,2 op 10. Een aanvaller hoeft niet in te loggen: een webverzoek volstaat om eigen code op je server te laten draaien. Volgens het NCSC-advies zijn alle PHP-installaties die webverzoeken verwerken getroffen, en zijn alle versies vanaf PHP 5 in ieder geval kwetsbaar.
De fix zit in PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. PHP 8.1 en ouder worden niet meer regulier ondersteund. Voor 7.4, 8.0 en 8.1 is alleen een minimale broncodepatch beschikbaar, bedoeld voor wie PHP zelf compileert of een gepatchte build van zijn leverancier krijgt. Tijdelijke maatregelen van PHP beperken alleen specifieke aanvalspaden. Alleen de update verhelpt de lekken volledig.
Of er misbruik is, hangt af van wie je vraagt. Het NCSC had woensdagavond nog geen actief misbruik gezien, maar zag wel meer verkeer van partijen die kwetsbare sites zoeken. Amazon zag de eerste poging al op 17 oktober, vier dagen vóór de publieke release, en meldt dat PHP2Shell nu breed wordt misbruikt. Cloudflare en watchTowr melden ook aanvalspogingen. Of zulke pogingen bij echte sites zijn geslaagd, is volgens Amazon nog onduidelijk, en een bevestigde inbraak bij een specifieke site heb ik niet gevonden. Beveiligingsexperts waarschuwen dat de gevolgen maanden kunnen duren: veel systemen worden niet direct bijgewerkt, en een patch maakt een eerdere inbraak niet ongedaan.
PHP (PHP: Hypertext Preprocessor) is een programmeertaal die op de server draait. Het bouwt de pagina's van een website op, regelt het inloggen, verwerkt betalingen en praat met de database. Volgens de PHP Foundation draait ongeveer 70 procent van alle websites op PHP of iets wat ervan is afgeleid. WordPress, WooCommerce, Joomla, Drupal en Magento zijn erop gebouwd. Ook hostingpanelen en software van leveranciers kunnen een eigen PHP-installatie bevatten, zonder dat de productdocumentatie dat vermeldt. Voor die producten wacht je op de update van de leverancier.
Als mkb'er heb je meestal geen eigen serverbeheerder. Dat maakt je afhankelijk van twee partijen: je hoster en je webbouwer. Jouw taak is vragen en controleren.
Je PHP-versie vind je in WordPress onder Tools, Site Health (Sitediagnose), tabblad Info, onderdeel Server. Zie je 8.2.35, 8.3.36, 8.4.27 of 8.5.12, of een latere versie binnen dezelfde reeks, dan zit de fix erin. Zie je een lager nummer, dan weet je niets. Linux-distributies als Ubuntu, Debian en Red Hat, en sommige hosters, verwerken de fix vaak zonder het versienummer te veranderen. Alleen je hoster kan het bevestigen.
Zo zien de vragen aan je hoster eruit. De tweede komt uit het advies van Amazon om het onderzoek bij 17 oktober te beginnen en niet bij de dag van de patch:
Hallo, mijn site draait op PHP [versie]. Is de fix voor CVE-2026-109618 en CVE-2026-109619 op mijn server geïnstalleerd, en op welke datum? Zo niet, wanneer volgt dat? Zijn de serverlogs vanaf 17 oktober gecontroleerd op misbruik?
Een paar uur uitval is voor Google in de regel geen probleem. Bij serverfouten (5xx) vertraagt Googlebot het crawlen, blijven al geïndexeerde pagina's in de index staan en neemt de crawlsnelheid weer geleidelijk toe zodra je site 200 teruggeeft. Pas als de fout blijft, vallen pagina's er uiteindelijk uit.
Google noemt een hele site uitzetten een extreme maatregel die je hooguit een paar dagen mag volhouden. Moet het toch, houd je dan aan de regels van Google:
Gaf je onderhoudspagina wél een 200 of een 404? Kijk in Search Console bij Instellingen, Crawlstatistieken, of er een piek aan fouten staat, en of je belangrijkste pagina's nog geïndexeerd zijn. Vraag voor de homepage opnieuw indexering aan. Google noemt dat een werkbare route voor een beperkt aantal pagina's.
Wie via deze lekken binnenkomt, kan op je site doen wat je server kan. Voor je zoekresultaten betekent dat meestal spam-pagina's onder jouw domein (casino, medicijnen), verborgen doorverwijzingen die alleen werken als bezoekers via Google of vanaf een telefoon komen, en geïnjecteerde links. Search Console meldt dat onder Beveiligingsproblemen als Hacked. Na het opschonen vraag je een review aan, en die duurt enkele dagen tot enkele weken. Hoe je dat aanpakt staat in Website gehackt: zo herken je SEO-spam en herstel je je posities.
Controleer dit in vijf minuten, ook als je hoster zegt dat alles gepatcht is:
Vind je iets, laat je hoster de server dan scannen en een back-up van vóór het moment terugzetten. Wijzig daarna alle wachtwoorden: WordPress, hosting en database. Staan er persoonsgegevens achter je site, dan kan het een datalek zijn. Een datalek met risico voor betrokkenen meld je binnen 72 uur bij de Autoriteit Persoonsgegevens.
Deze site draait op Webflow. Op 21 oktober was er hier niets te patchen: geen server, geen PHP-versie, geen plugin om bij te werken. Dat is het verschil dat deze week laat zien. Bij WordPress was WordPress zelf niet het probleem, de server eronder wel, en wie die server bijwerkt is niet altijd duidelijk. Ik bouw ook Webflow-sites, dus weeg mijn mening mee. Wil je de afweging zelf maken? Lees dan Webflow of WordPress: wat wint voor SEO (Engels).
Het NCSC adviseert per systeem een risicoafweging. Zegt je hoster dat de fix of een tijdelijke bescherming erop staat, laat de site dan online en houd hem in de gaten. Kun je niet patchen en staat er klantdata achter, zoals bestellingen of accounts, dan is offline met een 503 het veiligste.
Nee. De fout zit in PHP zelf, onder WordPress en zijn plugins. Bij Apache met mod_php kan een aanval zelfs plaatsvinden voordat WordPress of een plugin draait.
Vraag het schriftelijk en bewaar het antwoord. Blijft een duidelijke datum uit, dan is dit een goed moment om een andere hoster te zoeken.
Niet inhoudelijk. Wel verdient je technische basis na deze week een controle. Mijn technische SEO-auditgids (Engels) loopt de stappen door. Wil je een tweede paar ogen op de SEO-kant van je site? Mail mo@sahardid.com, of lees hoe ik als freelance SEO-specialist voor het mkb werk.