Kritieke WordPress-kwetsbaarheid maakt volledige serverovername mogelijk

WordPress heeft een kritieke beveiligingskwetsbaarheid verholpen waarmee een aanvaller zonder inloggegevens onder bepaalde omstandigheden willekeurige PHP-code op een server kan laten uitvoeren. De kwetsbaarheid, CVE-2026-87902, wordt inmiddels actief misbruikt. Vooral organisaties met vergeten, oude of onvoldoende geïnventariseerde WordPress-installaties lopen risico.

WordPress heeft op 22 september een beveiligingsupdate uitgebracht voor een kwetsbaarheid met een CVSS-score van 9,2. Het beveiligingslek maakt het onder bepaalde omstandigheden mogelijk dat een niet-geauthenticeerde aanvaller een lokaal PHP-bestand buiten de normale themamappen laat opnemen en uitvoeren.

Wanneer aan de vereiste voorwaarden wordt voldaan, kan dit uiteindelijk leiden tot remote code execution (RCE). Dat betekent dat een aanvaller code op de server kan laten uitvoeren zonder daarvoor eerst een WordPress-account of beheerdersrechten te hoeven verkrijgen.

Het probleem is inmiddels niet uitsluitend theoretisch. Kort na het beschikbaar komen van de beveiligingsupdate werden aanvallen en scans waargenomen waarbij aanvallers probeerden de kwetsbaarheid daadwerkelijk te misbruiken.

Van bestand naar volledige servercompromittering

Op zichzelf klinkt het probleem misschien beperkt: een aanvaller kan onder bepaalde omstandigheden een lokaal PHP-bestand laten gebruiken bij de verwerking van een WordPress-paginatemplate.

De gevolgen kunnen echter aanzienlijk zijn wanneer een aanvaller erin slaagt om eerst een kwaadaardig PHP-bestand op de server te plaatsen.

Zodra zo'n bestand vervolgens door WordPress wordt ingeladen en uitgevoerd, beschikt de aanvaller in feite over een mechanisme om opdrachten uit te voeren met de rechten van het betreffende webproces.

Vanaf dat moment kan een aanval zich snel uitbreiden.

Een aanvaller kan bijvoorbeeld proberen om:

• het bestand wp-config.php uit te lezen;
• databasegegevens te bemachtigen;
• WordPress-authenticatiesleutels en salts te stelen;
• nieuwe administratoraccounts aan te maken;
• bestaande gebruikersaccounts te manipuleren;
• formulieren voor betalingen, contactaanvragen of leadgeneratie te wijzigen;
• bezoekers naar andere websites door te sturen;
• aanvullende malware te installeren;
• blijvende toegang tot de server te creëren;
• gegevens uit de WordPress-database te verzamelen;
• andere applicaties of bestanden op dezelfde server te onderzoeken.

De uiteindelijke impact hangt af van de rechten van het webserverproces en van de manier waarop de betreffende server is ingericht. Een kwetsbare WordPress-installatie betekent daarom niet automatisch dat een volledige server of het gehele bedrijfsnetwerk wordt overgenomen, maar de kwetsbaarheid kan daar wel een belangrijk startpunt voor vormen.

Aanvallers gebruiken een ongebruikelijke tussenstap

Een opvallend onderdeel van de waargenomen aanvallen is het gebruik van pearcmd.php.

PEAR is een legitiem PHP-framework en pakketbeheersysteem. Het bestand pearcmd.php is dus op zichzelf geen malware. In bepaalde serveromgevingen kan het echter door een aanvaller worden misbruikt om bestanden op het systeem te schrijven.

Dat creëert een interessante aanvalsketen.

De aanvaller hoeft niet noodzakelijkerwijs rechtstreeks een kwaadaardig PHP-bestand in de WordPress-installatie te plaatsen. In plaats daarvan kan eerst een PHP-bestand worden aangemaakt op een andere locatie, bijvoorbeeld in /tmp. Vervolgens wordt de WordPress-kwetsbaarheid gebruikt om dat bestand te laten laden.

Het resultaat is een keten die er vereenvoudigd als volgt uitziet:

internet → kwetsbare WordPress-installatie → lokaal PHP-bestand → uitvoering van PHP-code → verdere compromittering

Dit is belangrijk voor beveiligingsteams omdat traditionele monitoring soms uitsluitend kijkt naar wijzigingen binnen de WordPress-directory.

Wanneer een aanvaller de eerste stap buiten de WordPress-installatie uitvoert, kan die activiteit aan dergelijke monitoring ontsnappen.

De kwetsbaarheid zit in template-resolutie

