Er WordPress sikkert – og er en kodet nettside sikrere?

Kjernen i WordPress har få sårbarheter – seks i løpet av 2025, alle med lav prioritet. En WordPress-nettside er likevel ikke sikker av seg selv. I 2025 lå 91 % av sårbarhetene i WordPress-økosystemet i plugins og 9 % i temaer, ifølge Patchstack. Om en nettside blir hacket, avgjøres derfor av hva som er installert rundt kjernen, og av om noen holder det oppdatert. Her går vi gjennom hva som faktisk blir hacket, hva dere kan gjøre med det, hva et innbrudd gjør med synligheten i Google, og om en kodet nettside er sikrere – med de risikoene den også har.

Er WordPress sikkert?

Kjernen er stort sett sikker, men det som installeres rundt den, er ikke automatisk det. Patchstack, State of WordPress Security in 2026 (oppdatert 25. februar 2026) registrerte 11 334 nye sårbarheter i WordPress-økosystemet i løpet av 2025. Det er 42 % flere enn året før. 91 % fantes i plugins og 9 % i temaer. I selve kjernen ble det funnet seks sårbarheter, alle med lav prioritet.

De alvorlige øker også. 1 966 sårbarheter, 17 %, hadde høy alvorlighetsgrad – flere enn i de to foregående årene til sammen.

Mest talende er at 46 % av sårbarhetene manglet en ferdig oppdatering da de ble offentliggjort. Å alltid oppdatere er nødvendig, men det beskytter ikke mot et hull som utvikleren ennå ikke har tettet. Da gjenstår to former for beskyttelse: å ikke ha pluginen installert, eller en brannmur som stopper angrepet før det når koden. Patchstack selger selv den typen beskyttelse, men andre sikkerhetsselskaper gir det samme rådet om brannmur.

WordPress-sikkerhet handler derfor om hvem som vedlikeholder det som kjører på serveren, og hvor mye som kjører der.

Hvorfor blir WordPress-nettsider hacket?

WordPress-nettsider blir først og fremst hacket gjennom plugins og temaer som ikke oppdateres i tide, og angriperne er raske. WordPress er også det største målet: plattformen driver 39,5 % av alle nettsteder og 58,3 % av nettstedene med et kjent CMS, ifølge W3Techs (oktober 2026). Et hull i en populær plugin kan derfor åpne tusenvis av nettsider på én gang.

De vanligste veiene inn:

• Sårbare plugins og temaer. Det er der nesten alle kjente hull sitter. På Patchstacks liste over de ti mest utnyttede sårbarhetene i 2025 lå alle ti i plugins, og sju kunne utnyttes uten innlogging (Patchstack).
• Utdaterte installasjoner. Oppdateringen finnes, men ingen har installert den.
• Svake innlogginger. Innloggingssiden er offentlig, passord gjenbrukes, og tofaktorautentisering mangler.
• Delt hosting uten beskyttelse. Uten brannmur og isolasjon mellom kundene kan et innbrudd hos en nabo spre seg.

Risikoen kan også ligge under WordPress. I oktober 2026 ble det funnet to alvorlige sikkerhetshull i PHP, språket WordPress kjører på (SVT). Ligger nettsiden hos et vanlig webhotell, er det webhotellet som oppdaterer PHP, og dermed webhotellet som avgjør når nettsiden er sikker igjen. Hva det betyr for valget av plattform, tar vi opp i Alternativ til WordPress 2026.

Tiden til å handle er kort. For de mest utnyttede sårbarhetene i 2025 var den vektede mediantiden fem timer fra hullet ble kjent til det første angrepet Patchstack observerte. Omtrent halvparten av sårbarhetene med høy påvirkning ble utnyttet innen et døgn. En nettside som oppdateres én gang i måneden, kan dermed ligge åpen i flere uker.

Sucuris rapport om hackede nettsteder viser det samme mønsteret fra den andre siden. I Sucuris data for 2023 (39 594 rensede nettsteder og drøyt 108 millioner fjernskanninger) var 95,5 % av de oppdagede infeksjonene WordPress. Sucuri påpeker selv at tallet ikke betyr at plattformen er mer eller mindre sikker enn andre – det speiler hvor utbredt WordPress er, og hvem som henvender seg til Sucuri. Mer nyttig er det at 39,1 % hadde et utdatert CMS da de ble infisert, og at 49,21 % hadde minst én bakdør (Sucuri, 2023 Hacked Website & Malware Threat Report). En bakdør som blir liggende igjen, er en vanlig måte for angriperen å komme inn igjen på, og derfor holder det ikke å fjerne bare det som er synlig.

Oppdaterer WordPress seg selv?

