Er kwamen in 2025 11.334 nieuwe kwetsbaarheden bij in het WordPress-ecosysteem, en bijna twee derde daarvan kreeg het stempel «medium». Als alles belangrijk is, is niets het. Deze pagina rekent één melding door langs twee poorten die allebei open moeten staan voor er een echt risico is — en zegt erbij welke voorwaarde de zaak dichthoudt, en wat die voorwaarde breekt.
Cijfers: Patchstack, State of WordPress Security in 2026 en het halfjaarrapport 2025. Zie de bronnen onderaan.
Poort 1: is het rechtenniveau dat de kwetsbaarheid vraagt op jouw site überhaupt te bereiken? Poort 2: bestaat het ding dat de kwetsbaarheid raakt hier wel? Staat er één dicht, dan is de melding op jouw site geen risico — hoe hoog de score ook is. Het profiel links vul je één keer in en blijft in deze browser bewaard; rechts vul je per melding in.
Verdeling uit het Patchstack-halfjaarrapport 2025. Het jaarrapport over heel 2025 komt op 43% zonder account uit in plaats van 57,6%, dus het aandeel schommelt flink per periode. Lees de balk als een orde van grootte, niet als een meter.
Bijna elke melding noemt een minimaal rechtenniveau. Dat niveau is pas een risico als een vreemde het op jouw site kan bereiken — en dat is een vraag over je instellingen, niet over de plugin. De laatste kolom is de kolom die telt.
| Rol | Kan wat | Aandeel | Hoe komt een vreemde hieraan? |
|---|---|---|---|
| Geen account | Bezoekt de site als iedereen. Roept publieke endpoints aan, dus ook de REST-API en XML-RPC voor zover die open staan. | 57,6% | Hoeft niets te doen. Dit is de enige categorie die geautomatiseerd op schaal gescand en misbruikt wordt — en de reden dat de mediane tijd tot exploitatie vijf uur is. |
| Abonnee | Alleen read plus het eigen profiel. Geen berichten, geen uploads. Klinkt onschuldig; is de sleutel tot ruim een op de tien meldingen. |
11,5% | Als zelfregistratie aanstaat: zelf aanmaken. Of via een webshop, ledenplugin of forum, die eigen klantaccounts maken buiten de registratie-instelling om. Dat is de val: registratie dicht betekent niet dat er geen accounts zijn. |
| Bijdrager | Eigen concepten schrijven en bewerken. Kan niet publiceren en heeft géén recht om bestanden te uploaden, dus geen media. | 20,6% | Zelden zelf. Dit is het niveau van gastauteurs. Heb je die niet, dan is een op de vijf meldingen op jouw site meteen dood — het grootste enkele blok dat je met een instelling dichtzet. |
| Auteur | Publiceren, en upload_files erbij. Bestanden op de server krijgen is de opstap die de meeste ketens nodig hebben. |
10,3% samen met redacteur en beheerder | Alleen als je hem uitdeelt. Deel je auteursrechten uit aan mensen die je niet persoonlijk vertrouwt, dan verschuift je hele profiel. |
| Redacteur | Andermans berichten en pagina's bewerken, reacties modereren, en op een enkelvoudige installatie unfiltered_html — rauwe HTML en JavaScript plaatsen. Op multisite vervalt dat. |
valt in dezelfde 10,3% | Niet vanzelf. Wel het niveau waarop een gekaapt account meteen zichtbaar schade doet. |
| Beheerder | Alles. Plugins installeren, en met de ingebouwde bestandsbewerker ook PHP schrijven — de kortste weg van accountovername naar code op de server. | valt in dezelfde 10,3% | Niet via de kwetsbaarheid, maar ernaast: phishing, een hergebruikt wachtwoord, of een lek elders. Precies daarom is tweefactor op beheerders zwaarder dan welke plugin-update ook. |
«Geen enkele melding is hier uitbuitbaar» is een uitspraak over een voorbijganger of een sleepnet, niet over iemand die het op jou gemunt heeft. Een gerichte aanvaller begint niet bij de plugin maar bij je beheerders, en zit daarna op het niveau waar álles bereikbaar is. Het opruimen van een lek verlaagt daarom vaak niet wat er maximaal te bereiken valt, maar wél wie erbij kan. Dat is winst, ook als het cijfer niet zakt.
De goedkoopste manier om een kwetsbaarheid op te lossen is de plugin verwijderen. Dat mag alleen als je gemeten hebt dat hij niets doet — en «ik zie hem nergens» is geen meting. De volgorde hieronder sluit dat af in vier stappen.
Cache-Control: no-cache erbij, anders vergelijk je een pagina van vóór je wijziging met eentje van erna en bewijst «gelijk» niets.Uitzetten haalt de bestanden niet van de server. Ze blijven op hun eigen pad staan en zijn rechtstreeks opvraagbaar, en een deel van de kwetsbaarheden werkt juist via zo'n direct aangeroepen bestand in plaats van via WordPress. «Inactief» is dus geen mitigatie — verwijderen wel.
Je kunt elke plugin bijwerken en toch het grootste gat open laten staan: een oude installatie in een submap, of een back-uparchief dat in de webmap is blijven liggen. Die worden door niemand bijgewerkt en staan er vaak jaren.
Een compleet site-archief bevat naast de inhoud ook het configuratiebestand met de databasegegevens en de acht authenticatiesleutels, plus een dump van de gebruikerstabel. Vier dingen komen daarmee op straat, in volgorde van hoe duurzaam het probleem is.
De sleutels en zouten. Die roteren nooit vanzelf. Zijn ze eenmaal weg, dan blijven ze geldig tot iemand ze met de hand vervangt — en het vervangen ervan logt in één klap iedereen uit, wat precies de reden is dat het niet gebeurt.
De applicatiewachtwoorden. Die geven toegang tot de REST-API en XML-RPC zonder langs het inlogscherm te gaan, en dus ook zonder tweefactor. Vóór WordPress 6.8 stonden ze als portable hash opgeslagen; sindsdien niet meer.
De wachtwoordhashes. Hier zit een harde datumgrens. WordPress ging pas met versie 6.8, uitgebracht op 15 april 2025, over van de oude portable hashing naar bcrypt. Een archief van vóór die overstap bevat dus hashes uit het tijdperk waarin ze met moderne hardware realistisch te kraken zijn; een archief van erna niet. Bestaande hashes worden pas omgezet als de gebruiker weer inlogt, dus een slapend account houdt zijn oude hash ook op een bijgewerkte site.
De databasegegevens. Meestal onbruikbaar van buiten, omdat de databaseserver alleen op de machine zelf luistert. Meestal, niet altijd — dat is het controleren waard en niet het aannemen.
Eerst een verse back-up buiten de webmap. Dan controleren dat niets naar de oude map verwijst — niet in de pagina's, niet in de database, niet in de sitemap. Dan verwijderen en toetsen dat het pad een 404 geeft in plaats van een foutmelding. Pas dáárna de nasleep: sleutels en zouten vervangen, alle applicatiewachtwoorden intrekken, en de wachtwoorden van de accounts die er in stonden opnieuw zetten. Die laatste stap wordt het vaakst overgeslagen en is de enige die het lek echt sluit.
Schijfruimte is geen argument. Zo'n oude installatie is vaak het leeuwendeel van je verbruik, maar dat is bijvangst. Wat telt is uitsluitend dat de archieven van buitenaf opvraagbaar zijn.
Een onbekend pad is geen beveiliging. Geeft een verzonnen bestandsnaam in die map een gewone WordPress-foutpagina en geen «verboden», dan worden bestaande bestanden gewoon uitgeserveerd en beschermt alleen de willekeurige tekenreeks in de bestandsnaam ze. Die staat in de indexlijst van het archief.
upload_files bij de bijdrager en unfiltered_html bij de redacteur op een enkelvoudige installatie.Dit is een weegmodel om je eigen onderhoudsvolgorde mee te bepalen, geen beveiligingsaudit. Het oordeel is zo goed als de antwoorden die je invult, en het kent alleen de melding die je erin stopt — niet de rest van je stack, je hosting of je mailinstellingen. Bij een site met klant- of betaalgegevens erop ligt de lat hoger dan wat hier uitrolt.