WordPress-plugins bijwerken: wat er gebeurt als je het niet doet
De updatemelding in je dashboard is geen verzoek om netjes op te ruimen. Waarom een beveiligingsupdate het lek pas openbaar maakt, welke plugin echt gevaarlijk is en wat er op 11 september verandert.
In bijna elk WordPress-dashboard staat een klein getal naast Plugins. Het stoort niemand. Je klikt het weg omdat er net iets anders belangrijker is, en bij de volgende keer inloggen is het getal groter. Het opvallende eraan: er gebeurt niets. De pagina laadt, het contactformulier verstuurt, de webshop incasseert. Precies daar zit het probleem. De kosten van niets doen zijn onzichtbaar tot ze dat niet meer zijn, en dan komen ze in één klap.
Dit artikel legt uit wat er tussen de updatemelding en het incident werkelijk gebeurt, vanuit het perspectief van de mensen die die updates schrijven. Wij bouwen zelf WordPress-plugins, we publiceren de updates waar het hier over gaat, en we zien wat er daarna gebeurt.
Waarom een updatemelding geen verzoek om orde is
1. Een beveiligingsupdate maakt het lek pas openbaar
Dit is het punt dat bijna niemand kent, en het draait de intuïtie om. Zolang een beveiligingslek onontdekt in een plugin sluimert, weet niemand ervan. Op het moment dat de ontwikkelaar het dicht en de nieuwe versie publiceert, ontstaat er iets nieuws: een openbare vergelijking tussen ervoor en erna. WordPress-plugins staan onder de GPL, hun broncode is open, en elke versie blijft in de directory opvraagbaar. Twee versies naast elkaar leggen en zien welke regel is veranderd, is routinewerk.
Het publiceren van een beveiligingsupdate is daarmee tegelijk een routebeschrijving naar het lek in de oude versie. Dat is geen argument tegen updates, het is het sterkste argument voor snel bijwerken. De gevaarlijkste periode in het leven van een lek begint niet als het ontstaat, maar als het gedicht wordt. Wie drie weken later bijwerkt, heeft drie weken lang een gedocumenteerde zwakke plek in bedrijf gehad.
2. Niemand valt je aan, iets scant je
Het meest gehoorde tegenargument is dat een site veel te klein is om interessant te zijn. Dat gaat ervan uit dat er aan de andere kant een mens zit die kiest. Die zit er niet. Wat er draait zijn automatische scans die adreslijsten afwerken en naar vingerafdrukken zoeken: paden die alleen bij één bepaalde plugin bestaan, versievermeldingen in openbaar leesbare bestanden, antwoorden die een bepaalde versie verraden.
Voor dat proces maakt het niet uit of je site tien of tienduizend bezoekers heeft. Interessant is niet je bereik, maar de server, de postbus voor spamverzending en de ruimte voor doorverwijzingen. Een kleine site is daarom geen slechter doelwit, alleen een minder opvallend doelwit. Dat is trouwens de reden dat inbraken vaak maandenlang onopgemerkt blijven.
3. Een plugin is meer dan de code die de ontwikkelaar schreef
Bijna elke grotere plugin brengt vreemde bibliotheken mee: voor het maken van PDF, beeldbewerking, betaalkoppelingen, grafieken. Die staan in de pluginmap en worden meegeleverd. Wordt in zo'n bibliotheek een lek bekend, dan hangt het alleen van de pluginaanbieder af of de bijgewerkte versie bij jou aankomt. Je ziet deze afhankelijkheden niet in je dashboard, en je kunt ze ook niet zelf bijwerken.
Vanuit ontwikkelaarsperspectief is dat een flink deel van ons updatewerk, en het blijft van buitenaf volledig onzichtbaar. Een release waarvan de changelog alleen bijgewerkte afhankelijkheden noemt, lijkt niets en kan toch de belangrijkste van het kwartaal zijn.
4. De gevaarlijkste plugin is de verlaten plugin
Een plugin die al twee jaar geen update heeft gekregen, is niet ongevaarlijk omdat er niets gebeurt. Hij is gevaarlijk omdat er niets meer zal gebeuren. Wordt daar een lek gevonden, dan komt er geen update meer, en in de regel hoor je het niet.
Hoe wijdverbreid dat is, zagen we bij eigen onderzoek. Voor ons marktoverzicht hebben we vergelijkingsartikelen doorgenomen en de aanbevolen plugins bij de bron nagekeken. In een recent artikel met twintig aanbevelingen waren vijf daarvan gesloten in de WordPress-directory. Het artikel beveelt ze nog steeds aan, en wie ze heeft geïnstalleerd ziet in zijn pluginlijst precies hetzelfde als daarvoor: een naam, een versienummer, geen waarschuwing. Een gesloten plugin verdwijnt niet van je site, hij houdt alleen op met updates leveren.
Hoe dat er bij ons uitziet
Wij staan aan de andere kant van dit proces, dus hier het weinig glamoureuze deel.
Er moet een adres zijn waar iemand naartoe kan schrijven. Wie een lek vindt, moet dat kunnen melden zonder via een contactformulier te gaan dat bij de verkoop belandt. Daarvoor houden we een eigen beveiligingsadres aan. Het is geen groot werk, maar het is het verschil tussen een melding die aankomt en een melding die op een dag openbaar wordt omdat niemand antwoordde.
We publiceren liever klein en vaak dan groot en zelden. Een voorbeeld van deze week: op 17 augustus verscheen onze versie 2.3.0 en op 18 augustus de 2.3.1, omdat de toestemmingsbanner opnieuw werd getoond aan bezoekers die al hadden beslist. Geen beveiligingslek, wel een ergernis. Toch gaat zoiets meteen de deur uit en wacht het niet op het volgende grote pakket. De reden is praktisch: een release die één ding verandert, kun je nakijken. Bij een release die acht dingen verandert, kan niemand meer herleiden welke ene wijziging de opmaak sloopte.
En het deel dat aanbieders niet graag opschrijven: updates gaan soms mis. Dat is geen theorie, dat is onze dagelijkse praktijk net zo goed als die van jou. Wie beweert dat zijn updates risicoloos zijn, heeft weinig gebruikers of een kort geheugen. Het juiste antwoord daarop is niet minder vaak bijwerken, maar de losse update klein en terugdraaibaar houden. Staat er na een update een wit scherm op je site, dan is dat vervelend en in tien minuten verholpen. Een inbraak niet.
De uitspraak never touch a running system komt uit een wereld waarin het systeem in een kamer stond en de deur op slot zat. Jouw WordPress-installatie staat op internet. De omgeving verandert dagelijks, ook als jij niets aanraakt: PHP-versies, browsers, de WordPress-kern, en het gereedschap van de mensen die naar oude versies zoeken. Een systeem dat niet beweegt, wordt in die omgeving niet stabieler, alleen ouder.
Wat de Cyber Resilience Act op 11 september verandert
De Cyber Resilience Act is een EU-verordening voor producten met digitale elementen, en software hoort daarbij. Vanaf 11 september 2026 gelden de meldplichten: actief misbruikte kwetsbaarheden en ernstige beveiligingsincidenten moeten worden gemeld. De rest van de verplichtingen volgt gefaseerd.
Voor fabrikanten komt het in de kern neer op drie dingen die eerder vrijwillig waren: kwetsbaarheden geordend afhandelen, gedurende een genoemde periode beveiligingsupdates leveren, en daarvoor een bereikbaar contactpunt hebben. Wie ooit heeft geprobeerd de ontwikkelaar te bereiken van een plugin die sinds 2021 niet is bijgewerkt, snapt meteen welk probleem hier wordt aangepakt.
Twee kanttekeningen horen er eerlijk bij. Ten eerste is de vraag wie bij vrije opensourcesoftware als fabrikant in de zin van de verordening geldt precies het punt dat nog omstreden is. Wij beschrijven het hier, we beslissen het niet voor jou. Dit artikel is een duiding en geen juridisch advies, en voor je eigen situatie is er geen weg omheen: laat het vakkundig toetsen. Ten tweede: de CRA werkt je website niet bij. Hij verandert wat je van een aanbieder mag verwachten, niet wie de update installeert. Dat blijft jouw taak, en beheer je websites voor klanten, dan wordt het een contractuele.
Praktisch betekent dat voor de keuze: een plugin die noch een beveiligingsadres noch een ondersteuningsperiode noemt, is niet automatisch slecht. Maar het zegt je iets over hoeveel structuur erachter zit, en die informatie krijg je voortaan zonder ernaar te vragen.
In de praktijk: bijwerken zonder je site te slopen
Een back-up die je al eens hebt teruggezet. Een back-up die nog nooit is teruggezet, is geen beveiliging maar een hoop. Probeer het één keer, dan weet je hoe lang het duurt en of het überhaupt werkt. Welk gereedschap daarvoor deugt, staat in het artikel over back-upplugins voor WordPress.
Automatische updates voor beveiligingsreleases, handmatig voor de rest. WordPress kan plugins zelfstandig bijwerken. Voor kleine correctieversies is dat de juiste instelling, omdat de tijd tussen publiceren en installeren daar het zwaarst weegt. Bij grote versiesprongen die nieuwe functies brengen, loont de handmatige blik.
Dertig seconden in de changelog. Staat er security fix, dan is de zaak dringend en niet onderhandelbaar. Staat er een nieuwe functie die je niet nodig hebt, dan kan het tot het weekend wachten.
Een testomgeving zodra de site geld verdient. Bij een blog volstaat een back-up. Bij een webshop of een ledengedeelte wil je de update ergens anders hebben gezien voordat klanten hem zien.
Twee keer per jaar de balans opmaken. Elke plugin die je niet meer nodig hebt, is aanvalsoppervlak zonder tegenwaarde. Deactiveren is niet genoeg, want de bestanden blijven op de server staan. Verwijderen.
Waaraan je een plugin herkent die je laat zitten
| Signaal | Waar je het ziet | Wat het betekent |
|---|---|---|
| Laatste update meer dan een jaar geleden | Pluginpagina in de directory | Onderhoud gestopt of sterk vertraagd |
| Getest tot twee kernversies achter | Directorypagina, pluginlijst | De aanbieder test niet meer tegen actuele kernen |
| Onbeantwoorde supportonderwerpen | Supportforum op wordpress.org | Er leest niemand meer mee |
| Directorypagina niet meer bereikbaar | wordpress.org, plugin gesloten | Er komen geen updates meer aan en de plugin draait bij jou gewoon door |
| Geen beveiligingsadres te vinden | Website van de aanbieder, security.txt | Een melding bereikt de ontwikkelaar waarschijnlijk niet |
| Changelog noemt alleen diverse foutoplossingen | Changelog | Je kunt de urgentie niet inschatten |
Plugins die nog onderhouden worden als je ze nodig hebt
We bouwen onze plugins in Duitsland, publiceren kleine correctieversies meteen in plaats van gebundeld en houden een eigen adres aan voor beveiligingsmeldingen. Elke Free-versie blijft gratis, en de betaalde varianten staan op de prijzenpagina.
Veelgestelde vragen
Moet ik echt elke plugin-update meteen installeren?
Bij beveiligingsupdates ja, en wel om een concrete reden: met het publiceren van de correctie wordt het lek in de oude versie navolgbaar, omdat beide versies te vergelijken zijn. Bij functie-updates mag je de tijd nemen, een blik in de changelog volstaat om het in te schatten. De vuistregel is dat alles wat als security fix wordt omschreven direct doorgaat en de rest rustig kan wachten.
Wat doe ik als een update mijn site sloopt?
Zet de back-up terug of hernoem de map van de betreffende plugin via FTP, dan schakelt WordPress hem bij de volgende aanroep zelf uit. Meld het probleem daarna bij de aanbieder, want als het jou treft, treft het anderen ook. Daarom is de volgorde belangrijk: eerst de back-up controleren, dan bijwerken, nooit andersom.
Waaraan zie ik dat een plugin is verlaten?
Op de directorypagina staan de datum van de laatste update, de geteste WordPress-versie en het supportforum. Een jaar zonder update, onbeantwoorde onderwerpen en een verouderde vermelding bij getest tot zijn samen een duidelijk signaal. Het hardste geval is een directorypagina die helemaal niet meer bereikbaar is: dan is de plugin gesloten, komen er geen updates meer aan, en draait hij op je website gewoon door.
Raakt de Cyber Resilience Act mij als websitebeheerder?
De verplichtingen uit de verordening richten zich tot fabrikanten, importeurs en distributeurs van producten met digitale elementen, niet tot jou als gebruiker van een plugin. Praktisch verandert voor jou vooral de keuze: een beveiligingscontact en een genoemde ondersteuningsperiode worden een verwachting richting een aanbieder. Wie in opdracht van klanten websites beheert, doet er goed aan de eigen rol vakkundig te laten vaststellen. Dit artikel is geen juridisch advies.
Zijn automatische updates gevaarlijk?
Ze zijn een ruil. Je geeft controle over het moment op en wint snelheid precies daar waar snelheid telt. Voor correctieversies is dat bijna altijd de betere deal, omdat het de risicovolle periode na een publicatie kort houdt. Voor grote versiesprongen op een site die geld verdient, is de handmatige route met testomgeving verstandiger.