Kjernen gjør det delvis, plugins og temaer gjør det ikke som standard. Siden versjon 3.7 har WordPress installert mindre versjoner og sikkerhetsoppdateringer av kjernen automatisk (WordPress Developer Resources). Siden versjon 5.5 har det vært mulig å slå på automatiske oppdateringer per plugin og tema, men funksjonen er slått av til noen aktiverer den (Make WordPress Core).

Problemet er at de delene som står for nesten alle sårbarhetene, ikke oppdateres av seg selv. Har ingen slått på funksjonen – eller slått den av etter at en oppdatering ødela en side – blir hver plugin liggende på versjonen som ble installert.

Automatiske oppdateringer kan også skape problemer. En oppdatering kan endre hvordan en side ser ut, eller få et skjema til å slutte å fungere. Slå dem derfor på for plugins som vedlikeholdes godt, og sørg for at noen kontrollerer nettsiden etterpå. Større oppdateringer, som et nytt tema eller en ny versjon av et redigeringstillegg som Elementor, testes først i en kopi av nettsiden.

Holder det med en sikkerhetsplugin?

Nei. En sikkerhetsplugin som Wordfence er ett lag av flere – og dessuten én plugin til som må holdes oppdatert. Den kan blokkere kjente angrep og varsle om endrede filer, men den erstatter ikke vedlikeholdet. Det som gjør størst forskjell, er en kort liste:

1. Færre plugins. Hver plugin er kode fra en annen leverandør som kjører på serveren deres. Fjern dem som ikke brukes, fordi en deaktivert plugin fortsatt ligger på serveren.
2. Bytt ut plugins som ikke vedlikeholdes. Har en plugin ikke blitt oppdatert på lenge, eller blitt stengt i plugin-katalogen på WordPress.org, skal den erstattes.
3. Automatiske oppdateringer og kontroll etterpå. Se avsnittet over.
4. Tofaktorautentisering og egne kontoer. Hver person har en egen konto med bare de rettighetene som trengs.
5. Sikkerhetskopi (backup) utenfor serveren. En sikkerhetskopi på samme server kan forsvinne eller bli infisert ved det samme innbruddet. Test at gjenopprettingen faktisk fungerer.
6. Hosting med brannmur. En brannmur på servernivå stopper angrep før de når WordPress, også mot hull som ennå mangler oppdatering.

Det finnes lengre sjekklister, men de seks punktene dekker veiene inn som er beskrevet over. Grunnhygienen som gjelder alle nettsider uansett plattform – HTTPS, sikkerhetsheadere og security.txt – går vi gjennom i sjekklisten for nettside 2026.

Er en kodet nettside sikrere enn WordPress?

En statisk kodet nettside har betydelig mindre angrepsflate enn WordPress. En serverrendret nettside har en server som må beskyttes, og alle kodede nettsider har avhengigheter som må oppdateres. En kodet nettside kan bygges på tre måter, som delvis overlapper:

• Statisk (forhåndsrendret). Rammeverket, for eksempel Astro, bygger alle sidene til ferdige HTML-filer før de publiseres. Filene leveres fra et CDN. Det finnes ingen database og ingen innlogging på nettsiden.
• Serverrendret. Rammeverket, for eksempel Next.js med server, bygger siden når den besøkende ber om den. Kode kjører på en server eller i serverløse funksjoner ved hver forespørsel.
• Med headless CMS. Innholdet ligger i et headless CMS som Sanity – en hostet tjeneste med egen innlogging – og nettsiden henter det når den bygges, eller når siden vises. Frontenden kan være statisk eller serverrendret. Headless WordPress er en variant der WordPress er CMS-et.

Tabellen viser hvor arbeidet og risikoen havner i hver arkitektur. Graderingen av angrepsflaten er vår vurdering.

Jo mindre som kjører på serveren, desto mindre er det å oppdatere, og desto færre veier inn finnes. En statisk nettside har minst angrepsflate. En serverrendret nettside har en server og et rammeverk som må holdes oppdatert. Webflow legger vedlikeholdet av plattformen hos leverandøren. WordPress, og til en viss grad headless WordPress, legger det meste hos dere. Risikoen forsvinner ikke i noen av arkitekturene, men den havner på ulike steder.

Tre hendelser i 2025 viser at en kodet nettside ikke er sikker av seg selv:

