53 prosent WordPress-nettsteder med upatchede CVE-er: GuardingWP 2026

#53 prosent av WordPress-nettsteder kjorer upatchede CVE-er: hva GuardingWP-revisjonen 2026 faktisk beviser

Mer enn halvparten. Den forste State of WordPress Security 2026-rapporten fra GuardingWP, hentet fra skanninger av 424 bekreftede WordPress-installasjoner i mer enn forti bransjer, sier at 53 prosent av nettstedene kjorer minst en plugin som barer en kjent upatchet CVE. Den samme rapporten setter 93,2 prosent uten moderne sikkerhetsheadere, 55,9 prosent som lekker WordPress-versjonen via generator-meta-taggen og 35,8 prosent som fortsatt serverer XML-RPC.

Tallene overrasker ikke. Et funn under tretti prosent ville vart overraskelsen, fordi strukturen i WordPress sin plugin-okonomi returnerer denne raten som standard. Denne artikkelen leser GuardingWP-dataene som bevis pa at kuren ikke er en bedre brannmur, men kontrollene for leverandorkjeden som allerede er skrevet inn i NIS2 artikkel 21 paragraf 2 bokstav d og DORA artikkel 28, og som Norge tilegner seg gjennom EOS-avtalen og kommende norsk gjennomforing under tilsyn av NSM.

Teksten star ved siden av pillarene vare om NIS2 og DORA pa WordPress: compliance-stacken 2026 og om WordPress plugin supply chain, og utfyller arbeidet om WCAG, BFSG og EAA, fordi innkjopsteam pakker tilgjengelighet, sikkerhet og motstandsdyktighet i ett leverandor-ark i dag.

#Det viktigste i ett avsnitt

• GuardingWP 2026 skannet 424 bekreftede WordPress-installasjoner i mer enn 40 bransjer. De fire hovedfunnene er observerbare fra ett enkelt HTTP-respons per side.
• 53 prosent av nettstedene med minst en upatchet plugin-CVE. 93,2 prosent uten moderne headere. 55,9 prosent med versjonslekkasje. 35,8 prosent med apen XML-RPC.
• Raten pa 53 prosent er ikke brukerslurv. Det er standardutfall av en plugin-okonomi med 20 til 40 tredjepartsutgivere per installasjon, ikke-koordinerte patch-sykluser og eieren som siste-instans-integrator.
• WordPress 7.0 la til AI-infrastruktur og dermed API-nokler i admin-hemmelighetsflaten. Patchstack-grunnlegger Oliver Sild varslet offentlig en “absolute rush by hackers to steal API keys”.
• NIS2 artikkel 21 paragraf 2 bokstav d og DORA artikkel 28 koder allerede kuren: dokumentert sarbarhetspolicy, patch-kadens, leverandorvurdering, register over IKT-tredjepartsavtaler.
• Spaken som flytter en WordPress-organisasjon fra compliance-feil til compliance-pass er ikke en plugin. Det er et kontrollrammeverk.

#Tallene, med kilde

De fire hovedindikatorene i GuardingWP-rapporten 2026 kan observeres utenfra nettstedet. En skanner trenger bare hjemmesideresponsen og HTTP-statusen pa /xmlrpc.php for a utlede hver av dem. Det er viktig, fordi compliance-revisorer i okende grad starter med ekstern evidens, og Patchstack-telemetri, GreyNoise og Internet Archive star som permanent maleinfrastruktur.

For EU-regulert leser ser baseline for disse fire tallene forskjellig ut. CSP og HSTS er nevnt i ENISAs beste praksiser for sikkerhet i internett-vendte systemer. XML-RPC-eksponering er eksplisitt ropt opp i OWASP Top 10. Upatchede plugin-CVE-er kobler direkte til NIS2 artikkel 21 om leverandorkjedekontroll. GuardingWP-rapporten er ikke en liste over kuriositeter. Det er en maling av fire allerede kodifiserte compliance-gap.

#Hvorfor 53 prosent er et strukturelt tall

En typisk WordPress-side kjorer mellom tjue og forti plugins. WordPress.org publiserer mer enn 60 000 plugins, med en lang hale av forfattere uten finansierte sikkerhetsteam. Patch-syklusen til plugin A og plugin B er ikke koordinert. Nettstedseieren er siste-instans-integrator. Nar CVE-2025-XYZW lander i plugin A pa en tirsdag, er nettstedseieren den eneste parten som kan avgjore om det skal patches, om det skal testes mot resten av stacken og om patchen odelegger plugin B.

