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

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

Mer enn halvparten. Den første State of WordPress Security 2026-rapporten fra GuardingWP, hentet fra skanninger av 424 bekreftede WordPress-installasjoner i mer enn førti bransjer, sier at 53 prosent av nettstedene kjører minst en plugin som bærer 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 vært overraskelsen, fordi strukturen i WordPress sin plugin-økonomi returnerer denne raten som standard. Denne artikkelen leser GuardingWP-dataene som bevis på at kuren ikke er en bedre brannmur, men kontrollene for leverandørkjeden som allerede er skrevet inn i NIS2 artikkel 21 paragraf 2 bokstav d og DORA artikkel 28, og som Norge tilegner seg gjennom EØS-avtalen og kommende norsk gjennomføring under tilsyn av NSM.

Teksten står ved siden av pillarene våre om NIS2 og DORA på WordPress: compliance-stacken 2026 og om WordPress plugin supply chain, og utfyller arbeidet om WCAG, BFSG og EAA, fordi innkjøpsteam pakker tilgjengelighet, sikkerhet og motstandsdyktighet i ett leverandør-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 åpen XML-RPC.
• Raten på 53 prosent er ikke brukerslurv. Det er standardutfall av en plugin-økonomi 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-nøkler 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 sårbarhetspolicy, patch-kadens, leverandørvurdering, 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 på /xmlrpc.php for å utlede hver av dem. Det er viktig, fordi compliance-revisorer i økende grad starter med ekstern evidens, og Patchstack-telemetri, GreyNoise og Internet Archive står som permanent måleinfrastruktur.

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 leverandørkjedekontroll. GuardingWP-rapporten er ikke en liste over kuriositeter. Det er en måling av fire allerede kodifiserte compliance-gap.

#Hvorfor 53 prosent er et strukturelt tall

En typisk WordPress-side kjører mellom tjue og førti 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. Når CVE-2025-XYZW lander i plugin A på en tirsdag, er nettstedseieren den eneste parten som kan avgjøre om det skal patches, om det skal testes mot resten av stacken og om patchen ødelegger plugin B.

Økonomien i situasjonen favoriserer ikke integratoren. Å patche tjue plugins i måneden med regresjonstest er ingeniør-arbeid. De fleste WordPress-sider er ikke budsjettert for det arbeidet. Derfor blir de fleste WordPress-sider ikke patchet. Raten på 53 prosent er markedslikevekten.

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

Den første veien er å krympe plugin-stacken. En WordPress-side med åtte plugins, alle under aktivt vedlikehold, alle individuelt avgrenset til en funksjon eieren kan beskrive i en setning, er en håndterbar patch-flate. Disiplinen koster mer i starten fordi teamet enten må bygge funksjonen i custom-kode eller leve uten den, men den månedlige kostnaden ved å holde seg patchet faller proporsjonalt.

Den andre veien er å outsource patch-kadensen til en managed provider som faktisk gjør det. Det er det seriøse managed-WordPress-hoster og seriøse byråer faktisk leverer, der kontrakten uttrykkelig sier “vi anvender sikkerhetspatcher innen X timer etter vendor-release, først på 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 nå lagrer API-nøkler for hostede modellleverandører (Anthropic, OpenAI), AI-gatewayer (Vercel) og selvhostede endepunkter. Disse nøklene har en fakturerbar side. En kompromittert admin-tilgang er ikke lenger bare et problem med innholdsintegritet. Det er også et kostnadslekkasje-problem.

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

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

Kontrollflaten er godt forstått. Det er den samme flaten et finansteam ville anvendt på 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 må anvende. Bokstav d, med direktivets egne ord, krever “sikkerhet i leverandørkjeden, herunder sikkerhetsrelaterte aspekter ved forholdet mellom hver enhet og dens direkte leverandører 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 leverandørrisikoen.

Kuren under NIS2 er prosedural. Den omfatter:

• En dokumentert policy for håndtering og offentliggjøring av sårbarheter som enheten faktisk følger. Paragraf 2 bokstav b.
• En patch- og oppdateringskadens med målsatt tid for å anvende CVE-vurderte fixer. Paragraf 2 bokstav f i kombinasjon med bokstav b.
• En leverandørvurdering som dekker plugin-forfatterne som selv er IKT-tredjepartsleverandører, herunder deres sikkerhetsmodenhet, offentliggjøringskanal og patch-latens. Paragraf 2 bokstav d.
• Et register over IKT-tredjepartsavtaler, som under DORA også har en eksplisitt artikkel 28-forpliktelse for finansforetak.

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

I Norge tilegner vi oss NIS2 gjennom EØS-avtalen og en norsk gjennomføring som tar form. Nasjonal sikkerhetsmyndighet (NSM) er fagmyndigheten for forebyggende nasjonal sikkerhet og driver NCSC med hendelseshåndtering, mens NorSIS gir rådgivning til norske virksomheter på cybersikkerhet og Datatilsynet håndhever 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 tilsynsøyemed.