De technische oorzaak bevindt zich in de manier waarop WordPress onder bepaalde omstandigheden een paginatemplate probeert te vinden.

De kwetsbaarheid kan ervoor zorgen dat een aanvaller invloed krijgt op het bestand dat tijdens dit proces wordt geladen. In plaats van uitsluitend een toegestaan template binnen het actieve thema te gebruiken, kan onder specifieke omstandigheden een lokaal PHP-bestand buiten de bedoelde themamappen worden bereikt.

Dat is op zichzelf al een ernstig probleem, omdat het laden van een PHP-bestand niet hetzelfde is als het lezen van een tekstbestand.

Een PHP-bestand wordt door de server geïnterpreteerd.

Als een aanvaller controle heeft over de inhoud van dat bestand, kan het laden ervan daardoor veranderen in code-uitvoering.

De aanval werkt echter niet onder iedere denkbare WordPress-configuratie. Er moeten specifieke voorwaarden aanwezig zijn in zowel de serveromgeving als het actieve WordPress-thema. Dat maakt de kwetsbaarheid niet universeel exploiteerbaar, maar organisaties kunnen er ook niet van uitgaan dat hun omgeving automatisch veilig is.

Vooral oudere WordPress-installaties zijn een probleem

WordPress heeft de kwetsbaarheid opgelost in versie 7.1.2. De beveiligingscorrectie is daarnaast teruggebracht naar oudere ondersteunde versies, omdat het probleem een groot aantal WordPress-generaties raakt.

De kwetsbare versies lopen terug tot WordPress 4.7.0.

Dat is vanuit beveiligingsperspectief bijzonder relevant.

Een organisatie kan immers denken dat uitsluitend moderne WordPress-installaties onderdeel zijn van de infrastructuur, terwijl ergens nog een oude campagnewebsite, microsite of regionale website draait.

Die installatie kan jarenlang blijven functioneren zonder dat iemand er actief naar kijkt.

Juist dergelijke systemen vormen een aantrekkelijk doelwit.

Het grootste probleem kan buiten de bekende IT-inventaris liggen

Voor veel ondernemingen is de technische kwetsbaarheid zelf niet eens het moeilijkste onderdeel.

Het grotere probleem is simpelweg:

Weten organisaties wel waar al hun WordPress-installaties staan?

In theorie zou een onderneming een complete inventaris moeten hebben van alle publiek bereikbare websites en servers. In de praktijk ontstaat echter regelmatig een versnipperd landschap.

Een WordPress-site kan bijvoorbeeld zijn opgezet door:

• een marketingafdeling;
• een externe webbouwer;
• een reclamebureau;
• een dochteronderneming;
• een regionale organisatie;
• een tijdelijk projectteam;
• een externe leverancier;
• een organisatie die inmiddels is overgenomen;
• een afdeling die inmiddels is opgeheven.

De website kan vervolgens gewoon online blijven.

Het contract met de oorspronkelijke leverancier kan zijn afgelopen, de medewerkers die de site hebben opgezet kunnen zijn vertrokken en de website kan uit de centrale IT-documentatie zijn verdwenen.

Technisch gezien is de site nog steeds onderdeel van de digitale infrastructuur.

Voor een aanvaller maakt het echter niet uit of een website in een CMDB staat.

Marketingwebsites zijn geen uitzondering

Een veelgemaakte fout is om WordPress uitsluitend te associëren met blogs en kleine websites.

WordPress wordt ook gebruikt voor zakelijke websites, campagnes, nieuwsplatforms, kennisbanken, productpagina's en microsites.

Een grote onderneming kan daardoor tientallen of zelfs honderden verschillende websites hebben die geheel of gedeeltelijk op WordPress draaien.

Niet iedere installatie wordt noodzakelijkerwijs door het centrale securityteam beheerd.

Daarbij komt dat sommige websites jarenlang blijven draaien nadat de oorspronkelijke reden voor het bestaan ervan is verdwenen.

Een oude campagnewebsite kan bijvoorbeeld nog steeds bereikbaar zijn omdat niemand heeft besloten hem offline te halen.

Een vergeten WordPress-installatie is daarmee niet alleen een beheerprobleem, maar ook een potentieel beveiligingsprobleem.

Aanvallen begonnen vrijwel direct na de beveiligingsupdate

Een van de meest zorgwekkende aspecten van deze kwetsbaarheid is de snelheid waarmee aanvallers reageerden.

Volgens waarnemingen van beveiligingsonderzoekers verschenen kort na de publicatie van de WordPress-update al verzoeken die probeerden te bepalen of systemen kwetsbaar waren.

In eerste instantie ging het daarbij vooral om verkenning.

Aanvallers proberen in die fase vast te stellen:

