Är WordPress säkert – och är en kodad hemsida säkrare?

Kärnan i WordPress har få sårbarheter – sex under 2025, alla med låg prioritet. En WordPress-hemsida är ändå inte säker av sig själv. Under 2025 satt 91 % av sårbarheterna i WordPress-ekosystemet i plugins och 9 % i teman, enligt Patchstack. Om en hemsida blir hackad avgörs därför av vad som har installerats runt kärnan och av om någon håller det uppdaterat. Här går vi igenom vad som faktiskt hackas, vad ni kan göra åt det, vad ett intrång gör med synligheten i Google och om en kodad hemsida är säkrare – med de risker den också har.

Är WordPress säkert?

Kärnan är i stort sett säker, men det som installeras runt den är det inte automatiskt. Patchstack, State of WordPress Security in 2026 (uppdaterad 25 februari 2026) registrerade 11 334 nya sårbarheter i WordPress-ekosystemet under 2025. Det är 42 % fler än året innan. 91 % fanns i plugins och 9 % i teman. I själva kärnan hittades sex sårbarheter, samtliga med låg prioritet.

De allvarliga ökar också. 1 966 sårbarheter, 17 %, hade hög allvarlighetsgrad – fler än under de två föregående åren sammantaget.

Mest talande är att 46 % av sårbarheterna saknade en färdig uppdatering när de offentliggjordes. Att alltid uppdatera är nödvändigt, men det skyddar inte mot en lucka som utvecklaren ännu inte har täppt till. Då återstår två skydd: att inte ha pluginet installerat, eller en brandvägg som stoppar attacken innan den når koden. Patchstack säljer själva den sortens skydd, men samma råd om brandvägg ger även andra säkerhetsbolag.

Avgörande är vem som underhåller det som körs på servern, och hur mycket som körs där.

Varför blir WordPress-hemsidor hackade?

WordPress-hemsidor hackas framför allt genom plugins och teman som inte uppdateras i tid, och angriparna är snabba. WordPress är också det största målet: plattformen driver 39,5 % av alla webbplatser och 58,3 % av webbplatserna med ett känt CMS, enligt W3Techs (oktober 2026). En lucka i ett populärt plugin kan därför öppna tusentals hemsidor på en gång.

De vanligaste vägarna in:

• Sårbara plugins och teman. Där sitter nästan alla kända luckor. I Patchstacks lista över de tio mest utnyttjade sårbarheterna under 2025 satt alla tio i plugins, och sju gick att utnyttja utan inloggning (Patchstack).
• Inaktuella installationer. Uppdateringen finns, men ingen har installerat den.
• Svaga inloggningar. Inloggningssidan är publik, lösenord återanvänds och tvåfaktorsautentisering saknas.
• Delad hosting utan skydd. Utan brandvägg och isolering mellan kunderna kan ett intrång hos en granne spridas.

Risken kan också sitta under WordPress. I oktober 2026 hittades två allvarliga säkerhetshål i PHP, språket som WordPress körs på (SVT). Ligger hemsidan hos ett vanligt webbhotell är det webbhotellet som uppdaterar PHP, och därmed webbhotellet som avgör när hemsidan är säker igen. Vad det betyder för valet av plattform tar vi upp i Alternativ till WordPress 2026.

Tiden att agera är kort. För de mest utnyttjade sårbarheterna 2025 var den viktade mediantiden fem timmar från att luckan blev känd till första attacken som Patchstack observerade. Ungefär hälften av sårbarheterna med hög påverkan utnyttjades inom ett dygn. En hemsida som uppdateras en gång i månaden kan därmed ligga öppen i veckor.

Sucuris rapport om hackade webbplatser visar samma mönster från andra hållet. I Sucuris data för 2023 (39 594 rensade webbplatser och drygt 108 miljoner fjärrskanningar) var 95,5 % av de upptäckta infektionerna WordPress. Sucuri påpekar själva att siffran inte betyder att plattformen är mer eller mindre säker än andra – den speglar hur utbredd WordPress är och vilka som anlitar dem. Mer användbart är att 39,1 % hade ett inaktuellt CMS när de infekterades, och att 49,21 % hade minst en bakdörr (Sucuri, 2023 Hacked Website & Malware Threat Report). En kvarlämnad bakdörr är ett vanligt sätt för angriparen att ta sig in igen, och därför räcker det inte att bara ta bort det som syns.

