WordPress beveiliging: versie 7.0.3 dicht 12 lekken, dit moet je weten

Twaalf kwetsbaarheden in één release is niet normaal voor WordPress core. De meeste lekken zitten in blokken die bijdragers kunnen gebruiken, zoals de Post Date block, Post Content block en de Quick Edit-functie. XSS staat voor Cross-Site Scripting: een aanval waarbij kwaadaardige code de pagina ingaat en de browser van een nietsvermoedende gebruiker die code dan uitvoert.

De meeste van die twaalf vereisen een account met minimaal de rol Contributor, wat het risico beperkt. Maar drie kwetsbaarheden vallen in een andere categorie. Die bespreek ik hieronder apart.

Overigens heeft de toename van gevonden lekken deels te maken met AI-gestuurde beveiligingstests. Beveiligingsonderzoekers gebruiken AI-tools om code sneller te scannen op patronen die mensen missen. Goed voor de veiligheid op lange termijn, maar het betekent ook dat het aantal meldingen de komende tijd niet daalt.

Stel je voor: een aanvaller bouwt een nep-website met een link die eruitziet als jouw WordPress-inlogpagina. Als een beheerder of redacteur op die link klikt, draait er kwaadaardige code in zijn browser. In het ergste geval escaleert dat naar Remote Code Execution (RCE), wat inhoudt dat code op jouw server actief wordt.

Dat klinkt alarmerend, en dat is het ook, maar de aanval vereist social engineering. De aanvaller moet de juiste persoon overtuigen om op de juiste link te klikken. Beveiligingsonderzoekers schatten de kans op actief misbruik als laag in, juist omdat die menselijke stap er altijd tussen zit.

De fix gaat terug tot alle WordPress-versies vanaf 4.7. Draai je nog een oudere versie, dan is de patch er alsnog, maar je moet wel updaten.

Voor wie zijn WordPress-installaties beheert: AI inzetten om WordPress-code te analyseren en te verbeteren helpt je sneller onveilige patronen te spotten in custom code die je zelf hebt toegevoegd.

SSRF in URL-validatie klinkt technisch, maar de kern is dit: als een aanvaller de server laat communiceren met interne IP-adressen (link-local ranges), kan gevoelige informatie uitlekken die normaal niet van buitenaf bereikbaar is. Denk aan configuratiedata van je server of interne services. Hoe ernstig dit precies is voor standaard WordPress-hosting is nog niet volledig gedocumenteerd, maar de patch is er en dat telt.

De privilege-escalatie op multisites is relevant als je WordPress Multisite draait met open gebruikersregistratie. Een normale gebruiker kan dan een nieuwe subsite aanmaken op jouw netwerk. Voor een universiteits-intranet of een platform met honderden subsites is dat een echt probleem. Voor een standaard WordPress-site met één domein speelt dit niet.

Ga naar je WordPress-dashboard, klik op Instellingen, dan Netwerk als je multisite draait. Staat gebruikersregistratie aan en weet je niet waarom, zet hem dan uit.