WordPress heeft aangekondigd dat het een geautomatiseerde beveiligingsbeoordeling lanceert voor elke release van een plug-in voordat deze wordt gedistribueerd via de update-API van WordPress.org, om deze te analyseren op mogelijke beveiligingsproblemen en ervoor te zorgen dat er geen risico’s aan verbonden zijn.
“Nieuwe plug-ins worden beoordeeld voordat ze in de map terechtkomen, maar updates worden daarna continu verzonden”, zegt David Perez, co-leider van het WordPress Official Plugin Repository Team. “Een plug-in kan vandaag veilig zijn en in een toekomstige release een kwetsbaarheid of kwaadaardige code introduceren.”
WordPress zei dat het ontbreken van een “consistente beoordelingsstap” tussen het vastleggen van een release en de release van een plug-in voor downstream-gebruikers betekende dat dit de deur kon openen voor kwaadaardige aanvallen.
Het contentmanagementsysteem (CMS)-platform merkte op dat de geautomatiseerde beoordeling een achterdeur detecteerde die zich had gecommitteerd aan een release van een plug-in met ongeveer 20.000 actieve installaties op 28 juli 2026. Omdat de release binnen een afkoelperiode viel, werd de gecompromitteerde versie van de plug-in nooit gedistribueerd via de update-API van WordPress.org.
De plug-in werd gesloten voor downloads 26 minuten nadat het Plug-ins-team op de hoogte was gebracht van de update door WordPress-beveiligingsbedrijf Wordfence. WordPress heeft de naam van de plug-in niet bekendgemaakt.
Sinds 5 juni 2026 doorloopt elke WordPress-plug-in en elk thema een afkoelperiode voordat deze wordt gedistribueerd via automatische updates als onderdeel van een nieuw beveiligingsinitiatief genaamd Protect The Shire. Het idee is om enige wrijving in het proces te introduceren, zodat kwaadaardige updates de eindgebruikers niet onmiddellijk bereiken. De afkoelperiode bedraagt momenteel zes uur, vergeleken met 24 uur toen deze voor het eerst werd geïntroduceerd.
De nieuwste poging is bedoeld om nog een kritiek gat in de beveiliging te dichten: een score met een hoog risico voor een plug-in of thema-release zou de distributie automatisch moeten stoppen zonder tussenkomst van het Plug-ins-team. Het hele proces doorloopt de volgende stappen:
- Tijdens de afkoelperiode worden de wijzigingen in elke release op WordPress.org geanalyseerd door modellen voor kunstmatige intelligentie (AI) in combinatie met Jetpack Scan.
- De resultaten worden kruislings geverifieerd en gecombineerd in een beveiligingsscore: een hogere score vertaalt zich in een potentieel hoger risico.
- Releases met een hoge risicoscore worden automatisch geblokkeerd zodra de beoordeling is voltooid, terwijl releases onder die drempel het normale proces zullen voortzetten.
- Plugin-committers ontvangen een e-mail met de bevindingen. E-mails worden alleen verzonden in scenario’s waarin een plug-in is geblokkeerd.
Dat gezegd hebbende, is het de moeite waard om op te merken dat een hoge risicoscore niet noodzakelijkerwijs duidt op kwade bedoelingen, omdat de score ook rekening houdt met onbedoeld geïntroduceerde beveiligingsfouten, net zoals het opzettelijke malware markeert.
In een vervolgcommentaar legde Perez uit dat de beveiligingsbeoordeling “naar dezelfde kwetsbaarheidsklassen zoekt waar elke beveiligingsaudit naar zoekt”, waarbij hij ontwikkelaars aanspoorde om de WordPress Coding Standards en PHP_CodeSniffer (PHPCS)-regels te volgen om hun code te valideren en de codekwaliteit te garanderen. Ontwikkelaars die WooCommerce-extensies publiceren, wordt aangeraden het testplatform Quality Insights Toolkit (QIT) te gebruiken.
Andere patronen die de risicoscore ook zouden kunnen verhogen, staan hieronder:
- REST-, AJAX- of admin-post-eindpunten zonder een capaciteitscontrole (een nonce alleen is geen autorisatie)
- Query’s gebouwd zonder $wpdb->prepare()
- Bestandspaden, uploads, verwijderingen of opnames opgebouwd uit aanvraaggegevens
- unserialize() op verzoekgegevens of op een antwoord op afstand
- Opties, gebruikersmeta of instellingen geschreven vanaf eindpunten die bereikbaar zijn voor abonnees of niet-geverifieerde gebruikers
- Code opgehaald of geëvalueerd tijdens runtime, en onduidelijke of ingepakte code
Zodra een release is geblokkeerd, is de enige manier waarop de ontwikkelaar de beperkingen kan verwijderen, het beoordelen van de bevindingen, het oplossen van de problemen en het publiceren van een nieuwe release. Mocht de nieuwe release onder de hoge risicodrempel scoren, dan gaat deze verder via het normale cooldown-proces.
“Als een bevinding onjuist lijkt, kunnen auteurs contact opnemen met het Plugins-team”, aldus Perez. “Begrijp alsjeblieft dat het team een groot aantal recensies verwerkt, dus het publiceren van een vaste release is bijna altijd sneller dan wachten op een handmatige beoordeling van een bezwaar.”
