De meeste WordPress- site-eigenaren slaan updates niet over omdat het ze niet interesseert. Ze slaan ze over omdat de site gewoon werkt, het team het druk heeft en de update-wachtrij al wekenlang ongebruikt in de wachtrij staat.
Die ogenschijnlijk stille wachtrij is bedrieglijk. Ze is niet neutraal. Elke week dat ze onbehandeld blijft, worden de kosten voor de afhandeling ervan hoger en wordt het steeds gevaarlijker om haar te negeren.
In dit artikel wordt uitgelegd waarom, aan de hand van cijfers uit het huidige dreigingslandschap, kostengegevens van reële herstelscenario's en een praktisch kader om te begrijpen waar uw site zich momenteel bevindt.
Het overslaan van WordPress-updates zorgt voor een achterstand in updates, wat na verloop van tijd de beveiligingsrisico's, compatibiliteitsproblemen en nalevingsproblemen vergroot. Elke gemiste update kan bekende kwetsbaarheden onopgelost laten en het veiliger maken om toekomstige updates toe te passen.
Naarmate de WordPress-kern, plugins, thema's en PHP-versies zich blijven ontwikkelen, wordt verouderde software moeilijker te onderhouden en is de kans groter dat deze na een update niet meer werkt.
Hoe langer updates worden uitgesteld, hoe meer tijd en middelen er nodig zijn om het probleem op te lossen, waardoor een simpele onderhoudstaak verandert in een kostbaar herstelproject.
Hoe snel worden verouderde WordPress-plugins misbruikt?
Om te begrijpen waarom de timing van updates belangrijk is, moet je eerst begrijpen hoe de moderne cyclus van het exploiteren van kwetsbaarheden werkt.
Wanneer een beveiligingsonderzoeker een kwetsbaarheid in een WordPress-plugin, volgt hij of zij doorgaans een verantwoorde openbaarmakingsprocedure: de pluginontwikkelaar wordt op de hoogte gesteld, er wordt gewacht tot er een patch beschikbaar is en de details van de kwetsbaarheid worden gepubliceerd nadat de patch is uitgebracht. Deze openbaarmaking bevat technische specificaties waarmee de beveiligingsgemeenschap het probleem kan begrijpen en zich ertegen kan beschermen.
Het geeft aanvallers ook precies wat ze nodig hebben om een exploit te ontwikkelen.
Hoe gebruiken aanvallers niet-gepatchte plugins?
Het beveiligingsrapport van Patchstack uit 2026 documenteerde dat de gemiddelde tijd tussen de openbaarmaking van een kwetsbaarheid en het begin van massale exploitatie vijf uur bedraagt. Geautomatiseerde scantools zoeken naar sites die de kwetsbare versie draaien en proberen deze te exploiteren zonder menselijke tussenkomst.
Dit betekent dat de periode waarin een patch beschikbaar is, maar uw site nog niet beveiligd is, de periode met het hoogste risico is. Een site die wekelijks onderhoud uitvoert, dicht die periode binnen enkele dagen. Een site die updates weken of maanden uitstelt, is kwetsbaar gedurende de hele periode tussen de publicatie en het moment dat iemand weer op de updateknop klikt.
In oktober 2025 werden bijna negen miljoen pogingen ondernomen om misbruik te maken van drie kwetsbaarheden in WordPress-plugins. De patches voor alle drie waren al een jaar beschikbaar. De aanvallers vonden geen nieuwe zwakke punten. Ze richtten zich op sites waar updates zo lang waren uitgesteld dat de kwetsbaarheid permanent open bleef staan.
Hoe snel groeit de achterstand?
De achterstand op het gebied van beveiliging groeit niet lineair, maar exponentieel.
| Uitstelperiode | Geschatte updates in afwachting | Bekende misbruikte kwetsbaarheden |
| 1 maand | 4 tot 8 | Sommige werden actief als doelwit gekozen |
| 3 maanden | 12 tot 24 | Veel mensen richtten zich actief op het doelwit |
| 6 maanden | 25 tot 50 | De meerderheid wordt massaal uitgebuit |
| 12 maanden | 50 tot 100+ | Allemaal zwaar doelwit van geautomatiseerde tools |
Wekelijks onderhoud betekent 52 patchcycli per jaar. Maandelijks onderhoud betekent 12. Het verschil is 40 minder beschermingsperioden gedurende een jaar. Dat verschil is direct meetbaar in de mate van blootstelling.
Automatische updates lossen slechts een deel van het probleem op
Automatische updates van de WordPress-kern geven veel website-eigenaren een vals gevoel van veiligheid. Kernupdates zijn belangrijk, maar ze pakken minder dan 10% van de daadwerkelijke bedreigingen aan. 91% van de WordPress-kwetsbaarheden in 2025 werd gevonden in plugins en thema's, niet in de kern zelf. Een website met ingeschakelde automatische updates, maar onbeheerde plugins, is beschermd tegen een klein deel van de gedocumenteerde bedreigingen, terwijl deze volledig blootgesteld blijft aan de overgrote meerderheid.
Is uw WordPress-site niet up-to-date?
Seahawk verzorgt wekelijkse WordPress-updates, beveiligingsmonitoring, back-ups en noodondersteuning voor honderden websites. Geen contracten. Geen abonnementskosten. Abonnementen vanaf $49 per maand.
De werkelijke kosten van uitgestelde WordPress-updates
De totale kosten van uitgestelde updates vallen onder drie categorieën die de meeste website-eigenaren afzonderlijk, of helemaal niet, evalueren. Inzicht in al deze categorieën samen maakt de afweging tussen onderhoud en herstel duidelijk.
Wat betaal je als er iets misgaat?
Directe kosten zijn de facturen van de ontwikkelaar die binnenkomen nadat er iets mis is gegaan.
Malwareverwijdering: $150-$500 per incident. Dit omvat het scannen van bestanden, het verwijderen van infecties en verificatie. Het omvat niet de tijd die wordt besteed aan het onderzoeken hoe de site is gecompromitteerd of het herstellen van eventuele schade die tijdens de aanval is ontstaan.
Noodhulp voor ontwikkelaars: $50-$200 per uur. Noodtarieven liggen hoger dan standaardtarieven omdat ze ander werk verdringen en vaak buiten kantooruren plaatsvinden.
Volledig herstel na een hack: $2.500 tot $7.500 voor een gemiddeld complexe website. Dit omvat het opschonen van de gegevens, het versterken van de beveiliging, het herstellen van back-ups en het testen na het incident. Websites met e-commerce- of ledenfunctionaliteit liggen doorgaans hoger.
Update-achterstand wegwerken: Voor een website die al 12 maanden geen updates heeft ontvangen, vereist het veilig wegwerken van de achterstand 30 tot 50 uur of meer aan professionele expertise. Met een tarief van $100 tot $200 per uur is dit een aanzienlijke investering voordat er ook maar één regel nieuwe code is geschreven.
De gemiddelde maandelijkse kosten voor professioneel onderhoud bij verschillende serviceproviders bedragen $246. De gemiddelde kosten voor een herstelincident liggen tussen de $2.500 en $7.500. Een enkel incident kost gemiddeld meer dan een jaar aan onderhoud.
De inkomsten die u misloopt tijdens downtime
Indirecte kosten zijn lastiger te factureren, maar in de praktijk vaak hoger.
Omzetverlies door downtime. Wanneer een WordPress-site uitvalt als gevolg van een beveiligingsincident of een mislukte update, worden alle transacties die in die periode zouden hebben plaatsgevonden, niet geregistreerd. Voor e-commercewebsitesis dit meetbaar. Voor dienstverlenende bedrijven betekent het gemiste leads en potentiële klanten.
Schade aan SEO door de malwarewaarschuwing van Google. Google markeert dagelijks ongeveer 10.000 websites als schadelijk of met malware gemarkeerd. Wanneer een site gemarkeerd is, zien bezoekers een waarschuwing in de browser voordat ze verder kunnen. De organische zoekresultaten dalen direct. Het aantal klikken stort in.
Het herstelproces na een malware-melding van Google omvat het volledig verwijderen van de infectie, het indienen van een verzoek tot handmatige controle via Google Search Console, wachten tot Google de site opnieuw crawlt en bevestigt dat deze schoon is, en vervolgens wachten tot de rankingposities zich herstellen. Alleen al de handmatige controle duurt weken. Het herstel van de rankings duurt maanden. Voor een bedrijf dat afhankelijk is van organische zoekresultaten voor leads of omzet, kan het verlies gedurende die periode gemakkelijk hoger uitvallen dan de directe kosten voor het herstel.
Vertrouwen van klanten en leden. Voor non-profitorganisaties, ledenverenigingen en dienstverlenende bedrijven heeft een gehackte website die leden- of klantgegevens blootlegt, reputatieschade die niet terug te vinden is op een herstelfactuur. Het herstellen van het vertrouwen van donateurs of leden na een beveiligingsincident is geen eenmalige kostenpost. Het zijn doorlopende kosten die jarenlang aanhouden.
Juridische boetes en afgewezen verzekeringsclaims
Deze categorie krijgt de minste aandacht en brengt het meest asymmetrische risico met zich mee.
AVG. De Algemene Verordening Gegevensbescherming ( ) vereist dat organisaties die gegevens van EU-ing ingezetenen verwerken, passende technische beveiligingsmaatregelen treffen. Het gebruik van software met bekende, te verhelpen kwetsbaarheden is een aantoonbaar bewijs van het niet voldoen aan deze norm. Boetes kunnen oplopen tot 20 miljoen euro of 4% van de jaarlijkse wereldwijde omzet. Elke WordPress-website met een contactformulier, e-mailaanmeldingsmogelijkheid of gebruikersaccountfunctie die Europese bezoekers bedient, valt onder de AVG.
CCPA. De Californische wet op de bescherming van de privacy van consumenten (California Consumer Privacy Act) staat boetes toe tot $ 7.500 per opzettelijke overtreding. Toezichthouders hebben de bevoegdheid om bewust uitgestelde beveiligingsupdates te classificeren als opzettelijke nalatigheid. Organisaties met gebruikers of klanten in Californië vallen onder de reikwijdte van de wet.
Afwijzing van cyberverzekeringsclaims. Het afwijzingspercentage van claims in de cyberverzekeringssector ligt boven de 40%. Een van de meest voorkomende redenen voor afwijzing zijn verliezen die worden toegeschreven aan bekende, maar niet verholpen beveiligingslekken. Verzekeraars controleren de patchgeschiedenis als standaard onderdeel van het claimonderzoek. Een inbreuk waarbij gebruik wordt gemaakt van een beveiligingslek waarvoor zes maanden geleden een openbare patch beschikbaar is gekomen, wordt door de meeste standaard cyberverzekeringen niet gedekt.
Organisaties die updates uitstellen om maandelijkse onderhoudskosten te vermijden, terwijl ze wel een cyberverzekering hebben, kunnen in feite zelf verzekerd zijn tegen de uitkomst waartegen ze zich juist proberen te beschermen.
Waarom werken verouderde WordPress-plugins niet meer na een update?
Beveiliging is de belangrijkste reden om updates te blijven uitvoeren, maar het is niet de enige.
Eén versie achter versus zes maanden achterstand
Een enkele updatecyclus brengt weinig risico met zich mee. Een plugin gaat van versie 4.2 naar 4.3; de wijzigingen zijn stapsgewijs en alles blijft gewoon werken. De WordPress-core brengt gedurende het jaar kleine updates uit, die elk voortbouwen op de vorige. Wanneer een site up-to-date blijft, is elke update een kleine stap voorwaarts, samen met het hele ecosysteem.
Een achterstand in uitgestelde updates zorgt voor een andere situatie. De WordPress-kern is één of twee grote versies verder ontwikkeld. De PHP-compatibiliteitsvereisten zijn veranderd. Andere plugins hebben hun API's bijgewerkt. De plugin die niet is bijgewerkt, werkt nu in een omgeving die aanzienlijk verschilt van de omgeving waarvoor deze is ontwikkeld.
Hoe groter het verschil, hoe groter de kans dat de update een conflict veroorzaakt. En omdat er meerdere updates tegelijkertijd in behandeling zijn, is een conflict niet gemakkelijk te isoleren. Je kunt niet vaststellen welke update in een reeks van dertig het probleem heeft veroorzaakt.
Waarom lopen winkels en lidmaatschapwebsites extra risico?
Websites die WooCommerce, ledenadministratiesystemen of andere data-intensieve plugins gebruiken, worden geconfronteerd met een extra laag complexiteit.
Deze plugins bevatten vaak databasemigraties als onderdeel van grote versie-updates. Wanneer een WooCommerce-update wordt uitgevoerd, kan de databasetabelstructuur worden gewijzigd om nieuwe functies te ondersteunen. Wanneer een membership-plugin meerdere grote versies tegelijk bijwerkt, kunnen er meerdere opeenvolgende migraties worden uitgevoerd.
Databasemigraties kunnen niet ongedaan worden gemaakt door bestanden terug te draaien. Als een bulkupdate deze migraties uitvoert en er iets misgaat, is het herstellen van de site naar de staat van vóór de update alleen mogelijk door een back-up terug te zetten, en niet door simpelweg bestanden terug te draaien. Alle transacties, formulierinzendingen of gebruikersactiviteit die tussen de back-up en het herstel hebben plaatsgevonden, gaan verloren.
Dit is precies het mechanisme dat een uitgestelde update-taak omzet in een gegevensverlies.
Hoe controleer je of je website een compatibiliteitsprobleem heeft?
Voordat je updates toepast op een site met een aanzienlijke achterstand, controleer dan twee dingen. Ten eerste, controleer of de PHP-versie die je hostingomgeving gebruikt, voldoet aan de PHP-vereisten van je belangrijkste plugins. Veel plugins die twee jaar geleden nog actueel waren, vereisen PHP 7.4 of ouder, terwijl de huidige WordPress-versie PHP 8.2 aanbeveelt. Ten tweede, controleer of er plugins in je stack zijn verwijderd uit de WordPress-repository. Alleen al eind 2025 werden meer dan 150 plugins verwijderd vanwege onopgeloste beveiligingsproblemen of inactiviteit van de ontwikkelaars. Het is niet mogelijk om een verwijderde plugin bij te werken. Vervangen is de enige optie.
Waarom is het gevaarlijk om op 'Alles bijwerken' te klikken op een verwaarloosde website?
De instinctieve reactie op een groeiende updatewachtrij is om alles in één keer te verwerken. Dit is een van de meest voorkomende oorzaken van noodsituaties op WordPress-websites.
Waarom maakt klikken op 'Alles bijwerken' de situatie erger?
Wanneer updates zich gedurende weken of maanden hebben opgestapeld, leidt het gelijktijdig uitvoeren ervan tot verschillende problemen:
Geen isolatie. Wanneer een bulkupdate iets kapotmaakt, is het niet mogelijk om te bepalen welke update in de batch het probleem heeft veroorzaakt. Terugdraaien vereist het terugdraaien van alles, niet alleen de problematische update.
Cascaderende incompatibiliteiten. Twintig plug-ins die tegelijkertijd worden bijgewerkt, kunnen afzonderlijk veilig zijn, maar sommige combinaties leiden tot conflicten die niet zouden optreden als de updates stapsgewijs zouden worden toegepast. Hoe meer updates er in één batch worden uitgevoerd, hoe meer potentiële combinaties voor onverwachte interacties er zijn.
Databasemigraties worden sequentieel uitgevoerd zonder te testen. Plug-ins die de databasestructuur tijdens updates wijzigen, voeren die wijzigingen automatisch uit. Bij een bulkupdate kunnen meerdere plug-ins migraties achter elkaar uitvoeren, waarbij elke plug-in uitgaat van een specifieke databasestatus die de vorige migratie mogelijk niet correct heeft gereproduceerd.
Er is geen gefaseerd herstelpad. Als een terugdraaiing van bestanden nodig is, wordt de site hersteld naar de staat van vóór de updates in de batch. Het is nog steeds nodig om te achterhalen welke update het probleem heeft veroorzaakt, maar dit moet nu gebeuren op een herstelde site die opnieuw verouderd is.
Hoe kunt u veilig doorwerken tijdens updates die nog in behandeling zijn?
De juiste aanpak voor een opgebouwde updateachterstand is incrementeel, gefaseerd en met een geverifieerd herstelpunt bij elke stap.
Voor een website die een paar weken achterloopt, is het raadzaam om de updates één voor één door te voeren. Begin met beveiligingspatches voor plugins met een laag risico, ga vervolgens verder met complexere plugins en bewaar plugins die veel met de database te maken hebben (WooCommerce, ledenadministratiesystemen) voor het laatst. Controleer na elke update of alles naar behoren werkt voordat u verdergaat.
Voor een site die drie tot zes maanden achterloopt, repliceer je de productieomgeving in de stagingomgeving, voer je updates stapsgewijs door in de stagingomgeving, controleer je de functionaliteit bij elke stap en implementeer je de implementatie in productie pas na een succesvolle stagingtest.
Voor een website die zes maanden of langer achterloopt, is dit een professionele klus. De compatibiliteitsproblemen, mogelijk verouderde plug-ins en de complexiteit van de database vereisen deskundige aanpak. Een poging hiertoe zonder testomgeving, een methodische aanpak en ondersteuning van ontwikkelaars vergroot de kans op precies het probleem dat de update juist moet voorkomen.
Hoe weet je zeker dat je back-up ook echt werkt?
Een back-up die nooit is getest, is een aanname, geen vangnet. Controleer voordat u updates toepast op een site met een aanzienlijke achterstand of uw meest recente back-up succesvol kan worden hersteld naar een testomgeving of lokale omgeving.
Controleer of de database probleemloos kan worden hersteld, of de website zonder fouten laadt en of uw belangrijkste functionaliteiten (afrekenen, inloggen, formulieren) correct werken vanuit de herstelde staat. Een back-up die u niet kunt herstellen, is geen back-up. Het geeft een vals gevoel van veiligheid.
Wat te doen als uw WordPress-updates al achterlopen?
Niet elke situatie met uitgestelde updates vereist dezelfde reactie. Hier volgt een eerlijke beoordeling op basis van de omvang van de achterstand.
Een paar weken achterstand. Voer updates één voor één uit. Begin met de plugins met het minste risico. Maak een back-up voor elke update. Vermijd het updaten van WooCommerce- of membership-plugins zonder eerst te testen in een testomgeving. Met de nodige zorgvuldigheid kunt u dit zelf doen.
Eén tot drie maanden achterstand. Het compatibiliteitsverschil is aanzienlijk. Sommige van uw openstaande updates bevatten waarschijnlijk beveiligingslekken die actief worden misbruikt. Overweeg een testomgeving te gebruiken voordat u updates in de productieomgeving toepast. Als uw site WooCommerce, terugkerende betalingen of lidmaatschapsfunctionaliteit bevat, is professionele hulp het overwegen waard.
Drie tot zes maanden achterstand. Het risico dat een simpele update problemen veroorzaakt, is reëel. De achterstand bevat waarschijnlijk kwetsbaarheden waar geautomatiseerde tools actief naar scannen. Probeer dit niet zonder een gefaseerde uitrol. Schakel een professional in als u zich niet vertrouwd voelt met incrementele, gefaseerde updates.
Zes tot twaalf maanden achterstand. Dit is een herstelproject. Budgetteer voor professionele tijd. Budgetteer voor de mogelijkheid dat sommige plugins vervangen moeten worden in plaats van bijgewerkt. Budgetteer voor compatibiliteitstests van al je plugins.
Meer dan twaalf maanden achterstand. De PHP-versievereisten zijn vrijwel zeker veranderd. De WordPress-core heeft minstens één grote versie-update ondergaan. Sommige plugins in je huidige stack zijn mogelijk niet meer beschikbaar of verwijderd uit de repository. Dit vereist professionele hulp, een testomgeving, een compatibiliteitsaudit en een plan voordat er ook maar één update wordt toegepast.
Tot slot nog een paar tips om je WordPress-website up-to-date te houden
Uitgesteld onderhoud levert geen kostenbesparing op. Het zijn uitgestelde kosten waarover rente wordt berekend.
De organisaties die de beste ervaring met WordPress hebben, zijn de organisaties die updates nooit laten ophopen. Wekelijks onderhoud betekent kleine, omkeerbare wijzigingen. Het betekent dat het exploitatievenster van 5 uur binnen enkele dagen sluit. Het betekent dat een compatibiliteitsprobleem nooit de kans krijgt om groter te worden.
De kostenvergelijking behoeft niet veel analyse. Een paar honderd dollar per maand aan onderhoud voorkomt een paar duizend dollar aan herstelkosten, plus de inkomsten die verloren gaan tijdens de downtime, plus de maanden die nodig zijn om de ranking te herstellen na een malware-waarschuwing van Google, plus de wettelijke risico's die gelden voor elke website die gebruikersgegevens verwerkt.
Als uw website momenteel achterloopt, was vorige maand het juiste moment om dit aan te pakken. Het op één na beste moment is nu, voordat de achterstand verder oploopt en voordat iets op het slechtst mogelijke moment tot problemen leidt.
Seahawk verzorgt het WordPress-onderhoud voor honderden websites. Het patroon is consistent: de websites die dringend onderhoud nodig hebben, zijn de websites die updates hebben uitgesteld. De websites die probleemloos draaien, zijn de websites die dat niet hebben gedaan.
Veelgestelde vragen over uitgestelde WordPress-updates
Wat gebeurt er als je de WordPress-plugins niet bijwerkt?
Ongeüpdatete WordPress-plugins verzamelen bekende beveiligingslekken waar aanvallers actief naar zoeken en die ze misbruiken. Alleen al in 2025 werden er 11.334 nieuwe kwetsbaarheden in het WordPress-plugin-ecosysteem ontdekt. Elke uitgestelde beveiligingspatch verlengt de periode waarin uw site blootgesteld is aan een gedocumenteerde, exploiteerbare zwakte. Naast de beveiligingsrisico's raken verouderde plugins steeds vaker uit synchronisatie met de WordPress-kern en PHP, waardoor de compatibiliteitskloof groter wordt en toekomstige updates riskanter.
Wat zijn de kosten om een verwaarloosde WordPress-website te herstellen?
De kosten voor herstel hangen af van de duur van de verwaarlozing en de aard van de schade. Een beveiligingsincident op een website met zes maanden aan uitgestelde updates kost doorgaans tussen de $ 2.500 en $ 7.500 aan professionele hersteltijd. Websites die langer dan een jaar geen updates hebben gehad, vereisen vaak 30 tot 50 uur of meer aan professionele hulp voor een veilig herstel. Dit omvat het opzetten van een testomgeving, incrementele updates, compatibiliteitsaudits en functionele tests. Deze bedragen zijn exclusief gederfde inkomsten tijdens de downtime of de kosten voor SEO-herstel na een malwarewaarschuwing van Google.
Waarom is het gevaarlijk om op 'Alles bijwerken' te klikken in WordPress?
Het gelijktijdig uitvoeren van alle openstaande updates op een site met een opgebouwde achterstand voorkomt dat u kunt achterhalen welke update een probleem heeft veroorzaakt als er iets misgaat. Plugins die de databasestructuur wijzigen, voeren deze migraties automatisch en onomkeerbaar uit. Meerdere plugins die tegelijkertijd updaten, kunnen incompatibiliteiten veroorzaken die geen enkele update op zich zou hebben veroorzaakt. Voor sites met WooCommerce, ledensystemen of andere database-intensieve plugins kan een bulkupdate die databasemigraties activeert en vervolgens de site laat crashen, een volledige back-upherstel vereisen in plaats van een eenvoudige terugdraaiing van bestanden.
Welke gevolgen heeft uitgesteld WordPress-onderhoud voor SEO?
Het grootste SEO-risico van achterstallig onderhoud is een malware-waarschuwing van Google. Wanneer een WordPress-site wordt gecompromitteerd via een niet-gepatchte kwetsbaarheid, detecteert Google de infectie vaak en markeert de site als schadelijk. Dit activeert waarschuwingen op browserniveau die voorkomen dat bezoekers de site kunnen bereiken, leidt tot een onmiddellijke daling van de organische zoekresultaten en vereist een handmatige beoordeling door Google voordat de waarschuwing wordt verwijderd. Het herstel van de ranking na een malware-waarschuwing duurt doorgaans maanden. Google markeert ongeveer 10.000 websites per dag, en de meeste van deze infecties zijn afkomstig van niet-gepatchte kwetsbaarheden in plugins.
Dekt een cyberverzekering beveiligingslekken in WordPress als gevolg van onopgeloste kwetsbaarheden?
Niet altijd. Het afwijzingspercentage van cyberverzekeringsclaims ligt boven de 40%, en een van de meest voorkomende redenen voor afwijzing is schade veroorzaakt door bekende, maar niet-gepatchte beveiligingslekken. Verzekeraars onderzoeken de patchgeschiedenis als onderdeel van de standaard claimbeoordeling. Een inbreuk die gebruikmaakt van een beveiligingslek waarvoor weken of maanden vóór het incident een publiekelijk beschikbare patch bestond, wordt vaak uitgesloten van dekking. Organisaties die verouderde WordPress-installaties gebruiken met een actieve cyberverzekering, zijn mogelijk niet verzekerd voor de gevolgen waar ze het meest risico op lopen.
Wat is de juiste manier om een achterstand in WordPress-updates weg te werken?
De veiligste aanpak is stapsgewijs en gefaseerd. Voer updates één voor één uit in plaats van allemaal tegelijk. Begin met beveiligingspatches voor plugins met een laag risico. Bewaar plugins die veel databases gebruiken, zoals WooCommerce en ledenadministratiesystemen, voor het laatst. Maak een geverifieerde back-up vóór elke update. Voor updates die drie maanden of ouder zijn, repliceer je je productiesite in een testomgeving, werk je de updates stapsgewijs uit in de testomgeving, controleer je de functionaliteit bij elke stap en implementeer je de site pas in productie na een volledige, schone testrun.
Hoe vaak moet WordPress worden bijgewerkt?
Beveiligingspatches moeten binnen 24 tot 48 uur na release worden toegepast, aangezien de gemiddelde tijd tussen de openbaarmaking van een kwetsbaarheid en de massale exploitatie ervan vijf uur bedraagt. Functie-updates en upgrades naar een hogere versie moeten in een testomgeving worden getest voordat ze in productie worden genomen en wekelijks worden uitgerold als onderdeel van een routineonderhoudsschema. Geen enkele plugin op een bedrijfskritieke website mag langer dan zeven dagen ongepatcht blijven nadat een beveiligingsupdate is uitgebracht.