• welke WordPress-versie draait;
• of een bepaalde aanvalsmethode werkt;
• welke bestanden bereikbaar zijn;
• hoe de server reageert;
• of de benodigde voorwaarden aanwezig zijn.

Daarna kan de aanval worden uitgebreid met een daadwerkelijke payload.

Bij deze kwetsbaarheid werden vervolgens ook pogingen waargenomen waarbij pearcmd.php werd gebruikt om PHP-bestanden op schijf te schrijven.

Dat is een belangrijk verschil.

Een scan die alleen probeert vast te stellen of een website kwetsbaar is, kan relatief onschuldig lijken. Zodra een aanvaller echter PHP-code op de server probeert te plaatsen en uit te voeren, verandert het karakter van de activiteit volledig.

Het tijdsvenster voor patchen wordt steeds kleiner

Deze gebeurtenis illustreert een ontwikkeling die beveiligingsteams al langer zien: zodra een kwetsbaarheid openbaar wordt gemaakt, begint de race tussen verdedigers en aanvallers.

Een beveiligingsupdate bevat namelijk vaak indirect informatie over de kwetsbaarheid zelf.

Een onderzoeker kan vóór de patch hebben vastgesteld dat een bepaald gedrag onveilig is. Nadat de ontwikkelaar het probleem heeft aangepast, kunnen beveiligingsonderzoekers en aanvallers de oude en nieuwe code naast elkaar leggen.

Het verschil tussen beide versies kan aanwijzingen geven over de oorzaak van het probleem.

Dit betekent dat het publiceren van een patch tegelijkertijd waardevolle informatie kan opleveren voor aanvallers.

Dat betekent niet dat beveiligingsupdates niet moeten worden gepubliceerd. Het betekent wel dat organisaties rekening moeten houden met een zeer korte periode tussen openbaarmaking van een kwetsbaarheid en daadwerkelijke exploitatie.

Bij een kritieke kwetsbaarheid op een internet-facing systeem kan wachten tot de volgende reguliere onderhoudsronde daarom grote risico's met zich meebrengen.

Automatische updates zijn nuttig, maar geen volledige oplossing

WordPress ondersteunt automatische beveiligingsupdates voor bepaalde releases. Voor veel kleinere websites kan dat een belangrijke beveiligingsmaatregel zijn.

Automatische updates lossen echter niet alle problemen op.

In grotere organisaties worden automatische wijzigingen soms bewust beperkt vanwege change-management, compatibiliteit of beschikbaarheid. Een onderneming wil eerst testen of een update geen problemen veroorzaakt met bijvoorbeeld:

• aangepaste thema's;
• plugins;
• betaalmodules;
• koppelingen met andere systemen;
• maatwerkcode;
• hostingconfiguraties;
• caching;
• authenticatiesystemen.

Dat zijn legitieme operationele overwegingen.

Het risico ontstaat wanneer een organisatie daardoor dagen of weken wacht met het uitrollen van een beveiligingsupdate voor een kwetsbaarheid waarmee een niet-ingelogde aanvaller mogelijk code kan uitvoeren.

Bij dergelijke kwetsbaarheden moet het patchproces daarom anders worden ingericht dan bij normale softwarewijzigingen.

Een update installeren is bovendien niet hetzelfde als patchen

Een belangrijk onderscheid is het verschil tussen een update uitvoeren en verifiëren dat een systeem daadwerkelijk gepatcht is.

Een beheerplatform kan bijvoorbeeld aangeven dat een update is uitgevoerd, terwijl:

• een andere WordPress-installatie vergeten is;
• een stagingomgeving nog kwetsbaar is;
• een oude back-up of kopie publiek bereikbaar is;
• een tweede website op dezelfde server niet is bijgewerkt;
• de update door een fout niet is voltooid;
• een externe leverancier de website beheert;
• een organisatie een website niet langer als onderdeel van haar IT-landschap beschouwt.

Daarom hoort verificatie een afzonderlijke stap in het proces te zijn.

Een effectieve aanpak bestaat bijvoorbeeld uit:

inventariseren → patchen → controleren → opnieuw scannen → monitoren

Niet alleen de centrale WordPress-installatie moet daarbij worden gecontroleerd, maar de volledige externe webomgeving.

Staging- en testomgevingen mogen niet worden vergeten

Ook ontwikkel-, test- en stagingomgevingen kunnen relevant zijn.

Een stagingwebsite die normaal gesproken niet voor het publiek bedoeld is, kan door een verkeerde configuratie alsnog rechtstreeks vanaf internet bereikbaar zijn.

