WordPress heeft een nieuwe beveiligingsmaatregel aangekondigd die draait om automatische pluginreviews. Het doel: elke pluginrelease eerst kritisch beoordelen op mogelijke risico’s, voordat die via de WordPress.org update-API bij gebruikers terechtkomt. Dat is belangrijk, omdat een plugin vandaag veilig kan lijken, maar bij een latere versie een kwetsbaarheid of zelfs kwaadaardige code kan introduceren.
Met de aanpak probeert WordPress de zogeheten ‘tussenstap’ te dichten tussen het moment waarop code wordt uitgegeven en het moment waarop downstream-gebruikers de update automatisch binnenkrijgen. Minder directe verspreiding betekent meer tijd om problemen te signaleren én te verhelpen.
Waarom automatische pluginreviews nodig zijn
Tot nu toe konden plugins en thema’s na een commit of release doorstromen naar gebruikers via auto-updates. WordPress stelt dat er geen consistente beoordeling bestond tussen de oplevering van een versie en de distributie naar gebruikers. Juist die fase is gevoelig: een veilige release kan later toch veranderen door nieuwe code, en kwaadwillenden kunnen proberen een update te laten landen zodra die live is.
WordPress legt uit dat een geautomatiseerde review hiermee een extra controlepunt vormt. Daarmee verkleint het platform de kans dat een problematische versie meteen in productie bij eindgebruikers belandt.
“Protect The Shire”: cooldown en een security score
Deze maatregel sluit aan op een bredere beveiligingsinitiative binnen WordPress: Protect The Shire. Sinds 5 juni 2026 geldt voor zowel plugins als thema’s een cooldown-periode voordat ze via automatische updates worden verspreid. De cooldown is daarbij inmiddels teruggebracht naar 6 uur (was eerder 24 uur).
In die cooldown-periode worden de wijzigingen in de release geanalyseerd. WordPress geeft aan dat de beoordeling gebeurt met AI-modellen en Jetpack Scan. De resultaten worden vervolgens samengevat in een security score.
Het werkt als volgt:
- De release doorloopt de analyse tijdens de cooldown.
- De uitkomsten worden gecombineerd tot een security score.
- Hoge-risico releases worden automatisch geblokkeerd zodra de review is afgerond.
- Releases onder de drempel gaan door met het normale proces.
Wat gebeurde er in de praktijk?
WordPress noemt een concrete casus waarin automatische analyse een backdoor detecteerde in een pluginrelease met ongeveer 20.000 actieve installaties. Die problematische release is gelabeld rond 28 juli 2026.
Omdat de release binnen de cooldown-marge viel, werd de gecompromitteerde versie uiteindelijk niet via de WordPress.org update-API gedistribueerd. Dit laat zien waarom die extra tijd en reviewstap zo essentieel is.
De plugin werd bovendien kort daarna afgesloten voor downloads nadat het Plugins Team door WordPress security partner Wordfence was gewaarschuwd (binnen 26 minuten na de melding). De naam van de plugin is daarbij niet gedeeld.
Geen “hoge-risico” betekent niet automatisch “kwaadwillig”
Een belangrijke nuance: een hogere security score betekent niet automatisch dat de update opzettelijk kwaadaardig is. WordPress geeft aan dat de score ook kan stijgen wanneer er onbedoeld kwetsbaarheden in de code zijn terechtgekomen.
Met andere woorden: automatische pluginreviews zijn vooral bedoeld om risicoklassen te herkennen, vergelijkbaar met wat je van een security audit verwacht. Soms wijst dat op malware, maar soms vooral op fouten in codekwaliteit of security hygiene.
Waar let WordPress precies op?
WordPress beschrijft dat de review zoekt naar dezelfde typen kwetsbaarheden die ook bij een handmatige security audit aan bod komen. Daarbij hamert WordPress op het volgen van WordPress Coding Standards en het gebruik van PHP_CodeSniffer (PHPCS) om code en kwaliteit te valideren.
Voor ontwikkelaars die extensies voor WooCommerce publiceren, raadt WordPress bovendien aan om tests uit te voeren via de Quality Insights Toolkit (QIT).
Naast deze basis richten de checks zich ook op patronen die de security score kunnen verhogen, zoals:
- REST-, AJAX- of admin-post-endpoints zonder goede capability check. Alleen een nonce is geen autorisatie.
- Queries die niet worden opgebouwd met $wpdb->prepare().
- Bestands-, upload-, delete- of include-paden die worden samengesteld op basis van requestdata.
- Gebruik van unserialize() op data uit requests of op responsen van externe partijen.
- Opties, user meta of instellingen die worden geschreven vanuit endpoints die bereikbaar zijn voor subscribers of zelfs anonieme gebruikers.
- Code die tijdens runtime wordt opgehaald of geëvalueerd, of code die is geobfusceerd of packed.
Wat gebeurt er als een release wordt geblokkeerd?
Wanneer de security score boven de high-risk drempel uitkomt, wordt de release automatisch tegengehouden. In dat geval ontvangt de maintainer/committer een e-mail met de bevindingen.
WordPress geeft aan dat e-mails alleen worden verstuurd in scenario’s waarin een release daadwerkelijk wordt geblokkeerd. Dat maakt het proces gericht en voorkomt ruis bij updates die door de review komen.
De ontwikkelaar kan vervolgens de beperkingen laten vervallen door:
- de aangedragen issues te beoordelen en op te lossen;
- een nieuwe release te publiceren;
- en te zorgen dat die nieuwe versie opnieuw onder de high-risk drempel valt.
Als een bevinding onjuist lijkt, kunnen auteurs contact opnemen met het Plugins Team. WordPress benadrukt daarbij dat een gefixt release vaak sneller is dan wachten op een handmatige beoordeling van een bezwaar.
Tips voor ontwikkelaars: voorkom een hoge security score
Wil je als ontwikkelaar voorkomen dat je update blokkeert blijft hangen? Dan helpt het om je releaseproces en codebase al vóór publicatie op orde te hebben. Een paar praktische richtingen op basis van de beschreven risico-signalen:
- Controleer endpoints (REST/AJAX/admin-post) op correcte capability checks.
- Gebruik waar van toepassing altijd $wpdb->prepare() voor databasequeries.
- Vermijd constructies waarbij paden of includes rechtstreeks uit requestdata ontstaan.
- Wees voorzichtig met serialisatie/dsererialisatie van gebruikersinput en met runtime evaluatie van externe code.
- Test je WooCommerce-extensie met Quality Insights Toolkit (QIT) en validerende linters zoals PHP_CodeSniffer.
Door vroeg te testen, verklein je de kans dat de release pas tijdens de automatische pluginreviews problemen oplevert.
Impact op security voor gebruikers
Voor gebruikers verandert er vooral iets aan de snelheid waarmee risico’s kunnen doorstromen. Met een cooldown en een automatische security review wordt een potentieel gevaarlijke versie minder snel onderdeel van het normale updatepad.
Dat betekent niet dat alle risico’s verdwijnen—WordPress erkent impliciet dat kwetsbaarheden en security fouten ook onbedoeld kunnen ontstaan. Maar de extra reviewstap helpt wél om tijd te winnen en om de kans op “live” verspreiding van een problematische versie te verlagen.
Als je kijkt naar bredere thema’s binnen security rondom updates en supply chain risico’s, past dit in dezelfde lijn: voorkomen is beter dan genezen. Eerder op de site is bijvoorbeeld ook aandacht besteed aan hoe AI en aanvallers kunnen proberen softwareketens te verstoren, zoals bij berichten over backdoors via kwetsbaarheden in Artifactory. Het onderstreept dat ketens van ontwikkeling naar distributie extra aandacht verdienen.
Volgende stappen: volg releases en verbeter je release discipline
Voor teams die plugins beheren is het advies vooral om release discipline te verhogen. Houd rekening met de cooldownperiode en beschouw de automatische pluginreviews niet als een ‘extra hindernis’, maar als een signaal dat je code mogelijk niet voldoet aan security verwachtingen.
Wie actief bezig is met het volwassen maken van security in ontwikkel- en publicatieprocessen kan daarnaast ook kijken naar eerder gedeelde inzichten over beveiliging van AI-agenten en controlemechanismen. Ook daar draait het telkens om: risico’s vroeg herkennen, en systemen niet blind laten vertrouwen op de volgende stap in de keten.
Conclusie
WordPress introduceert automatische pluginreviews om releases eerst te laten analyseren en beoordelen voordat ze via de WordPress.org update-API worden verspreid. Samen met de cooldown in Protect The Shire vormt dit een extra controlepunt waarmee hoge-risico updates automatisch kunnen worden geblokkeerd.
Of het nu gaat om onbedoelde kwetsbaarheden of om schadelijke code: door het proces te vertragen én te toetsen, wint WordPress tijd voor detectie en herstel. Dat komt zowel de betrouwbaarheid van het WordPress-ecosysteem als de veiligheid van eindgebruikers ten goede.
Bron: https://thehackernews.com/2026/09/wordpress-adds-automated-plugin-reviews.html