Okonomien i situasjonen favoriserer ikke integratoren. A patche tjue plugins i maneden med regresjonstest er ingenior-arbeid. De fleste WordPress-sider er ikke budsjettert for det arbeidet. Derfor blir de fleste WordPress-sider ikke patchet. Raten pa 53 prosent er markedslikevekten.

Det er to veier ut av denne likevekten, og bare en av dem er holdbar.

Den forste veien er a krympe plugin-stacken. En WordPress-side med atte plugins, alle under aktivt vedlikehold, alle individuelt avgrenset til en funksjon eieren kan beskrive i en setning, er en handterbar patch-flate. Disiplinen koster mer i starten fordi teamet enten ma bygge funksjonen i custom-kode eller leve uten den, men den manedlige kostnaden ved a holde seg patchet faller proporsjonalt.

Den andre veien er a outsource patch-kadensen til en managed provider som faktisk gjor det. Det er det seriose managed-WordPress-hoster og seriose byraer faktisk leverer, der kontrakten uttrykkelig sier “vi anvender sikkerhetspatcher innen X timer etter vendor-release, forst pa staging, deretter produksjon”. Sier kontrakten ikke det, eksisterer ikke kadensen, og siden er statistisk i 53 prosent.

#Hva WordPress 7.0 endret

WordPress 7.0 “Armstrong” kom i samme publikasjonsuke som GuardingWP-rapporten. 7.0-utgivelsen la til AI Services Registry og Abilities API, som betyr at admin-flaten na lagrer API-nokler for hostede modellleverandorer (Anthropic, OpenAI), AI-gatewayer (Vercel) og selvhostede endepunkter. Disse noklene har en fakturerbar side. En kompromittert admin-tilgang er ikke lenger bare et problem med innholdsintegritet. Det er ogsa et kostnadslekkasje-problem.

Patchstack-grunnlegger Oliver Sild skrev offentlig pa X pa utgivelsesdagen: “there will be an absolute rush by hackers to steal API keys.”

Justin Nealey, som skriver pa bloggen sin, flagget det relaterte praktiske hodebryet: WP AI Client har ingen innebygd throttle, og flere plugins som deler en API-nokkel kan blase gjennom token-grensen pa under et minutt. Det er ikke en hypotetisk motstander, det er en velmenende feilkonfigurasjon. Begge former for kostnadslekkasje krever samme kontroll: scoping av nokler per kobling, rate-grenser pa gateway og ikke i pluginen, audit-logg som loftet uventet token-forbruk innen en faktureringssyklus.

Kontrollflaten er godt forstatt. Det er den samme flaten et finansteam ville anvendt pa enhver nyutgitt fakturerbar legitimasjon. WordPress er bare uvanlig fordi det historisk ikke har hatt denne kategorien legitimasjon i adminen.

#Hvordan NIS2 leser GuardingWP-dataene

NIS2-direktivet (2022/2555), artikkel 21, paragraf 2, lister ti tekniske og organisatoriske tiltak som vesentlige og viktige enheter ma anvende. Bokstav d, med direktivets egne ord, krever “sikkerhet i leverandorkjeden, herunder sikkerhetsrelaterte aspekter ved forholdet mellom hver enhet og dens direkte leverandorer eller tjenesteytere”. En WordPress-installasjon med upatchede plugin-CVE-er svikter bokstav d uavhengig av om den enkelte pluginen er kritisk, fordi enheten ikke har vurdert og styrt leverandorrisikoen.

Kuren under NIS2 er prosedural. Den omfatter:

• En dokumentert policy for handtering og offentliggjoring av sarbarheter som enheten faktisk folger. Paragraf 2 bokstav b.
• En patch- og oppdateringskadens med malsatt tid for a anvende CVE-vurderte fixer. Paragraf 2 bokstav f i kombinasjon med bokstav b.
• En leverandorvurdering som dekker plugin-forfatterne som selv er IKT-tredjepartsleverandorer, herunder deres sikkerhetsmodenhet, offentliggjoringskanal og patch-latens. Paragraf 2 bokstav d.
• Et register over IKT-tredjepartsavtaler, som under DORA ogsa har en eksplisitt artikkel 28-forpliktelse for finansforetak.

En WordPress-side kan besta den tekniske lesningen av NIS2 (det vil si ikke ha upatchede CVE-er pa revisjonsdagen) og fortsatt svikte pa den prosedurale lesningen hvis enheten ikke kan vise dokumentene. Raten pa 53 prosent antyder at dokumentene ikke eksisterer for halvparten av sidene i scope.

