De WordPress-kwetsbaarheid CVE-2026-119977 wordt actief misbruikt. Een aanvaller kan zonder in te loggen code uitvoeren op je webserver, en dat raakt elke WordPress-versie van 4.7 tot en met 7.1.3. Update naar 7.1.4, en zoek vandaag uit hoeveel WordPress-sites je organisatie eigenlijk heeft.
Dat tweede is lastiger dan het klinkt.
Wat is de WordPress-kwetsbaarheid CVE-2026-119977?
WordPress bracht op 28 oktober versie 7.1.4 uit als securityrelease. De belangrijkste fix gaat over een zwakke plek in het updateproces van WordPress zelf, die tijdens het bijwerken kan leiden tot het uitvoeren van code op afstand. In dezelfde release zitten nog ruim tien andere beveiligingsfixes, vooral voor stored XSS, plus een update van de meegeleverde rootcertificaten.
Op 4 november zette het NCSC er een waarschuwing over online. Het gaat om CVE-2026-119977 in WordPress Core, versie 4.7 tot en met 7.1.3. Het is een race condition: tijdens het korte moment waarop WordPress wordt bijgewerkt, kan een aanvaller zonder account schadelijke code op de server uitvoeren. Hij moet dan wel snel zijn, want het tijdsvenster is klein. Het NCSC meldt dat het lek al wordt misbruikt.
Waarom "kans laag" je niet moet geruststellen
Het NCSC geeft het lek een risicoscore van 8.1 en schat de kans op misbruik laag in, de mogelijke schade hoog. Wie alleen naar die eerste helft kijkt, zet het op de lijst voor volgende maand.
Dat vind ik een vergissing. Een lage kans zegt iets over hoe lastig de aanval is, niet over of hij gebeurt. Dat hij gebeurt, staat in dezelfde waarschuwing. En de schade gaat verder dan een bekladde homepage: wie code op je webserver uitvoert, kan alles wat die server kan. Formulieren met persoonsgegevens, koppelingen naar je CRM of je vacaturesysteem, API-sleutels in een configuratiebestand. Mijn advies: behandel dit als een actief misbruikt kritiek lek, met de doorlooptijd die daarbij hoort.
Welke WordPress-sites heb je eigenlijk?
Het lastigste deel is de inventaris. Bij veel organisaties staat de hoofdwebsite netjes in de CMDB en in de scope van de pentest. Maar WordPress zit ook op plekken waar security niet kijkt. De campagnesite die marketing twee jaar geleden liet bouwen. De werkenbij-site van een dochterbedrijf. Een evenementenpagina op een los subdomein, gehost door het webbureau dat er destijds de offerte voor won.
Die sites hebben vaak geen eigenaar in IT. Marketing betaalt de factuur, het webbureau doet het onderhoud op afroep, en of updates automatisch draaien weet niemand precies. Bij een lek als dit vraagt de CISO "zijn wij kwetsbaar?", en het eerlijke antwoord is dan meestal: dat moeten we uitzoeken.
Een site die op jouw domein draait, hoort wat mij betreft in jouw vulnerability management, ongeacht wie hem heeft laten bouwen. Voor een aanvaller is het gewoon jouw server.
Is updaten genoeg?
Voor wie op de 7.1-tak zit, is 7.1.4 de fix. Sites met automatische achtergrondupdates beginnen volgens WordPress vanzelf aan de update. Controleer wel of dat ook echt gebeurd is: een uitgeschakelde automatische update of een plugin die het proces blokkeert, zie je pas als je ernaar kijkt.
Draai je een oudere versie, dan ligt het minder simpel. WordPress schreef bij de release dat de fixes uit beleefdheid worden teruggezet naar alle takken die nog securityfixes krijgen, nu tot en met 4.7, maar dat die backports nog in uitvoering waren. Alleen de nieuwste versie wordt actief ondersteund. Zit je op een oude tak, kijk dan of er voor jouw versie al een gepatchte release is. Is die er niet, dan is overstappen naar 7.1.4 de veiligste route, ook al betekent dat testen met je thema en plugins.
Er speelt nog iets. Het lek zit in het updateproces zelf, en het NCSC meldt actief misbruik. Was je site al kwetsbaar en bereikbaar voordat je updatete, dan sluit de patch het gat maar zegt hij niets over wat er eerder is gebeurd. Laat je beheerder daarom nakijken of er onbekende bestanden, beheerdersaccounts of geplande taken zijn bijgekomen. Twijfel je, haal er dan iemand met DFIR-ervaring bij voordat je de site gewoon weer laat draaien.
Wat moet je deze week doen?
- Maak een lijst van alle WordPress-installaties op je domeinen en subdomeinen, ook die bij een extern webbureau draaien.
- Noteer per site de versie en wie hem beheert. Alles onder 7.1.4 krijgt vandaag een update of een gepatchte release voor die tak.
- Controleer of automatische updates aanstaan en of de update echt is doorgevoerd.
- Laat sites die kwetsbaar en publiek bereikbaar waren nakijken op sporen van misbruik.
- Leg vast wie in de toekomst eigenaar is van elke site, met een afspraak over hoe snel kritieke updates erop moeten.
Dit is de derde keer in een paar weken dat hetzelfde patroon langskomt. Bij PHP2Shell en bij het GitLab-lek was de patch ook snel beschikbaar. Uitzoeken waar alles draait en wie het oppakt, kostte de tijd.
Wie heb je hiervoor nodig?
Voor de update zelf volstaat je beheerder of je webbureau. Voor de vraag erachter niet. Wie een volledig overzicht wil van wat er op het internet hangt, en wil dat elk kritiek lek binnen een vaste termijn tot de laatste server wordt doorgezet, heeft iemand nodig die vulnerability management als vak heeft. Bij maatwerk op WordPress, eigen plugins en koppelingen, komt daar een application security-specialist bij.
Via MVPeople zetten we interim securityprofessionals in voor precies dit soort klussen. Mis je die capaciteit nu? Bel of mail me via de contactpagina, dan kijken we samen wat je nodig hebt.
