Development Tools

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

• 7 min leestijd • Sepp Stokbroekx
WordPress beveiligingsupdate 7.0.3 dicht XSS kwetsbaarheid op inlogpagina

Foto: RealToughCandy.com via Pexels

Kort antwoord

WordPress beveiliging staat onder druk: versie 7.0.3 dicht 12 kwetsbaarheden, waaronder een XSS-lek op de inlogpagina met een ernstscore van 8.9/10. Dat lek heeft geen ingelogde aanvaller nodig, maar werkt pas als iemand met een account op jouw site op iets klikt. Bij de meeste installaties regelt de automatische update dit, maar check het meteen in je dashboard.

Wat zit er precies in WordPress 7.0.3? 12 lekken in één release

WordPress 7.0.3 lost twaalf beveiligingsproblemen op in één keer. Dat is ongewoon veel. Normaal zijn het er één of twee per release. Drie van de twaalf zijn serieus genoeg om direct aandacht aan te geven: een XSS-lek op de inlogpagina, een SSRF-probleem in URL-validatie, en een privilege-escalatie op multisite-installaties. De rest is minder urgent maar alsnog de moeite van patchen waard.

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.

Het XSS-lek op de inlogpagina scoort 8.9/10. Hoe werkt dat? Ernstscore: 8.9/10

Dit is het gevaarlijkste lek van de batch. Het zit op de inlogpagina van WordPress en heeft een ernstscore van 8.9 op 10. Een aanvaller heeft geen account nodig om het lek te triggeren, vandaar de naam 'pre-auth'. Toch is de kans op misbruik beperkt, want de aanval werkt alleen als iemand met een account op jouw site op een speciaal geconstrueerde link klikt.

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 en privilege-escalatie: ook serieus nemen? Multisite-gebruikers: check registratie-instellingen

Naast het XSS-lek zijn er twee andere kwetsbaarheden die aandacht verdienen. SSRF staat voor Server-Side Request Forgery: een aanval waarbij de server verzoeken stuurt naar interne netwerkadressen. De derde is een privilege-escalatie op multisite-installaties waarbij een gewone gebruiker een nieuwe site kan aanmaken.

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.

Conclusie

WordPress 7.0.3 patcht 12 kwetsbaarheden, drie daarvan zijn serieus te nemen.

Het XSS-lek op de inlogpagina scoort 8.9/10 en kan leiden tot uitvoering van externe code.

Automatische updates helpen, maar handmatig controleren blijft de veiligste werkwijze.

Veelgestelde vragen

Bij de meeste WordPress-installaties staan automatische minor updates aan. Beveiligingsupdates zoals 7.0.3 installeert WordPress dan zelf. Twijfel je? Ga naar je dashboard, klik op Updates en check welke versie actief is. Staat er nog geen 7.0.3, klik dan nu op Bijwerken. WordPress legt uit hoe je automatische updates instelt en controleert.

Beveiligingsonderzoekers houden dit actief in de gaten, maar zien vooralsnog geen bewijs van massaal misbruik. De aanval vereist social engineering: iemand met een account op jouw site moet op een speciaal geconstrueerde link klikken. Dat beperkt de kans op willekeurige aanvallen. Updaten blijft de enige echte oplossing. Zie ook de basisprincipes van WordPress beveiliging voor een complete checklist.

Ja. WordPress heeft de fix voor het XSS-lek op de inlogpagina teruggeplaatst naar alle versies vanaf 4.7. Je hoeft dus niet per se naar 7.0.3 te upgraden voor die specifieke patch, maar je moet wel updaten naar de nieuwste versie binnen jouw tak. Check de officiële WordPress beveiligingsmededelingen voor de exacte versienummers per branch.

Meer over Webdevelopment