Prestanda & Säkerhet
Säkerhet i WordPress
Det som faktiskt skyddar din webbplats
Problemet är inte WordPress – det är det du installerar
Under 2025 registrerades 11 334 nya sårbarheter i WordPress-ekosystemet, 42 % fler än 2024. Bara 6 fanns i kärnan, alla med låg prioritet; 91 % fanns i tillägg (plugins) och 9 % i teman (Patchstack, 2026).
Det förändrar frågan. ”Är WordPress säkert?” är fel fråga. Rätt fråga är: hur många tredjepartskomponenter kör du, vem underhåller var och en, och hur snabbt reagerar du när en av dem går sönder?
Och ”snabbt” betyder nu timmar. Enligt samma rapport utsätts de mest eftertraktade sårbarheterna för den första massattacken med en viktad median på 5 timmar efter offentliggörandet, och ungefär hälften av sårbarheterna med hög påverkan utnyttjas inom 24 timmar.
En ärlig reservation: Patchstack säljer skydd mot exakt det här problemet. Siffrorna är de bästa som finns offentligt, men läs dem med vetskap om vem som publicerat dem.
Tillägg och teman: där den verkliga risken finns
Varje tillägg är tredjepartskod som körs med full åtkomst till din databas och ditt filsystem. Tre siffror från 2025 visar varför det väger tungt:
| Indiktor | Värde | Vad det btyder i praktiken |
|---|---|---|
| Sårbarheter utan rättning vid offentliggörandet | 46% | Att uppdatera räcker inte: i nästan hälften av fallen finns ingen uppdatering att installera |
| Sårbarheter i premiumtillägg som går att utnyttja i verkliga attacker | 76% | “Betalt” betyder inte “säkert” |
| Kända utnyttjade sårbarheter: premium vs. gratis | 3× fler i premium | Stängd kod granskas mindre av externa forskare |
Källa: Patchstack, State of WordPress Security in 2026.
Poängen om premiumtillägg går emot en vanlig uppfattning hos kunder och till och med hos byråer. Komponenter som säljs på marknadsplatser som Envato är svårare för forskare att komma åt. Färre ögon på koden betyder att fel upptäcks senare – ofta av angriparna först.
Äldre versioner attackeras också fortfarande. Av de tio mest utnyttjade målen 2025 var bara fyra sårbarheter publicerade samma år; i toppen fanns fel från 2023 och 2024 i populära tillägg som LiteSpeed Cache och tagDiv Composer. Webbplatser som inte uppdaterats på månader är lätta byten.
Tumregel: varje tillägg måste motivera sin plats. Innan du installerar, kontrollera datumet för senaste uppdateringen, historiken av sårbarheter (i Patchstacks databas eller Wordfences) och om leverantören har ett program för rapportering av sårbarheter. Inom EU börjar Cyber Resilience Act kräva ett sådant program för kommersiella tillägg.
Så går attackerna till
Den mest utnyttjade kategorin 2025 var Broken Access Control: behörighetsfel där ett tillägg låter en användare utan rättigheter utföra privilegierade åtgärder. Den är farligast eftersom attacktrafiken ser ut som en legitim förfrågan, och generiska brandväggar känner inte igen den.
| Attackvektor | Så fungerar den | Verkligt exempel som utnyttjades 2025 |
|---|---|---|
| Bruten åtkomstkontroll / rättighetseskalering | AJAX- eller REST-endpoint utan kontroll av capability eller nonce | SureTriggers ≤ 1.0.82, LiteSpeed Cache ≤ 6.3.0.1 |
| Godtycklig filuppladdning | Ett formulär accepterar förklädd PHP och angriparen får ett skal | Startklar Elementor Addons ≤ 1.7.13 |
| Lagrad XSS | Skadligt skript sparas i databasen och körs i administratörens webbläsare | LiteSpeed Cache ≤ 5.7, tagDiv Composer ≤ 4.2 |
| PHP Object Injection / RCE | Opålitlig data skickas till unserialize() | GiveWP ≤ 3.14.1 |
| Fjärrinstallation av tillägg | En funktion utan behörighetskontroll låter vem som helst installera tillägg | FunnelKit Automations ≤ 3.5.3 |
| Brute force och läckta inloggningsuppgifter | Återanvända lösenord testas mot wp-login.php och xmlrpc.php | Ständigt pågående, utan CVE |
Exempel: Patchstack, topp 10 utnyttjade sårbarheter 2025.
Efter intrånget blir problemet värre. Modern skadlig kod är byggd för att inte synas: familjer som Parrot TDS visar rent innehåll för webbplatsägaren och för skannrar, och omdirigerar bara vanliga besökare. Andra, som Lock360, ligger i serverns minne och återinfekterar index.php och .htaccess så fort du rensat dem. Därför är ”kör en skanner och radera den misstänkta filen” inte längre en pålitlig återställningsstrategi.
Säkerhetstillägg: användbara, men inte på det sätt du tror
Ett säkerhetstillägg är ett lager, inte en lösning. Frågan som spelar roll är: hur lång tid tar det innan det blockerar en nyss offentliggjord sårbarhet? När massutnyttjande börjar inom timmar skyddar en regel som kommer efter veckor dåligt mot det som är nytt.
| Verktyg | Huvudsaklig metod | Styrka | Begränsning du behöver känna till |
|---|---|---|---|
| Wordfence Free | Applikationsbrandvägg + skanner för skadlig kod på servern | Gratis, moget, bra skanner och sårbarhetsvarningar | Brandväggsregler och signaturer kommer 30 dagar senare än i betalversionen |
| Wordfence Premium / Care | Samma, med realtidsregler och lista över skadliga IP-adresser | Stänger 30-dagarsfönstret | Kostnad per webbplats; körs fortfarande inuti WordPress |
| Patchstack | ”Virtual patching”: specifika regler för den sårbara versionen som är installerad | Regeln publiceras vid offentliggörandet, även utan rättning från leverantören | Ingen skanner för skadlig kod och inget saneringsverktyg |
| Solid Security Pro | Härdning, 2FA, versionshantering; virtual patching via Patchstack | Samlar härdning och sårbarhetsskydd i en panel | En del funktioner överlappar det som webbhotellet eller en bra wp-config.php redan gör |
| WAF i nätverkskanten (Cloudflare, Sucuri) | Filtrerar trafik innan den når servern | Stoppar botar, brute force och generiska attacker utan att belasta servern | Svag mot WordPress-specifika behörighetsfel |
Den sista begränsningen är den mest underskattade. I penetrationstester som Patchstack genomförde hos populära webbhotell blockerade traditionella skydd (interna WAF:er, Cloudflare m.fl.) bara 12 % av de WordPress-specifika attackerna och 26 % i det utökade testet (Patchstack, 2026). Samma reservation igen: den som gjorde testet säljer alternativet. Ändå håller den tekniska logiken – en generisk WAF vet inte att just den POST-förfrågan till admin-ajax.php utnyttjar en saknad behörighetskontroll.
Installera inte två applikationsbrandväggar samtidigt. Wordfence och Solid Security tillsammans ger konflikter, resursförbrukning och falsk känsla av skydd. Kombinera olika lager: en WAF i kanten för generisk trafik, virtual patching eller en brandvägg med realtidsregler för WordPress-sårbarheter, och en skanner för upptäckt.
Försvar i lager: det som faktiskt minskar risken
Ingen enskild åtgärd löser problemet. Ordningen nedan följer effekt per insats: de första tar bort större delen av attackytan.
- Minska attackytan. Ta bort (inte bara inaktivera) tillägg och teman som inte används. Ett inaktiverat tillägg har fortfarande PHP-filer som går att nå på servern. Välj hellre ett välskött tillägg än tre som gör samma sak.
- Uppdatera snabbt och kontrollerat. Aktivera automatiska uppdateringar för mindre versioner och säkerhetsversioner. För kritiska tillägg (e-handel, formulär, sidbyggare), använd staging och en veckovis cykel, inte månadsvis.
- Täck fönstret utan rättning. Eftersom 46 % av sårbarheterna saknar rättning vid offentliggörandet behöver du virtual patching eller en brandvägg med realtidsregler. Uppdateringar ensamma stänger inte det hålet.
- Skydda åtkomsten.
- Obligatorisk 2FA för alla användare med rollen Redaktör eller högre.
- Unika lösenord från en lösenordshanterare; återanvänd aldrig inloggningar från andra tjänster.
- Begränsa inloggningsförsök och blockera xmlrpc.php om du inte använder appar eller Jetpack.
- Principen om minsta behörighet: en kund som bara publicerar inlägg är Redaktör eller Författare, inte Administratör.
- Härda konfigurationen. I wp-config.php: define(‘DISALLOW_FILE_EDIT’, true); för att stänga av kodredigeraren i panelen; unika nycklar och salts; ett tabellprefix annat än wp_ i nya installationer. På servern: blockera PHP-körning i /wp-content/uploads/ och använd behörigheterna 644 för filer och 755 för kataloger.
- Välj webbhotell efter isolering, inte pris. På delad hosting utan isolering per konto kan en komprometterad grannwebbplats påverka din. Kräv en PHP-version som stöds, isolering mellan konton och backuper utanför servern.
- Ha backuper som du redan testat att återställa. Daglig backup, sparad i minst 30 dagar, lagrad utanför servern (modern skadlig kod raderar även lokala backuper). En backup som aldrig återställts är en hypotes, inte en plan.
- Övervaka. Larm för filintegritet, aktivitetslogg för administratörer och övervakning av driftstatus. Cloaking gör att webbplatsen ser ren ut för dig – den första varningen kommer ofta från Google Search Console eller en kund.
För dig som arbetar headless (WPGraphQL + Next.js): ett separat frontend minskar exponeringen men tar inte bort den. Panelen /wp-admin och GraphQL-endpointen är fortfarande publika som standard. Begränsa admin via IP eller VPN, stäng av GraphQL-introspektion i produktion, begränsa djup och kostnad för queries och exponera aldrig känsliga ACF-fält i det publika schemat.
Myter som gör webbplatser sårbara
| Myt | Verklighet |
|---|---|
| ”Jag har ett säkerhetstillägg, jag är skyddad.” | Det är ett lager. I gratisversionen av Wordfence kommer nya regler 30 dagar senare; massattacker börjar inom timmar. |
| ”Betalda tillägg är säkrare.” | Under 2025 hade premiumkomponenter 3× fler utnyttjade sårbarheter än gratiskomponenter. |
| ”Det räcker att hålla allt uppdaterat.” | 46 % av sårbarheterna saknade rättning när de offentliggjordes. Att uppdatera är nödvändigt men inte tillräckligt. |
| ”Min webbplats är liten, ingen kommer att attackera den.” | Attackerna är automatiserade och skannar hela internet efter sårbara versioner. Storleken spelar ingen roll; tilläggets version gör det. |
| ”Att byta inloggnings-URL löser det.” | Det minskar bruset från brute force-botar men skyddar inte mot sårbarheter i tillägg, som är den huvudsakliga vägen in. |
| ”Webbhotellet sköter säkerheten.” | Webbhotell sköter servern. I Patchstacks tester blockerade webbhotellens skydd bara en liten del av de WordPress-specifika attackerna. |
| ”Jag har rensat bort den skadliga koden, nu är det klart.” | Minnesresident skadlig kod och planterade uppladdare återinfekterar webbplatsen. Utan att stänga ingångshålet och byta inloggningsuppgifter är återinfektion sannolik. |
Checklista för WordPress-säkerhet
- Oanvända tillägg och teman borttagna från servern
- Varje kvarvarande tillägg uppdaterat de senaste 6 månaderna och utan öppna sårbarheter i Patchstacks eller Wordfences databas
- Automatiska säkerhetsuppdateringar aktiva; kritiska tillägg testade i staging
- Virtual patching eller brandvägg med realtidsregler som täcker sårbarheter utan rättning
- 2FA aktiv för alla användare med rollen Redaktör eller högre
- Inga onödiga administratörer
- DISALLOW_FILE_EDIT aktiv och PHP-körning blockerad i /uploads/
- xmlrpc.php blockerad (om den inte används)
- Daglig backup utanför servern, med återställning testad de senaste 3 månaderna
- Övervakning av filintegritet och larm från Google Search Console aktiva
- Headless: GraphQL-introspektion avstängd i produktion och admin begränsad
Säkerhet i WordPress handlar om reaktionshastighet, inte om listan av installerade tillägg. Den webbplats som skyddar sig väl kör lite tredjepartskod, vet exakt vad den kör och kan stoppa en ny sårbarhet samma dag som den blir offentlig.
Källor
- Patchstack — State of WordPress Security in 2026 (data från 2025, publicerad i feb. 2026)
- Wordfence — planer och skillnader mellan Free och Premium
- SolidWP — WordPress Vulnerability Report, 4 mars 2026