• Next.js middleware (CVE-2025-29927). Et hull med CVSS-poengsum 9,1, offentliggjort 21. mars 2025, lot angripere omgå kontroller i Next.js middleware, for eksempel innloggingsbeskyttelse (GitHub Advisory Database). Statiske eksporter ble ikke berørt. Ifølge Vercel ble heller ikke prosjekter hos Vercel, Netlify eller Cloudflare Workers berørt (Vercels postmortem).
• React2Shell (CVE-2025-55182). En sårbarhet i React Server Components med høyest mulig CVSS-poengsum, 10,0, som tillot fjernkjøring av kode uten innlogging (React, 3. desember 2025). I Next.js ble den sporet som CVE-2025-66478 og gjaldt App Router i versjon 15 og 16 (Next.js).
• npm-angrepene i september. Den 8. september 2025 ble 18 populære pakker kapret, blant dem chalk og debug, med over to milliarder nedlastinger i uken til sammen. Den ondsinnede koden kjørte i de besøkendes nettlesere, var rettet mot kryptotransaksjoner og ble oppdaget i løpet av noen timer (Aikido). Senere i september spredte Shai-Hulud seg, et selvspredende angrep som ifølge CISA rammet over 500 pakker og stjal tilgangsnøkler til GitHub og skytjenester.

De to første rammet kode som kjører på serveren. npm-angrepene rammet byggekjeden og kunne nå også en statisk nettside, hvis en kapret pakke havnet i koden som sendes til den besøkende.

Hvordan en kodet nettside med headless CMS bygges i praksis, beskriver vi i AI-nettside med Claude Code og Next.js. Hele byttebeslutningen – hvor dere bør gå, hva det koster år 1 og år 3, og hvordan flyttingen gjøres – står i Alternativ til WordPress 2026, og Webflow mot WordPress i detalj i Webflow vs WordPress.

Kan en statisk nettside hackes?

Ja, men ikke på samme måte. Det finnes ingen database å injisere kode i, og ingen innloggingsside på nettsiden å gjette passord mot. Cloudflare, som selv tilbyr hosting for denne typen nettsider, skriver at fraværet av en kobling mellom nettside og database reduserer sårbarhetene (Cloudflare). Angrepene flytter seg i stedet til det som omgir nettsiden:

• Kontoer. Den som får tilgang til CMS-kontoen, kodelageret eller hostingkontoen, kan publisere hva som helst.
• Domene og DNS. Blir domenekontoen kapret, kan trafikken pekes om til en annen server.
• Skjemaer. Serverløse funksjoner eller tredjepartstjenester tar imot skjemaene, og de må validere inndata og beskyttes mot spam og misbruk.
• Tredjepartsskript. Chat, analyse og annonsetagger kjører i den besøkendes nettleser. Blir leverandøren kapret, rammes nettsiden deres også.
• Byggekjeden. Pakkene som brukes når nettsiden bygges, som i npm-eksemplene over.

Beskyttelsen ser derfor annerledes ut: tofaktorautentisering på alle kontoer, få personer med tilgang, låste versjoner av pakkene og en gjennomgang av hvilke skript som faktisk trengs.

Hva skjer med SEO hvis nettsiden blir hacket?

Et innbrudd kan bli et SEO-problem før det merkes som et IT-problem. Sucuri fant SEO-spam på 20,3 % av de infiserte nettstedene i 2023. Noen innbrudd er laget for å tjene penger på domenet deres i Google, ikke for å ødelegge nettsiden, så det er ikke sikkert dere merker noe når dere besøker den.

Et kjent mønster er at angriperen oppretter store mengder automatisk genererte sider under domenet deres, ofte på japansk, med affiliatelenker til butikker som selger forfalskede merkevarer. Sidene vises deretter i Googles søkeresultater. Noen varianter skjuler sidene for eieren, som får en falsk «siden ble ikke funnet» ved et direkte besøk (Google om det japanske søkeordhacket). Andre sender besøkende som kommer fra søkeresultatene, videre til et helt annet nettsted (Google om gibberish-hacket).

Dette kan skje i Google:

• Advarsel i søkeresultatet. Google kan merke treffet med «Dette nettstedet kan være hacket» (Google Søk-hjelpen), og nettleseren kan vise en helsidesadvarsel før den besøkende når nettsiden (Google Search Console-hjelpen). Advarselen kan være det første en potensiell kunde ser.
• Rapporten Sikkerhetsproblemer i Google Search Console. Den viser om Google har funnet hacket innhold, skadelig programvare og uønsket programvare eller sosial manipulering, med eksempler på berørte adresser (Google Search Console-hjelpen). Den er verdt å sjekke også når alt ser normalt ut.
• Dårligere plasseringer. Google skriver at en flagget nettside kan få dårligere plasseringer en periode (Google Search Console-hjelpen).

