WordPress driver ~43% av webben och är därför det mest attackerade CMS:et i världen. Men de allra flesta intrång beror inte på WP-core utan på övergivna plugins, svaga lösenord och dåliga admin-rutiner. Den här guiden ger en konkret hardening-checklista som faktiskt fungerar.

Kort svar

De viktigaste sex sakerna att göra direkt:

  1. 2FA på alla admin-konton — utan undantag
  2. Automatiska säkerhetsuppdateringar för WP-core och säkerhets-patchar
  3. Plugin-hygien — bara aktiva, underhållna plugins från välkända källor
  4. WAF (ModSecurity eller motsvarande) framför sajten
  5. Daglig backup med snabb återställning, retention 30+ dagar
  6. Begränsa filtillstånd så PHP inte kan skriva överallt

Allt annat (security-headers, hemliga rutter, custom login-URL) är användbart men har mycket lägre effekt än ovanstående.

Hot-modellen för WordPress 2026

Tre dominerande attack-vägar:

  1. Plugin/theme-sårbarheter — ~95% av alla WP-intrång. Antingen kända CVEs i utdaterade plugins, eller nolldags-buggar i nyligen släppta versioner.
  2. Credential stuffing och brute-force — botnät provar listor av läckta lösenord mot /wp-login.php.
  3. Supply chain — komprometterad plugin-utvecklare, eller piratkopierade premium-plugins med backdoors.

WordPress-core självt är relativt säkert sedan 5.x. Det är ekosystemet runtomkring som är problemet.

1. 2FA är icke-förhandlingsbart

Alla användare med edit_posts eller högre ska ha 2FA. Ingen “vi gör det senare”. Plugins som fungerar 2026:

  • Wordfence Login Security — gratis 2FA, integrerar med Google Authenticator/Authy
  • WP 2FA — användarvänligt UI
  • miniOrange 2FA — fungerar med befintlig SSO

Ännu bättre: använd OAuth via Google Workspace eller M365 om ni har det internt. Då är admin-inlogg kopplad till företagets centrala IdP med 2FA på den nivån.

Om någon säger “men det är jobbigt att logga in med 2FA varje gång” — använd “remember device for 30 days” och lägg på IP-allowlist för kontoret.

2. Uppdateringar — vad och hur

WordPress core

Aktivera automatiska säkerhetsuppdateringar (default sedan 3.7). I wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

För stora versioner (6.5 → 6.6): testa i staging först. Plugin-konflikter är vanliga vid major version bumps.

Plugins

Plugins är den största risken. Tre strategier:

  1. Auto-update på allt — enklast men risk för plugin-konflikter. OK för enkla sajter.
  2. Auto-update endast på säkerhetsfixar, manuell för funktionsuppdateringar — kräver hosting med policy-stöd (t.ex. managed WP-hosting där leverantören sköter det).
  3. Manuell uppdatering i staging först — säkrast men kräver disciplin. Lämpligt för affärskritiska sajter.

På Adminor managed WordPress hosting sköter vi detta åt kunden enligt tier-strategi.

Themes

Använd ett aktivt underhållet tema. Övergivna teman är en av vanligaste attack-vägarna. Premium-teman från välkända vendors (Astra, GeneratePress, Kadence, Blocksy) är ok. Piratkopierade premium-teman är garanterat komprometterade.

3. Plugin-hygien

Regler som faktiskt minskar attack-yta:

  1. Avinstallera inaktiva plugins — inte bara avaktivera. Inaktiverade plugins kan fortfarande exekveras via direkt URL-anrop till sårbara filer.
  2. Granska plugin-källa — WP.org repo > GitHub med aktiv community > någons personliga sajt. Aldrig nulled/piratplugins.
  3. Mät underhållsfrekvens — om en plugin inte uppdaterats på 12+ månader, byt. Många kända CVE-listor visar plugin-status.
  4. Begränsa antal plugins — siffran är inte magisk, men 30+ plugins är ofta en signal på dåliga arkitekturval. 10–15 plugins är typiskt tillräckligt även för komplexa WP-sajter.

Plugins att undvika 2026

Plugins med kända återkommande sårbarheter eller dålig underhållshistorik:

  • WPMU DEV-paketet “Smush” (CVE-listan är lång)
  • Slider Revolution (släpper inte fixar i tid)
  • WP File Manager (inte underhållet)
  • WooCommerce Subscriptions piratversioner (alltid backdoored)

Det betyder inte att de aldrig får användas — bara att de kräver extra övervakning.

Plugins som faktiskt höjer säkerhet

  • Wordfence Free — WAF + malware scan + 2FA. Default-val för småsajter.
  • Sucuri Security — auditlog + integritetskontroll.
  • WPScan — sårbarhetsskanner med daglig CVE-uppdatering.
  • Patchstack — managed security-patchar utan att uppdatera själva plugin.

4. wp-config.php hardening

Säkerhetsinställningar som faktiskt spelar roll:

// Förhindra fil-editering via admin-UI
define( 'DISALLOW_FILE_EDIT', true );

// Förhindra plugin-installation via admin (managed-läge)
// Stäng av om ni vill installera plugins via WP-Admin
define( 'DISALLOW_FILE_MODS', true );

// Tvinga SSL för admin
define( 'FORCE_SSL_ADMIN', true );

// Rotera nycklar regelbundet
// Generera nya på https://api.wordpress.org/secret-key/1.1/salt/
define( 'AUTH_KEY', '...' );
define( 'SECURE_AUTH_KEY', '...' );
// ... osv

// Stäng av debug i produktion
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// Begränsa antalet revisions
define( 'WP_POST_REVISIONS', 5 );