I Norge tilegner vi oss NIS2 gjennom EOS-avtalen og en norsk gjennomforing som tar form. Nasjonal sikkerhetsmyndighet (NSM) er fagmyndigheten for forebyggende nasjonal sikkerhet og driver NCSC med hendelseshandtering, mens NorSIS gir radgivning til norske virksomheter pa cybersikkerhet og Datatilsynet handhever GDPR-siden av samme datalekkasjer som NSM kan se. Et 53-prosent plugin-profil i en norsk virksomhet under kommende NIS2-omfang er ikke bare driftsrisiko, men et klart regulatorisk risiko i tilsynsoyemed.

Det er denne delen av samtalen de fleste sikkerhetsverktoy-leverandorer unngar. A selge en brannmur er enklere enn a selge et kontrollrammeverk. Kontrollrammeverket er det NIS2 faktisk krever.

#Hvordan DORA leser GuardingWP-dataene for finansforetak

DORA-forordningen (2022/2554) har vart direkte anvendelig siden 17. januar 2025. Den gjelder kredittinstitusjoner, betalingsinstitusjoner, forsikringsforetak, verdipapirforetak, tilbydere av kryptotjenester og om lag femten ytterligere kategorier listet i artikkel 2. For norske aktorer kommer DORA gjennom EOS-avtalen og Finanstilsynets handhevelse.

DORA artikkel 28 regulerer styring av IKT-tredjepartrisiko. Plugin-forfatterne til et finansforetaks offentlige nettsted faller inn under den definisjonen. To praktiske konsekvenser folger av GuardingWP-profilen.

For det forste ma enheten fore et register over kontraktsmessige ordninger med IKT-tredjepartsleverandorer (artikkel 28 paragraf 3). Dette registeret ma dekke plugin-utgivere hvis kode kjorer pa den offentlige siden. For de fleste finansforetak inneholder dette registeret WordPress-plugin-forfattere overhodet ikke for oyeblikket. Kuren er ikke teknisk, den er administrativ: hent ut den aktive plugin-listen, kartlegg hver plugin til utgiveren, fest utgiverens sarbarhetskanal og patch-latens og legg oppforingen inn i registeret.

For det andre krever artikkel 28 paragraf 5 at kontraktsmessige ordninger med IKT-tredjepartsleverandorer som leverer kritiske eller viktige funksjoner inkluderer “exitstrategier, sarlig fastsetting av en obligatorisk tilstrekkelig overgangsperiode”. For en WordPress-side som for en kritisk arbeidsflyt er avhengig av en enkelt spesialisert plugin (levering av signerte dokumenter, KYC-adapter, sammenstilling av regulatorisk rapport-PDF), ma exitstrategien finnes pa papir. Den finnes sjelden.

Dette er ikke glamorose kontroller. Det er papir. Det er ogsa hvordan en faktisk DORA-revisjon ser ut.

#Der GuardingWP-rapporten er for stille

Hovedtallene i rapporten er godt belagt, men rapporten undervurderer en ting praktikeren ma se klart: raten pa 53 prosent er konsentrert i den lange halen av smabedriftsinstallasjoner og er mye lavere i installasjoner med en managed provider pa kontrakt som uttrykkelig dekker sikkerhetspatching. Vi har ikke GuardingWPs underliggende segmentering, men var egen konsentrasjon av WordPress-sider under vedlikeholdskontrakt ligger ensifret for upatchet CVE-rate i enhver gitt revisjonsuke.

Implikasjonen er ikke at managed-WordPress-hoster og sikkerhetsfokuserte byraer er perfekte. Den er at likevektsraten pa 53 prosent er et markedsgjennomsnitt som blander to svart ulike populasjoner. En kjoper som leser rapporten bor ikke konkludere “WordPress er utrygt”. Han bor konkludere: “WordPress-sider uten kontrollrammeverk er utrygge, og storrelsen pa den uhandterte halen er halve markedet”.

#Hva endrer seg hvis WordPress 7.0 tas pa alvor

Utgivelsen av WordPress 7.0 med AI-infrastruktur er en nyttig tvingende funksjon for den uhandterte halen, fordi tillegget av API-nokler i admin-flaten gjor kostnadslekkasje-saken synlig pa en mate XSS eller eksfiltrering av lagrede legitimasjoner aldri var. En person i finans som ikke ble flyttet av “du kan ha en upatchet CVE” lar seg flytte av “AI-leverandorfakturaen din for forrige maned var tresifret hoyere enn vanlig og vi kan ikke gjore rede for trafikken”.