Uppdaterar WordPress sig själv?

Kärnan gör det delvis, plugins och teman inte som standard. Sedan version 3.7 installerar WordPress mindre versioner och säkerhetsuppdateringar av kärnan automatiskt (WordPress Developer Resources). Sedan version 5.5 går det att slå på automatiska uppdateringar per plugin och tema, men funktionen är avstängd tills någon aktiverar den (Make WordPress Core).

Problemet är att de delar som står för nästan alla sårbarheter inte uppdateras av sig själva. Har ingen slagit på funktionen – eller slagit av den efter att en uppdatering förstörde en sida – ligger varje plugin kvar på den version som installerades.

Automatiska uppdateringar kan också ställa till det. En uppdatering kan ändra hur en sida ser ut eller få ett formulär att sluta fungera. Slå därför på dem för plugins som underhålls väl, och se till att någon kontrollerar hemsidan efteråt. Större uppdateringar, som ett nytt tema eller en ny version av ett redigeringstillägg som Elementor, testas först i en kopia av hemsidan.

Räcker ett säkerhetsplugin?

Nej. Ett säkerhetsplugin som Wordfence är ett lager av flera – och dessutom ett plugin till att hålla uppdaterat. Det kan blockera kända attacker och larma om ändrade filer, men det ersätter inte underhållet. Det som gör störst skillnad är en kort lista:

1. Färre plugins. Varje plugin är kod från en annan leverantör som körs på er server. Ta bort de som inte används, eftersom ett inaktiverat plugin fortfarande ligger kvar på servern.
2. Byt ut plugins som inte underhålls. Har ett plugin inte uppdaterats på länge, eller stängts i pluginkatalogen på WordPress.org, ska det ersättas.
3. Automatiska uppdateringar och kontroll efteråt. Se avsnittet ovan.
4. Tvåfaktorsautentisering och egna konton. Varje person har ett eget konto med bara de rättigheter som behövs.
5. Backup utanför servern. En backup på samma server kan försvinna eller infekteras vid samma intrång. Testa att återställningen faktiskt fungerar.
6. Hosting med brandvägg. En brandvägg på servernivå stoppar attacker innan de når WordPress, även mot luckor som ännu saknar uppdatering.

Längre checklistor finns, men de sex punkterna täcker vägarna in som beskrivs ovan. Grundhygienen som gäller alla hemsidor oavsett plattform – HTTPS, säkerhetsheaders och security.txt – går vi igenom i checklistan för hemsida 2026.

Är en kodad hemsida säkrare än WordPress?

En statisk kodad hemsida har betydligt mindre attackyta än WordPress. En serverrenderad har en server att skydda, och alla kodade hemsidor har beroenden som måste uppdateras. En kodad hemsida kan byggas på tre sätt, som delvis överlappar:

• Statisk (förrenderad). Ramverket, till exempel Astro, bygger alla sidor till färdiga HTML-filer innan de publiceras. Filerna levereras från ett CDN. Det finns ingen databas och ingen inloggning på hemsidan.
• Serverrenderad. Ramverket, till exempel Next.js med server, bygger sidan när besökaren ber om den. Kod körs på en server eller i serverlösa funktioner vid varje anrop.
• Med headless CMS. Innehållet ligger i ett headless CMS som Sanity – en hostad tjänst med egen inloggning – och hemsidan hämtar det när den byggs eller när sidan visas. Framsidan kan vara statisk eller serverrenderad. Headless WordPress är en variant där WordPress är CMS:et.

Tabellen visar var arbetet och risken hamnar i respektive arkitektur. Graderingen av attackytan är vår bedömning.

Ju mindre som körs på servern, desto mindre finns att uppdatera och desto färre vägar in. En statisk hemsida har minst yta. En serverrenderad hemsida har en server och ett ramverk att hålla uppdaterade. Webflow lägger plattformens underhåll hos leverantören. WordPress, och i viss mån headless WordPress, lägger det mesta hos er. Risken försvinner inte i någon av arkitekturerna, men den hamnar på olika ställen.

Tre händelser under 2025 visar att en kodad hemsida inte är säker av sig själv:

• Next.js middleware (CVE-2025-29927). En lucka med CVSS-poäng 9,1, offentliggjord 21 mars 2025, lät angripare gå förbi kontroller i Next.js middleware, till exempel inloggningsskydd (GitHub Advisory Database). Statiska exporter påverkades inte. Enligt Vercel påverkades inte heller projekt hos Vercel, Netlify eller Cloudflare Workers (Vercels postmortem).
• React2Shell (CVE-2025-55182). En sårbarhet i React Server Components med högsta möjliga CVSS-poäng, 10,0, som tillät fjärrkörning av kod utan inloggning (React, 3 december 2025). I Next.js spårades den som CVE-2025-66478 och gällde App Router i version 15 och 16 (Next.js).
• npm-attackerna i september. Den 8 september 2025 kapades 18 populära paket, bland dem chalk och debug, med över två miljarder nedladdningar i veckan sammanlagt. Skadekoden kördes i besökarnas webbläsare, riktade sig mot kryptotransaktioner och upptäcktes inom några timmar (Aikido). Senare i september spreds Shai-Hulud, en självspridande attack som enligt CISA drabbade över 500 paket och stal åtkomstnycklar till GitHub och molntjänster.

De två första drabbade kod som körs på servern. npm-attackerna drabbade byggkedjan och kunde nå även en statisk hemsida, om ett kapat paket hamnade i koden som skickas till besökaren.

Hur en kodad hemsida med headless CMS byggs i praktiken beskriver vi i AI-assisterad webbutveckling med headless CMS. Hela bytesbeslutet – vart, vad det kostar år 1 och år 3 och hur flytten görs – står i Alternativ till WordPress 2026, och Webflow mot WordPress i detalj i Webflow vs WordPress.

Kan en statisk hemsida hackas?

Ja, men inte på samma sätt. Det finns ingen databas att injicera kod i och ingen inloggningssida på hemsidan att gissa lösenord mot. Cloudflare, som själva erbjuder hosting för den här typen av hemsidor, skriver att avsaknaden av koppling mellan hemsida och databas minskar sårbarheterna (Cloudflare). Angreppen flyttar i stället till det som omger hemsidan:

• Konton. Den som kommer åt CMS-kontot, kodförrådet eller hostingkontot kan publicera vad som helst.
• Domän och DNS. Kapas domänkontot kan trafiken pekas om till en annan server.
• Formulär. Serverlösa funktioner eller tredjepartstjänster tar emot formulären, och de behöver validera indata och skyddas mot spam och missbruk.
• Tredjepartsskript. Chatt, analys och annonstaggar körs i besökarens webbläsare. Kapas leverantören drabbas er hemsida också.
• Byggkedjan. Paketen som används när hemsidan byggs, som i npm-exemplen ovan.

Skyddet ser därför annorlunda ut: tvåfaktorsautentisering på alla konton, få personer med åtkomst, låsta versioner av paketen och en genomgång av vilka skript som faktiskt behövs.

Vad händer med SEO:n om hemsidan hackas?

Ett intrång kan bli ett SEO-problem innan det märks som ett IT-problem. Sucuri hittade SEO-spam på 20,3 % av de infekterade webbplatserna 2023. Vissa intrång är byggda för att tjäna pengar på er domän i Google, inte för att förstöra hemsidan, så det är inte säkert att ni märker något när ni besöker den.

Ett känt mönster är att angriparen skapar mängder av automatgenererade sidor under er domän, ofta på japanska, med affiliatelänkar till butiker som säljer förfalskade märkesvaror. Sidorna visas sedan i Googles sökresultat. Vissa varianter döljer sidorna för ägaren, som får ett falskt ”sidan hittades inte” vid ett direkt besök (Google om det japanska nyckelordshacket). Andra skickar besökare som kommer från sökresultaten vidare till en helt annan webbplats (Google om gibberish-hacket).

Det här kan hända i Google:

• Varning i sökresultatet. Google kan märka träffen med ”Denna webbplats kan ha blivit hackad” (Google Sök-hjälpen), och webbläsaren kan visa en helsidesvarning innan besökaren når hemsidan (Google Search Console-hjälpen). Varningen kan vara det första en potentiell kund ser.
• Rapporten Säkerhetsproblem i Google Search Console. Den visar om Google har hittat hackat innehåll, skadlig kod och oönskad mjukvara eller social manipulering, med exempel på drabbade adresser (Google Search Console-hjälpen). Den är värd att kontrollera även när allt ser normalt ut.
• Sämre placeringar. Google skriver att en flaggad hemsida kan få sämre placeringar under en tid (Google Search Console-hjälpen).