Vid intrång (eller misstänkt) — rotera alla nycklar i wp-config. Det invaliderar alla existerande sessioner.

5. Filtillstånd och PHP-execution

Default-rekommendation:

  • Filer: 644
  • Mappar: 755
  • wp-config.php: 600 (eller 400 när det är på plats)
  • .htaccess: 644

PHP-användaren (ofta www-data eller per-customer-användare i ISPConfig) ska inte kunna skriva i:

  • wp-content/plugins/ (utom vid uppdatering — då görs det via WP-CLI eller separat user)
  • wp-content/themes/
  • WP-core-filer

Sätt detta via skriptat post-install:

find /var/www/site/web -type d -exec chmod 755 {} \;
find /var/www/site/web -type f -exec chmod 644 {} \;
chmod 600 /var/www/site/web/wp-config.php

PHP-execution i wp-content/uploads/ ska blockeras med nginx eller .htaccess. Vanligt attack-mönster: uppladdad bild som egentligen är en PHP-shell.

nginx-exempel:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

6. WAF (Web Application Firewall)

ModSecurity med OWASP CRS är de facto-standard 2026. Alternativ:

  • Hosting-nivå: ModSecurity, NAXSI, BunkerWeb
  • Cloudflare WAF: bra om ni redan kör Cloudflare
  • Plugin-nivå: Wordfence WAF (efter PHP-load, sämre prestanda men ändå värdefullt)

Specifika regler att aktivera:

  • Blockera direkta anrop till /xmlrpc.php (om ni inte använder Jetpack eller WP-mobile-app)
  • Blockera enumerering av användare via ?author=N
  • Rate-limita /wp-login.php till t.ex. 5 försök/min/IP
  • Blockera kända WP-skanner-user-agents

7. Login-säkerhet

# nginx rate-limit för wp-login
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=wplogin burst=10 nodelay;
    # ... rest of fastcgi config
}

Ytterligare lager:

  • Byt namn på login-URL med “WPS Hide Login” eller motsvarande. Det stoppar 99% av automatiserade botar utan att irritera riktiga användare.
  • IP-allowlist för wp-admin om ni har fast IP på kontoret. Görs i nginx eller via Cloudflare Access.
  • Stäng av användarregistrering (Settings → General → “Anyone can register”) om ni inte aktivt behöver det.

8. Backup som faktiskt fungerar

3-2-1-regeln gäller:

  • 3 kopior av data
  • 2 olika media
  • 1 off-site

Konkret för WordPress:

  • Daglig automatisk backup av filer + databas
  • Retention 30+ dagar
  • Off-site lagring (inte på samma server)
  • Test av återställning kvartalsvis — annars vet ni inte om backupen faktiskt funkar

Plugins:

  • UpdraftPlus (gratis-version räcker för småsajter)
  • BlogVault (managed, med staging-test ingår)
  • WP Time Capsule (block-level incremental)

Bättre: hosting som backupar på infrastrukturnivå. På Adminor managed WP ingår daglig snapshot + 30 dagars retention som standard.

9. Monitoring och early detection

Saker att larma på:

  • Filändringar i wp-admin/, wp-includes/, wp-config.php (file integrity monitoring)
  • Nya användare med admin-roll
  • Misslyckade login-försök över ett visst tröskelvärde per minut
  • Outgoing connections från webbservern till okända IP:n (tecken på shell)

Verktyg:

  • Wazuh — open source SIEM med WordPress-modul
  • AuditLog plugin — registrerar allt som händer i WP
  • Fail2ban med WP-specifika regler för login-skydd

10. Incident response — vad gör ni vid intrång?

Steg-för-steg:

  1. Isolera — sätt sajten i underhållsläge, stäng av plugins via WP-CLI (wp plugin deactivate --all)
  2. Snapshota nuvarande tillstånd för forensik
  3. Återställ från backup som föregår intrånget
  4. Rotera allt: WP-nycklar, alla användarlösenord, databas-lösenord, FTP/SSH-credentials, alla API-nycklar i wp_options
  5. Granska: hitta hur de kom in. Vilken plugin? Vilket konto? Patcha specifikt.
  6. Övervaka noggrannare i 2–4 veckor efter återställning

Om sajten hanterar känsliga personuppgifter och intrånget kan ha avslöjat dem — GDPR-anmälan inom 72 timmar till Integritetsskyddsmyndigheten.

Hardening-checklista

Print eller spara denna:

  • 2FA på alla användare med edit_posts+
  • Auto-updates aktiverade för WP-core säkerhet
  • Plugin-uppdateringar minst en gång per vecka
  • Inga inaktiva plugins kvar
  • WAF aktiv (ModSecurity, Wordfence, eller motsv.)
  • DISALLOW_FILE_EDIT i wp-config
  • Filtillstånd 644/755, wp-config 600
  • PHP-execution blockerad i wp-content/uploads/
  • Daglig backup med 30+ dagars retention
  • Återställning testad senaste kvartalet
  • File integrity monitoring aktivt
  • Audit log aktivt
  • Rate-limit på /wp-login.php

Sammanfattning

WordPress kan vara säkert om grunden är rätt. De flesta intrång beror på inaktiva plugins, svaga lösenord och saknad 2FA — inte exotiska 0-days i WP-core. Fokusera på de sex punkterna i kortsvaret innan ni grottar ner i security-headers och custom login-URLs.

På Adminor managed WordPress hosting ingår automatiska säkerhetsuppdateringar, daglig backup, ModSecurity WAF, malware-scan med ImunifyAV och löpande security audit som standard.

Vidare läsning