Als daarop dezelfde kwetsbare WordPress-versie draait, kan die omgeving een ingang vormen voor een aanvaller.

Hetzelfde geldt voor oude kopieën van websites, tijdelijke omgevingen en subdomeinen.

Een organisatie kan daarom niet uitsluitend haar primaire domein controleren.

De vraag moet zijn:

Welke WordPress-installaties zijn vanaf internet bereikbaar en wie is ervoor verantwoordelijk?

Wat organisaties nu zouden moeten controleren

Organisaties die WordPress gebruiken, doen er verstandig aan om niet uitsluitend te controleren of hun hoofdwebsite is bijgewerkt.

Een praktische controle begint met een volledige inventarisatie van het externe weboppervlak.

Controleer daarbij onder meer:

1. Alle publieke domeinen en subdomeinen
   Zoek naar websites die mogelijk buiten de centrale IT-inventaris vallen.
2. Alle WordPress-installaties
   Controleer niet alleen de officiële bedrijfswebsite, maar ook microsites, campagnesites en regionale websites.
3. De geïnstalleerde WordPress-versie
   Kwetsbare versies moeten zo snel mogelijk worden bijgewerkt.
4. Staging-, test- en ontwikkelomgevingen
   Controleer of deze vanaf internet bereikbaar zijn.
5. Websites van dochterondernemingen en overgenomen bedrijven
   Oude infrastructuur blijft vaak langer bestaan dan verwacht.
6. Websites die door externe bureaus worden beheerd
   Leg expliciet vast wie verantwoordelijk is voor beveiligingsupdates.
7. Serverbestanden buiten de WordPress-directory
   Controleer op onverwachte PHP-bestanden, vooral wanneer er aanwijzingen zijn voor exploitatie.
8. Verdachte bestanden in tijdelijke directories
   Een bestand dat onverwacht in bijvoorbeeld /tmp verschijnt, verdient nader onderzoek.
9. Webserver- en applicatielogs
   Zoek naar verdachte verzoeken en pogingen om lokale PHP-bestanden te laden.
10. Nieuwe WordPress-administratoraccounts
    Controleer of er accounts zijn aangemaakt die niet door een bevoegde beheerder zijn geregistreerd.
11. Onverwachte wijzigingen in formulieren en templates
    Kwaadaardige wijzigingen kunnen bezoekers omleiden of gegevens onderscheppen.
12. Persistence-mechanismen
    Zelfs na het installeren van de patch moet worden onderzocht of een aanvaller al toegang heeft verkregen.

Patchen betekent niet automatisch dat een besmetting is verwijderd

Dit laatste punt is cruciaal.

Wanneer een organisatie een kwetsbare WordPress-site vandaag bijwerkt, betekent dat niet automatisch dat de site gisteren niet is gecompromitteerd.

Als een aanvaller vóór het patchen toegang heeft verkregen en vervolgens persistente code heeft geplaatst, kan die code na de update nog steeds aanwezig zijn.

Een beveiligingsupdate sluit dan de oorspronkelijke ingang af, maar verwijdert niet noodzakelijkerwijs de gevolgen van eerder misbruik.

Bij een vermoedelijke exploitatie moet daarom een uitgebreider incidentonderzoek worden uitgevoerd.

Daarbij kan worden gekeken naar:

• gewijzigde PHP-bestanden;
• nieuwe gebruikersaccounts;
• verdachte administratoractiviteiten;
• ongebruikelijke databasewijzigingen;
• gewijzigde thema's en plugins;
• onbekende cronjobs;
• verdachte processen;
• bestanden in tijdelijke directories;
• webserverlogs;
• uitgaande netwerkverbindingen;
• wijzigingen in authenticatiesleutels;
• onbekende scripts en backdoors.

De kwetsbaarheid is groter dan één WordPress-site

De belangrijkste les uit deze situatie is uiteindelijk niet alleen dat WordPress snel moet worden bijgewerkt.

Het probleem raakt een fundamenteler onderdeel van enterprise security: organisatiebreed zicht op internet-facing systemen.

Een onderneming kan uitgebreide beveiligingsprocessen hebben, maar alsnog een kwetsbare website missen wanneer die website niet in de inventaris staat.

Een oude marketingwebsite kan technisch net zo goed vanaf internet bereikbaar zijn als de primaire bedrijfswebsite.

Voor een aanvaller is het verschil tussen die twee niet relevant.

Daarom moet patchmanagement worden gekoppeld aan attack-surface management: eerst moet bekend zijn welke systemen bestaan en vanaf internet bereikbaar zijn, daarna kan worden vastgesteld welke software daarop draait en welke kwetsbaarheden aanwezig zijn.

Door: Drifter