Wat je doet op de dag dat een kwetsbaarheid in een WordPress-plugin wordt gepubliceerd

Er wordt bijna elke dag een nieuwe kwetsbaarheid in een WordPress-plugin gepubliceerd. De meeste vragen niets meer dan de volgende gewone update. Een paar vragen vandaag actie: de lekken die actief worden misbruikt, die geen login nodig hebben, of die in een plugin zitten die je op tientallen klantsites draait. Deze gids is een vaste werkwijze voor die dag: hoe je snel beslist of een lek voor jou telt, hoe je elke getroffen site vindt en wat je na de update doet.

Stap 1: beslis in vijf minuten of het dringend is

Lees de melding zelf (Patchstack, Wordfence of WPScan), niet alleen de kop. Vier vragen bepalen hoe snel je handelt:

• Wordt het misbruikt? Een melding die zegt dat er aanvallen in het wild worden gezien, gaat bovenaan je dag.
• Is er een login nodig? Een lek dat een anonieme bezoeker kan gebruiken, is veel gevaarlijker dan een lek waarvoor een beheerdersaccount nodig is.
• Wat kan een aanvaller doen? Bestanden uploaden, code uitvoeren of beheerdersaccounts aanmaken is erger dan een reflected XSS waarvoor een klik nodig is.
• Op hoeveel van je sites draait het? Eén site is een taak; veertig sites is een project met een deadline.

Is het antwoord op de eerste twee vragen ja, behandel het dan als dringend: getroffen sites vandaag, niet bij de volgende onderhoudsronde.

Stap 2: vind elke getroffen site

Je hebt per site twee feiten nodig: is de plugin geïnstalleerd (actief of niet), en welke versie draait er. Inactieve plugins tellen mee. De kwetsbare code staat nog steeds op de server en is vaak nog rechtstreeks bereikbaar.

Met WP-CLI kost dit seconden per site:

wp plugin list --name=ninja-forms --fields=name,status,version

Zonder WP-CLI kijk je bij Plugins in wp-admin, of naar de versie in de readme.txt van de plugin. Zet het resultaat in één lijst: site, geïnstalleerd ja of nee, versie, versie met de oplossing. Die lijst is je checklist voor de rest van de dag en daarna je bewijs voor de klant.

Stap 3: update de getroffen sites, de meest kwetsbare eerst

Begin met de sites die het zwaarst getroffen worden als het misgaat: webshops, sites met veel formulieren of gebruikersaccounts, en sites met veel verkeer. Zorg voor elke update dat er een recente back-up is die je echt kunt terugzetten.

Beveiligingsupdates zijn meestal klein, maar niet altijd. Sommige makers leveren de oplossing in een grotere release met andere wijzigingen. Is de versie met de oplossing een grote sprong, of verwerkt de plugin formulieren of de checkout, test hem dan eerst op een kopie van de site als dat kan, en controleer daarna de belangrijkste pagina’s.

Kun je vandaag niet updaten, bijvoorbeeld omdat de oplossing nog niet uit is of de update iets breekt, verklein dan het risico: zet de plugin uit als de site een dag zonder kan, of blokkeer het kwetsbare endpoint in je firewall als de melding het noemt. Vertel de klant wat je deed en waarom.

Stap 4: test wat de plugin doet

Een geslaagde update is niet hetzelfde als een site die werkt. Test na de update waar de plugin voor is. Bij een formulierplugin stuur je een echte testinzending en controleer je of de e-mail aankomt. Bij een winkelplugin doe je een testbestelling tot aan de betaling. Een formulier dat stilletjes stopt met verzenden, kan een klant een week aan leads kosten voordat iemand het merkt.

Stap 5: controleer of de site al geraakt is

Updaten dicht het gat. Het verwijdert niets wat een aanvaller voor de update heeft achtergelaten. Werd het lek misbruikt voordat je patchte, controleer dan elke getroffen site op:

• beheerdersaccounts die je niet herkent;
• PHP-bestanden in de uploadsmap, die alleen media hoort te bevatten;
• recent gewijzigde bestanden in plugins en thema’s die je niet hebt geüpdatet;
• onbekende geplande taken, of doorverwijzingen die je niet hebt ingesteld.

Vind je tekenen van een inbraak, zet dan een back-up terug van vóór de aanvalsperiode, update meteen en wijzig alle wachtwoorden en de beveiligingssleutels in wp-config.php. Alleen patchen is niet genoeg.

Stap 6: informeer de klant, kort

Klanten lezen zelden beveiligingsnieuws, maar ze merken wel dat hun bureau erbovenop zat. Een kort bericht is genoeg: wat het probleem was, of hun site wel of niet getroffen was, wat je deed en wanneer. Zo wordt onzichtbaar werk zichtbare waarde, en het hoort ook in je volgende onderhoudsrapport.

Maak de volgende keer sneller

• Houd een lijst bij van welke plugins op welke sites draaien, zodat stap 2 minuten kost.
• Volg één of twee bronnen voor meldingen, geen tien.
• Zorg dat elke site een back-up heeft die je echt een keer hebt teruggezet.
• Spreek vooraf met klanten af dat dringende beveiligingsupdates buiten het normale schema gebeuren.

Hoe Verploy met kwetsbaarheden in plugins omgaat

Verploy toont bekende kwetsbaarheden in de plugins en thema’s van elke gekoppelde site, zodat je meteen ziet welke sites getroffen zijn. Elke update wordt gecontroleerd, en de risicovolle worden eerst op een kopie getest, inclusief de formulieren en de checkout. Nachtelijke back-ups komen met een hersteltest, en als een site na livegang breekt, draait Verploy hem terug. Meer over WordPress-kwetsbaarheden monitoren.