Kontrollflaten som lukker AI-nokkel-risikoen, lukker ogsa store deler av resten av GuardingWP-funnene, fordi kontrollene overlapper:

• Moderne sikkerhetsheadere (CSP, HSTS, X-Content-Type, Referrer-Policy) pa edge. En Cloudflare Worker eller en .htaccess-blokk. Lukker 93,2-prosent-gapet.
• Undertrykking av generator-meta-tag. Ett filter. Lukker 55,9-prosent-gapet.
• XML-RPC slatt av eller rate-begrenset pa edge. En brannmurregel eller en .htaccess-linje. Lukker 35,8-prosent-gapet.
• API-nokkel-scoping, rate-grense per kobling, anomali-varsel pa token-forbruk. Ny kontrollflate. Lukker 7.0-risikoen for den far skala.

Dette er ikke heroiske ingenioroppgaver. Det er linjeposter i et managed-services scope of work.

#En praktikers lesning

Jeg gjor sikkerhetsaudit av WordPress-sider under EU-jurisdiksjoner og har gjort det i femten ar. Ukens monster i 2026 er det samme som i 2018: en side ankommer med tjueatte plugins, eieren kan ikke liste hva atte av dem gjor, og regresjonstest-byrden ved a patche alt i en syklus overstiger budsjettet. GuardingWP-raten er en trofast beskrivelse av det monsteret. Kuren som faktisk virker pa ett-arshorisont er den ingen liker:

1. Revider plugin-listen. Fjern hver plugin hvis funksjon eieren ikke kan beskrive i en setning.
2. Erstatt de to eller tre pluginene som overlever, men har stagnerende vedlikeholdskanaler.
3. Etabler en dokumentert patch-kadens og en sarbarhetspolicy. Skriv det ned. Henvis til det ved navn i vedlikeholdskontrakten.
4. Legg til et register over IKT-tredjepartsavtaler som speiler den aktive plugin-listen og oppdateres ved hver plugin-add eller plugin-remove.
5. For WordPress 7.0-installasjoner: scop hver AI-leverandor-nokkel per kobling, anvend rate-grenser pa gateway og varsel pa anomalier i token-forbruk.

De fire forste punktene er compliance-arbeid under NIS2 artikkel 21. Det femte er den nye kontrollklassen som 7.0 introduserer. Ingen av de fem kjopes som produkt fra en leverandor. Slik moter en WordPress-praktiker pa jobb.

#Avsluttende argument

GuardingWP-rapporten 2026 er det mest nyttige enkeltdokumentet WordPress-sikkerhetsmiljoet har publisert pa fem ar, fordi den omformulerer en debatt som har sittet for lenge fast i verktoy-sammenligningsmodus. Den riktige lesningen er ikke “bytt til Patchstack” eller “installer Wordfence”. Den er: halve markedet driver ikke et kontrollrammeverk, kontrollene som lukker gapet er kodifisert i NIS2 og DORA, og kjoperen pa mottakerenden av EU-regulering i 2026 er den med spaken til a tvinge kontrollene inn i leverandorkontrakten.

For leseren fra et WordPress-byra er dette det sterkeste kommersielle oyeblikket pa flere ar for a selge rammeverket, ikke verktoyet. Tallet 53 prosent er ledelinjen i neste leverandor-pitch.

#Kilder

• GuardingWP, State of WordPress Security 2026 (rapportside)
• Direktiv (EU) 2022/2555 om sikkerhet i nettverks- og informasjonssystemer (NIS2), artikkel 21
• Forordning (EU) 2022/2554 om digital operasjonell motstandsdyktighet for finanssektoren (DORA), artikkel 28
• Patchstack
• ENISA: beste praksiser for sikkerhet i internett-vendte systemer
• Nasjonal sikkerhetsmyndighet (NSM)
• NorSIS
• Datatilsynet
• OWASP Top 10 2021

#Relaterte tekster hos oss

• Pillar: NIS2 og DORA pa WordPress: compliance-stacken 2026
• WordPress plugin supply chain 2026: fire bakdorer pa en maned
• WCAG 2.2, BFSG og EU Accessibility Act: compliance-stacken 2026 for WordPress
• WordPress sikkerhetsaudit
• DORA artikkel 28 IKT-tredjepartrisiko: WordPress-hosting og WAF-leverandoraudit

Sist oppdatert: 2026-05-23