Hur länge det varar beror på hur länge intrånget pågick och hur mycket som hann indexeras. Därför lönar det sig att upptäcka intrång tidigt. Koppla Google Search Console till hemsidan, låt aviseringarna gå till en inkorg som någon läser och gör en site:-sökning på domänen ibland för att se vad Google faktiskt har indexerat.

WordPress-hemsidan är hackad – vad gör vi?

Isolera hemsidan, återställ från en ren backup, byt alla lösenord, uppdatera allt och be Google granska hemsidan på nytt. I den ordningen:

1. Isolera. Sätt hemsidan i underhållsläge eller be hostingbolaget stänga den tillfälligt. Spara loggar och en kopia av den infekterade installationen – de visar hur angriparen kom in.
2. Återställ från en ren backup. Välj en backup från före intrånget. Finns ingen måste filer och databas saneras, och då räcker det inte att ta bort det som syns. Ligger en bakdörr kvar kan angriparen komma tillbaka.
3. Byt alla lösenord. WordPress-konton, databasen, hostingkontot, SFTP och e-postkonton kopplade till hemsidan. Generera nya säkerhetsnycklar i wp-config.php, ta bort administratörskonton ni inte känner igen och slå på tvåfaktorsautentisering. Kontrollera också vilka som är ägare i Google Search Console – angripare lägger ibland till sig själva där (Google).
4. Uppdatera och rensa. Kärna, plugins och tema till senaste version. Ta bort det som inte används, och byt ut pluginet som släppte in angriparen om det saknar en uppdatering.
5. Be Google granska. Kontrollera att spamsidorna inte längre finns, och begär sedan en granskning i rapporten Säkerhetsproblem. Granskningen tar enligt Google allt från några dagar till flera veckor, och att begära den innan hemsidan är helt ren förlänger bara tiden den är flaggad (Google om granskning).

Ligger hemsidan nere eller är den hackad hjälper vi till akut. Hur det går till och vad det kostar står i Hjälp med hemsidan.

När är WordPress ändå rätt val?

WordPress är ett rimligt val när någon äger underhållet och hemsidan behöver det WordPress gör bäst. Det gäller ofta när:

• Ni har en rutin för uppdateringar. Någon uppdaterar varje vecka, kontrollerar hemsidan efteråt och reagerar när en allvarlig lucka publiceras.
• Hemsidan har få och kända plugins. Varje plugin har ett skäl att finnas och en leverantör som underhåller det.
• Ni är beroende av funktioner som saknas på andra plattformar. Medlemssystem, kurser eller en WooCommerce-butik med nischade integrationer.
• Ni har en egen WordPress-utvecklare. Då är ansvaret redan placerat.
• Hemsidan är innehållstung och redaktionen kan WordPress. Kostnaden för att lära om kan vara större än vinsten av ett byte. Headless WordPress är ett mellanläge som behåller redaktionsverktyget men flyttar den publika framsidan bort från WordPress-servern.

Om WordPress är bra för er handlar alltså mer om underhåll än om plattform. Stämmer punkterna är säkerheten hanterbar. Stämmer de inte passar ofta en kodad hemsida med headless CMS eller Webflow bättre, eftersom det löpande underhållet blir mindre.

Hur hjälper SEOS Design er att säkra upp eller byta?

Det finns två vägar, och vilken som passar beror på hur hemsidan är byggd och vem som ska äga den framåt.

Stanna och säkra upp. Vill ni behålla WordPress börjar vi ofta med en genomgång av installationen: plugins, uppdateringsläge, konton, backup och hosting. Förvaltning av en befintlig WordPress-hemsida passar bäst när den är välbyggd och har få plugins. Vad förvaltningen kan omfatta står på sidan om förvaltning och support.

Byta. Vill ni minimera det löpande underhållet är en kodad hemsida med headless CMS eller Webflow ofta rätt spår. Hur beslutet fattas står i Alternativ till WordPress 2026, och hur vi bygger beskriver vi under ny hemsida till företag och headless CMS-byrå. En kodad hemsida kräver inget förvaltningsavtal med oss. Har ni en egen utvecklare kan den ta över underhållet helt. Utan en egen utvecklare är ett mindre förvaltningsavtal ofta bra, eftersom beroendena också behöver uppdateras.

Vi ger en rekommendation när vi hört mer om era behov. Hör av er med adressen till hemsidan och vad som oroar er.