Det er denne delen av samtalen de fleste sikkerhetsverktøy-leverandører unngår. Å selge en brannmur er enklere enn å selge et kontrollrammeverk. Kontrollrammeverket er det NIS2 faktisk krever.

#Hvordan DORA leser GuardingWP-dataene for finansforetak

DORA-forordningen (2022/2554) har vært 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 aktører kommer DORA gjennom EØS-avtalen og Finanstilsynets håndhevelse.

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

For det første må enheten føre et register over kontraktsmessige ordninger med IKT-tredjepartsleverandører (artikkel 28 paragraf 3). Dette registeret må dekke plugin-utgivere hvis kode kjører på den offentlige siden. For de fleste finansforetak inneholder dette registeret WordPress-plugin-forfattere overhodet ikke for øyeblikket. Kuren er ikke teknisk, den er administrativ: hent ut den aktive plugin-listen, kartlegg hver plugin til utgiveren, fest utgiverens sårbarhetskanal og patch-latens og legg oppføringen inn i registeret.

For det andre krever artikkel 28 paragraf 5 at kontraktsmessige ordninger med IKT-tredjepartsleverandører som leverer kritiske eller viktige funksjoner inkluderer “exitstrategier, særlig 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), må exitstrategien finnes på papir. Den finnes sjelden.

Dette er ikke glamorøse kontroller. Det er papir. Det er også 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 må se klart: raten på 53 prosent er konsentrert i den lange halen av småbedriftsinstallasjoner og er mye lavere i installasjoner med en managed provider på kontrakt som uttrykkelig dekker sikkerhetspatching. Vi har ikke GuardingWPs underliggende segmentering, men vår 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 byråer er perfekte. Den er at likevektsraten på 53 prosent er et markedsgjennomsnitt som blander to svært ulike populasjoner. En kjøper som leser rapporten bør ikke konkludere “WordPress er utrygt”. Han bør konkludere: “WordPress-sider uten kontrollrammeverk er utrygge, og størrelsen på den uhåndterte halen er halve markedet”.

#Hva endrer seg hvis WordPress 7.0 tas på alvor

Utgivelsen av WordPress 7.0 med AI-infrastruktur er en nyttig tvingende funksjon for den uhåndterte halen, fordi tillegget av API-nøkler i admin-flaten gjør kostnadslekkasje-saken synlig på en måte 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-leverandørfakturaen din for forrige måned var tresifret høyere enn vanlig og vi kan ikke gjøre rede for trafikken”.

Kontrollflaten som lukker AI-nøkkel-risikoen, lukker også store deler av resten av GuardingWP-funnene, fordi kontrollene overlapper:

• Moderne sikkerhetsheadere (CSP, HSTS, X-Content-Type, Referrer-Policy) på 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 slått av eller rate-begrenset på edge. En brannmurregel eller en .htaccess-linje. Lukker 35,8-prosent-gapet.
• API-nøkkel-scoping, rate-grense per kobling, anomali-varsel på token-forbruk. Ny kontrollflate. Lukker 7.0-risikoen før den får skala.

Dette er ikke heroiske ingeniøroppgaver. Det er linjeposter i et managed-services scope of work.

#En praktikers lesning

Jeg gjør sikkerhetsaudit av WordPress-sider under EU-jurisdiksjoner og har gjort det i femten år. Ukens mønster i 2026 er det samme som i 2018: en side ankommer med tjueåtte plugins, eieren kan ikke liste hva åtte av dem gjør, og regresjonstest-byrden ved å patche alt i en syklus overstiger budsjettet. GuardingWP-raten er en trofast beskrivelse av det mønsteret. Kuren som faktisk virker på ett-årshorisont 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 sårbarhetspolicy. 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-leverandør-nøkkel per kobling, anvend rate-grenser på gateway og varsel på anomalier i token-forbruk.

De fire første punktene er compliance-arbeid under NIS2 artikkel 21. Det femte er den nye kontrollklassen som 7.0 introduserer. Ingen av de fem kjøpes som produkt fra en leverandør. Slik møter en WordPress-praktiker på jobb.

#Avsluttende argument

GuardingWP-rapporten 2026 er det mest nyttige enkeltdokumentet WordPress-sikkerhetsmiljøet har publisert på fem år, fordi den omformulerer en debatt som har sittet for lenge fast i verktøy-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 kjøperen på mottakerenden av EU-regulering i 2026 er den med spaken til å tvinge kontrollene inn i leverandørkontrakten.

For leseren fra et WordPress-byrå er dette det sterkeste kommersielle øyeblikket på flere år for å selge rammeverket, ikke verktøyet. Tallet 53 prosent er ledelinjen i neste leverandør-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