Hvor lenge det varer, avhenger av hvor lenge innbruddet pågikk, og hvor mye som rakk å bli indeksert. Derfor lønner det seg å oppdage innbrudd tidlig. Koble Google Search Console til nettsiden, la varslene gå til en innboks som noen leser, og gjør et site:-søk på domenet av og til for å se hva Google faktisk har indeksert.

WordPress-nettsiden er hacket – hva gjør vi?

Isoler nettsiden, gjenopprett fra en ren sikkerhetskopi, bytt alle passord, oppdater alt og be Google vurdere nettsiden på nytt. I den rekkefølgen:

1. Isoler. Sett nettsiden i vedlikeholdsmodus, eller be hostingselskapet stenge den midlertidig. Ta vare på logger og en kopi av den infiserte installasjonen – de viser hvordan angriperen kom inn.
2. Gjenopprett fra en ren sikkerhetskopi. Velg en sikkerhetskopi fra før innbruddet. Finnes det ingen, må filer og database renses, og da holder det ikke å fjerne det som er synlig. Ligger en bakdør igjen, kan angriperen komme tilbake.
3. Bytt alle passord. WordPress-kontoer, databasen, hostingkontoen, SFTP og e-postkontoer knyttet til nettsiden. Generer nye sikkerhetsnøkler i wp-config.php, fjern administratorkontoer dere ikke kjenner igjen, og slå på tofaktorautentisering. Sjekk også hvem som er eiere i Google Search Console – angripere legger noen ganger til seg selv der (Google).
4. Oppdater og rydd. Kjerne, plugins og tema til siste versjon. Fjern det som ikke brukes, og bytt ut pluginen som slapp angriperen inn, hvis den mangler en oppdatering.
5. Be Google om en gjennomgang. Kontroller at spamsidene ikke lenger finnes, og be deretter om en gjennomgang i rapporten Sikkerhetsproblemer. Ifølge Google tar gjennomgangen alt fra noen dager til flere uker, og å be om den før nettsiden er helt ren, forlenger bare tiden den er flagget (Google om gjennomgang).

Ligger nettsiden nede, eller er den hacket, hjelper vi akutt. Hvordan det foregår og hva det koster, står i Hjelp med nettsiden.

Når er WordPress likevel riktig valg?

WordPress er et fornuftig valg når noen eier vedlikeholdet, og nettsiden trenger det WordPress gjør best. Det gjelder ofte når:

• Dere har en rutine for oppdateringer. Noen oppdaterer hver uke, kontrollerer nettsiden etterpå og reagerer når et alvorlig hull blir publisert.
• Nettsiden har få og kjente plugins. Hver plugin har en grunn til å være der og en leverandør som vedlikeholder den.
• Dere er avhengige av funksjoner som mangler på andre plattformer. Medlemssystemer, kurs eller en WooCommerce-butikk med nisjeintegrasjoner.
• Dere har en egen WordPress-utvikler. Da er ansvaret allerede plassert.
• Nettsiden er innholdstung, og redaksjonen kan WordPress. Kostnaden ved å lære noe nytt kan være større enn gevinsten ved et bytte. Headless WordPress er en mellomløsning som beholder redaksjonsverktøyet, men flytter den offentlige frontenden bort fra WordPress-serveren.

Om WordPress er bra for dere, handler altså mer om vedlikehold enn om plattform. Stemmer punktene, er sikkerheten håndterbar. Stemmer de ikke, passer ofte en kodet nettside med headless CMS eller Webflow bedre, fordi det løpende vedlikeholdet blir mindre.

Hvordan hjelper SEOS Design dere med å sikre eller bytte?

Det finnes to veier, og hvilken som passer, avhenger av hvordan nettsiden er bygget, og hvem som skal eie den fremover.

Beholde og sikre. Vil dere beholde WordPress, begynner vi ofte med en gjennomgang av installasjonen: plugins, oppdateringsstatus, kontoer, sikkerhetskopier og hosting. Drift av en eksisterende WordPress-nettside passer best når den er godt bygget og har få plugins. Hva driften kan omfatte, står på siden om drift og vedlikehold.

Bytte. Vil dere minimere det løpende vedlikeholdet, er en kodet nettside med headless CMS eller Webflow ofte det riktige valget. Hvordan beslutningen tas, står i Alternativ til WordPress 2026, og hvordan vi bygger, beskriver vi under ny nettside til bedrifter og headless CMS-byrå. En kodet nettside krever ingen driftsavtale med oss. Har dere en egen utvikler, kan vedkommende ta over vedlikeholdet helt. Uten en egen utvikler er en mindre driftsavtale ofte lurt, fordi avhengighetene også må oppdateres.

Vi gir en anbefaling når vi har hørt mer om behovene deres. Ta kontakt med adressen til nettsiden og det som bekymrer dere.