Avansert WordPress-sikkerhet og herding i 2026

Et WordPress-sikkerhetsplugin på en skrivbar origin er ikke herding. Herding i 2026 er identitet, en skrivebeskyttet kjøretid, en kant som kan droppe en payload før PHP starter, og logger origin ikke kan slette.

WordPress 7.1 på PHP 8.4 er en vedlikeholdt applikasjon. Det er også det angripere skanner først, fordi plugin-katalogen, xmlrpc.php og wp-login.php er forutsigbare. Hendelsene vi fortsatt rydder opp i, er ikke «WordPress er usikkert». De er en offentlig admin, en fredagsoppdatering fra dashbordet, og en vert hos Domeneshop eller Simply.com som lar PHP skrive til seg selv.

Denne guiden er driftsversjonen. Passkeys, uforanderlige imager, virtuell WAF-patching, CSP-noncer, composer-revisjon, logger utenfor boksen. WordPress-sikkerhetsrevisjonen er den kommersielle flaten når dere vil ha stakken inspisert, ikke beskrevet. WPPoland er ikke NSM-revisor. Vi herder WordPress og dokumenterer kontrollene. Grunnprinsippene leser dere hos Nasjonal sikkerhetsmyndighet.

#Identitet først: passkeys og wp-admin utenfor det åpne nettet

Innloggingsskjemaet er fortsatt det billigste angrepet. Credential stuffing trenger ingen zero-day. Det trenger wp-login.php på det åpne nettet og en administrator som gjenbrukte et passord fra et lekkasjedump.

Passkeys (WebAuthn) binder seremonien til enheten og til origin. Et etterligningsdomene fullfører den ikke. Derfor tvinger vi passkeys på hver konto som kan installere plugin eller redigere PHP i temaeditoren (som også skal være av). Application passwords for CI bor i secret store, ikke i en felles passordboks markedsavdelingen også har.

Ikke la passordinnlogging ligge som «i nødsfall» på den offentlige URL-en. Reservestien er hvordan phishing fortsatt virker. Nødadgang er en hardware-nøkkel i et safeskap, eller gjenoppretting gjennom identitetsleverandøren, på en sti som ikke er wp-login.php.

wp-admin hører ikke hjemme på det åpne nettet. Cloudflare Access, en Tailscale-funnel, eller den identitetsbevisste proxyen virksomheten allerede bruker til interne verktøy. Anonym GET av butikkfronten blir cachet. /wp-admin og wp-login.php svarer 403 eller en SSO-utfordring. xmlrpc.php er av med mindre Jetpack eller en mobilapp faktisk trenger den, og da er den allow-listet på metode og IP, ikke stående som pingback-kanon.

Vi ser fortsatt butikker som «skjulte» wp-admin ved å døpe innloggingen om til /innlogging eller /backend. Det er ikke identitet. Crawlere finner den nye slugen på en dag. En idrettsforening i Trondheim hadde gjort akkurat det, pluss et «sikkerhetsplugin» som e-postet 401-er til en innboks ingen leste. Stuffing-kjøringen låste redaktøren ute. Skjul flaten bak identitet, eller la være.

REST er ikke «tryggere enn xmlrpc» som standard. /wp-json/wp/v2/users enumererer innlogginger på mange standardinstallasjoner. Application passwords for en headless-front skal være scoped og roteres. Users-endepunktet er GET av en grunn på offentlige blogger. I en WooCommerce-butikk er det en gave. Slå det av eller krev auth. Det samme gjelder ?author=1-redirects som lekker admin som nicename.

Rate-limiting av innlogging i PHP er hvordan dere DDoS-er dere selv. WAF eller Access gjør den jobben. Hvis dere må ha offentlig innlogging for medlemmer (en forening, et kurs), går administratorer likevel gjennom Access på et annet vertsnavn. Én wp-login.php for alle er hvordan en stuffing-kjøring stenger redaktøren ute av egen side.

#NSM-grunnprinsipper og BankID foran wp-admin

Nasjonal sikkerhetsmyndighet publiserer grunnprinsipper for IKT-sikkerhet. De er fire hoder: identifiser og kartlegg, beskytt og oppretthold, oppdag, håndter og gjenopprett. De er et rammeverk for styret og for IKT-ansvarlig, ikke et merke i footeren og ikke et sertifikat WPPoland kan utstede. En WordPress-stakk som hevder «NSM-godkjent» uten å peke på en faktisk tilsynssak, selger et klistremerke. Vi mapper prinsippene til kontroller på origin. Revisjonen gjør kunden, eller en revisor kunden har valgt.

Kartleggingen er lockfilen og dataklassifiseringen, ikke et Excel-ark med «vi har Wordfence». Hvilke plugin kjører. Hvilke personopplysninger ligger i wp_users, wp_usermeta og Woo-ordrer. Hvilken databehandleravtale dere har med Domeneshop, Simply.com, Loopia eller den som faktisk har disken. Datatilsynet spør etter behandlingsgrunnlag og underleverandører. Personopplysningsloven gjelder ordrer, nyhetsbrevlister og innloggingslogger med IP. Hvis dere ikke kan navngi det, har dere ikke identifisert.

Beskyttelse på wp-admin i Norge er sjelden Okta. Den er BankID eller ID-porten foran vertsnavnet. Ansatte har allerede BankID. Et OIDC-løp (BankID OIDC via Signicat, Criipto eller tilsvarende broker) foran Cloudflare Access, eller oauth2-proxy på egen VPS, gjør wp-login.php uinteressant for stuffing. ID-porten er Digdir-sporet for stat og kommune. Bland dem ikke: en kommunal innsynsside bak ID-porten, en butikk-admin bak BankID for ansatte. Vipps Login er for kunder i kassen, ikke for folk som kan installere plugin.

BankID foran wp-admin er ikke et 2FA-plugin i WordPress. Pluginet ser forespørselen etter at PHP har startet. Brokerseremonien skjer før origin. Et etterligningsdomene som kloner innloggingsskjemaet, får ikke fullført BankID mot deres client-id. Det er samme idé som passkeys, på en identitet nordmenn allerede har i lommeboka. Passkeys inne i WordPress kan ligge oppå: BankID for å nå admin-verten, passkey for å bli administrator. To seremonier. Én uten BankID og med åpen wp-login.php er den vi rydder.

Vipps i kassen er en annen identitet. Checkout, ePayment-webhook, logg inn med telefon. Den stien skal være åpen for Vipps sine IP-er og signaturer, og stengt for resten. En WAF-regel som «beskytter wp-admin» og samtidig kveler /wp-json/ eller admin-ajax som Vipps treffer, er ikke NSM-beskyttelse. Det er en selvlaget hendelse en 17. mai-helg.

Oppdagelse er logger utenfor origin, WAF-treff og varsel på ny administrator. Håndtering er restore testet på en klone, ikke et snapshot i samme Domeneshop-konto. Grunnprinsipp fire er verdiløst hvis backupen dør med verten. Vi er et WordPress-byrå. Vi peker på kontrollene. Vi later ikke som vi er NSM.

BankID som nødadgang er feil vei. Hvis IdP-en er nede, trenger dere en hardware-nøkkel på en intern sti, ikke et passord på den offentlige butikk-URL-en. Det er det samme skillet som i identitetsseksjonen over. NSM ber om at tilgangen er styrt og at unntak er skrevet ned. Unntaket er ikke «admin/admin i en Slack-tråd».

#Skrivebeskyttet kjøretid: disken som nekter et skall

Dashbordoppdateringer er en sikkerhetsbeslutning. De ser ut som bekvemmelighet. De er en skriving til produksjon av den som har en admin-cookie.

Behandle PHP-treet som skrivebeskyttet. WordPress kjører fra et image (container, eller rsync av et byggeartefakt). wp-content/plugins og wp-content/themes ligger i det imaget. Det eneste skrivbare volumet er uploads, og det volumet kjører ikke PHP. Hvis en plugin-RCE prøver å legge wp-content/uploads/cache.php, feiler skrivingen eller filen ligger ikke i kjørbar sti.

Oppdateringer skjer da i git:

1. Dependabot eller en planlagt composer-bump åpner en PR.
2. CI kjører phpstan, en røyktest og en lockfil-CVE-skanning.
3. Imaget bygges og deployes. Forrige image ligger der for rollback.

Live-serveren «redigeres» aldri. Det dreper også klassen skadevare som overlever ved å skrive til wp-config.php eller til et must-use-plugin dashbordet aldri lister.

På Domeneshop, Simply.com og Loopia i billiglaget er dette ofte umulig. PHP kjører som samme bruker som eier filene. Panelet tilbyr «ett klikk oppdater». SSH mangler, eller det finnes uten composer. Da har dere ikke uforanderlig kjøretid. Dere har et plugin og et håp. Herdingen starter med å flytte origin til en VPS eller en WordPress-host som tar imot et image (ServeBolt med composer, en Domeneshop VPS med root, Hetzner i EØS). Å late som Wordfence kompenserer for skrivbar disk, er hvordan skallene lander.

Databasebruker: SELECT, INSERT, UPDATE, DELETE på nettstedets skjema. Ingen DROP, ingen FILE, ingen GRANT. TLS til MySQL. Tabellprefiks er ikke en kontroll. Det er trivia.

Objektcache (Redis) holder sesjoner og transients. Behandle den som et lager av hemmeligheter. Nettverksisolasjon, AUTH, ingen offentlig port. En «flush all» fra en kompromittert admin er en tilgjengelighetshendelse. Skill cache for sesjoner fra cache for HTML-fragmenter hvis dere kan. Vi har sett et plugin skrive et reset-passord-token inn i en delt Redis, og et annet nettsted på samme Loopia-vert lese det. Det er en hostingsfeil, ikke en WordPress-feil, og den lander likevel i hendelseskanalen deres.

wp-config.php-nøkler (AUTH_KEY og venner) roteres når dere mistenker cookietyveri, og gamle sesjoner dør. Nøklene i miljøet, ikke i imaget, betyr at et lekket repo ikke er en lekket innlogging. Imaget trenger fortsatt en måte å starte på. Bruk plattformens secret store. Ikke commit en .env til samme git frontend-byrået kan klone.

#WAF og virtuell patching

WAF sitter foran origin. Den ser HTTP-forespørselen før PHP bootstrapper. Det er den eneste grunnen til at den er verdt pengene.

Hva den er til:

• Kjente utnyttelsesstier: flom mot /wp-login.php, xmlrpc multicall, REST-ruter som ikke skal være anonyme.
• En virtuell patch samme dag en WooCommerce- eller Elementor-CVE er offentlig, mens dere bygger imaget på nytt. Timer, ikke helgen.
• Rate limits som applikasjonen ellers ville implementert dårlig i PHP.

Hva den ikke er til: å erstatte input-validering, eller å være den eneste kopien av access-loggen.

Administrerte WordPress-verter selger ofte «vi har WAF». Spør om dere kan legge inn en regel samme dag, og om regelen treffer før PHP. Hvis svaret er en sakskø, er det ikke virtuell patching. Domeneshop og Simply.com har kantfiltre. De er ikke deres regelmotor. En virtuell patch dere ikke kan navngi, eier dere ikke.

Vipps, Klarna og Nets sender webhooks til origin. Hver skip-regel er et skriftlig unntak med begrunnelse. Et hopp over hele /wp-admin/admin-ajax.php fordi «Vipps-knappen døde» åpner origin for RCE igjen. Hopp den konkrete stien Vipps dokumenterer, verifiser signaturen i PHP, og la resten treffe WAF.

#Wordfence på origin mot WAF på kanten

Dette er driftsvalget vi gjentar, og det som skiller et billig «sikkerhetsplugin» fra en stakk som fortsatt svarer etter en CVE-fredag.

Wordfence, Sucuri-plugin, iThemes kjører inne i PHP. De kan skanne filer, de kan strupe wp-login, de kan sende e-post. De starter etter at forespørselen allerede har nådd origin. En payload som utnytter PHP-workeren før pluginets init-krok, rekker de ikke å se. De trenger også et skrivbart filsystem til egne data, som kjemper mot den skrivebeskyttede kjøretiden.

Cloudflare WAF (eller Fastly, eller WAF foran VPS-en) kjører på cachenoden. Anonym GET kan forbli et cache-treff. En POST som matcher en CVE-signatur, når aldri PHP. Virtuell patching er et regeltrykk, ikke en pluginoppdatering. Origin-imaget blir skrivebeskyttet.

Regler vi bruker:

• Innlogging og xmlrpc bare fra Access, eller blokkert. Butikk-POST (kasse, konto) går gjennom WAF med et administrert WordPress-regelsett pluss et skreddersydd hopp for betalingswebhookene dere faktisk eier (Vipps, Klarna, Stripe). Å hoppe over /wp-admin/admin-ajax.php i sin helhet er hvordan folk ødelegger sin egen WAF.
• Wordfence, hvis det blir igjen i det hele tatt, er en skanner i CI eller på en staging-klone, ikke en runtime-brannmur i produksjon. To brannmurer som begge tror de eier rate limits, stenger ekte kunder ute og treffer likevel ikke CVE-en.
• Filintegritet: sammenlign deployet image med git, ikke et plugin som vandrer wp-content på hver cron. Cron på origin er enda en PHP-prosess dere ikke trengte.

En nettbutikk vi bygde om i 2025, hostet hos Simply.com med Wordfence «high sensitivity», Cloudflare «I’m under attack» på samme URL, og en Vipps-callback som POST-et til admin-ajax. Kassen var død et døgn. CVE-en de var redde for, ble patcht på kanten i én regel. Plugin-krigen var nedetiden. Wordfence krevde skrivbare mapper. Det var også stien skallet ville ha brukt.

Virtuell patching har holdbarhet. WAF-regelen er helgen. Image-rebuild er uken. Hvis regelen fortsatt er den eneste fiksen et halvt år senere, har dere ikke en pipeline, dere har en lapp på skjermen. Vi behandler en åpen virtuell patch som en sak med eier, ikke som et merke.

Skip-lister er der WAF-er dør. /wp-admin/admin-ajax.php, /?wc-ajax=, Vipps notify, Stripe-webhooks, Apple Pay domain verify. Hvert hopp er et skriftlig unntak. Et hopp for «cookie-banneret knakk» som også åpner admin-ajax for verden, er hvordan et billig plugin blir origin-RCE igjen.

#CSP-noncer, ikke en kommentar i .htaccess

Content-Security-Policy er nettleseren som nekter å kjøre et skript dere ikke sendte. XSS i et plugin skjer fortsatt. CSP er det som stopper det skriptet fra å kalle ut.

En policy som virker på et WordPress-tema, i praksis:

• default-src 'self'
• script-src 'self' 'nonce-…' pluss de to eller tre betalingsoriginene dere kan navngi (Vipps, Klarna)
• style-src 'self' 'unsafe-inline' til dere har hashet temaet (unsafe-inline på style er et kompromiss; ikke kopier det over på script)
• frame-ancestors 'none' med mindre dere faktisk embedder siden
• object-src 'none'
• base-uri 'self'

Noncen må endres per svar. En statisk nonce i wp_head er teater. HTMLRewriter på kanten, eller et PHP mu-plugin som skriver headeren og matchende attributter, begge virker. Plugin-katalogen er full av «legg til CSP»-plugin som emitterer 'unsafe-inline' på script. Den policyen stopper ikke XSS. Den dokumenterer at dere prøvde.

Report-Only først. Les rapportene en uke. Deretter enforce. Vipps, Tag Manager og samtykkeplattformen (Cookie Information, Cookiebot) vil ligge i rapporten. Hver av dem er en beslutning: tillat etter origin, eller ta den av førstepartssiden.

CSP er ikke en erstatning for esc_html og noncer på skjemaer. Det er siste gjerde.

På Loopia- og Domeneshop-planer uten headerkontroll i panelet, setter dere CSP i PHP eller på Cloudflare. En kommentar i .htaccess som aldri treffer fordi verten overstyrer Apache, er ikke en policy.

#Leverandørkjede: composer, plugin-katalogen og fredagsoppdateringer

De fleste WordPress-kompromissene vi fortsatt ser, starter som et plugin, ikke som kjerne. Kjernen har en release-prosess. Et plugin med 200 000 installasjoner kan sende hjem i en minor.

Hva vi gjør:

• Plugin dere er avhengige av, bor i composer (wpackagist eller et privat speil) slik at lockfilen er materiallisten. «Installer fra wp-admin» er av i produksjon.
• CI feiler PR-en hvis composer audit eller npm-audit på temaverktøykjeden rapporterer en kjent CVE over listen dere har satt. Listen er ikke «bare critical». En glemt XSS i et skjemaplugin er nok.
• Nye plugin får en lesing av eval, file_get_contents av eksterne URL-er, og admin-post-handlere før de kommer inn i speilet. Det er en time, ikke et teatersertifikat.
• Auto-oppdateringer i produksjon er av. Auto-oppdateringer på en staging-klone som promoveres gjennom samme pipeline, er greit.

Fredag før en langhelg er den norske klassikeren. Redaktøren oppdaterer Woo og «et lite» popup-plugin fra dashbordet, reiser på hytta, og mandag er kassen en PHP-advarsel. Auto-oppdatering på Domeneshop i det vinduet er samme klasse. Pipeline eller ingenting.

NIS2- og DORA-vurderingen er der EU-operatørpliktene bor. Denne seksjonen er engineeringsarbeidet som gjør pliktene mulige: dere kan navngi det som kjører, og dere kan bygge det på nytt. NSM-grunnprinsippet «identifiser» er lockfilen. Uten den har dere en pluginliste i et skjermbilde.

Personopplysningsloven treffer leverandørkjeden når pluginet sender ordrer eller e-postlister ut av EØS. Les call_user_func mot eksterne URL-er. En «anbefalt» SMTP-tjeneste uten databehandleravtale er en Datatilsynet-sak, ikke en ytelsessak.

#Logger som overlever hendelsen

Hvis den eneste kopien av auth.log og PHP-errorloggen ligger på verten som nettopp fikk et skall, har dere ikke en hendelsestidslinje. Dere har en gjenoppbygd server og et gjett.

Send:

• nginx- eller Cloudflare-requestlogger (WAF-handling, sti, land, ray id)
• PHP-FPM-feil og slow log
• WordPress authenticate-feil og user_register / set_role
• Deploy-hendelser fra CI (hvem sendte hvilket image)

til en bøtte eller et SIEM origin-rollen ikke kan slette. Retensjon dere faktisk kan søke i: 90 dager varmt er nok for en butikk. Regulerte lesere går lenger fordi advokaten sa det, ikke fordi et plugin tilbød «log retention».

IP-adresser og innlogginger kan være personopplysninger. Datatilsynet forventer behandlingsgrunnlag og sletting. En logg som lever evig «i tilfelle» uten hjemmel, er en ny sak. Skill tekniske WAF-dropp fra logger som kan identifisere en person. Personopplysningsloven stopper dere ikke fra å ha evidens. Den stopper dere fra å late som evidens er marketing.

Varsle på: spike av 401 mot wp-login (hvis den fortsatt er offentlig, er det allerede feilen), ny administrator, plugin-filhash som driver mot git, WAF-blokkerate som trapper opp på en REST-rute.

Ikke kjøp «AI-avviksdeteksjon» som første kontroll. Første kontroll er «vi har loggene» og «noen leser admin-opprett-hendelsene på mandag». En Wordfence-e-post til post@bedrift.no som lander i en delt innboks, er ikke oppdagelse.

Domeneshop-filbehandleren er ikke SIEM. Simply.com sitt «error log»-panel forsvinner når dere reinstallerer. Loopia-backup i samme konto slettes av den som har panelet. Logger utenfor boksen betyr en annen leverandør, en annen nøkkel, og at origin ikke kan rm.

#Det vi faktisk endrer den første uken

En herdingsjobb er ikke et regneark med 25 rader. Det er en kort sekvens dere kan fullføre.

1. Ta skjermbilde av gjeldende pluginliste og siste dashbordoppdateringer. Det er åstedet hvis noe allerede er galt.
2. Sett Access foran wp-admin. Koble BankID eller virksomhetens IdP. Tving passkeys for administratorer. Slå av xmlrpc hvis den ikke brukes.
3. Stopp plugininstallasjon i produksjon. Åpne composer-stien selv om første commit bare pinner det som allerede ligger der.
4. Legg på et administrert WAF-regelsett og én virtuell patch dere kan navngi (siste CVE i pluginlisten).
5. Send CSP i Report-Only. Les rapporten.
6. Send logger utenfor boksen. Bekreft at dere kan grepe en feilet innlogging fra i går uten SSH til origin.

Deretter blir imaget skrivebeskyttet. Det steget sist, fordi det knuser «rediger i wp-admin»-arbeidsflyter ingen dokumenterte. Dokumenter dem først, ellers ruller dere tilbake skrivebeskyttelsen på lørdag.

Redaktøren som limer inn i en gjenbrukbar blokk, markedsføreren som installerer «ett lite» popup, frilanseren som har admin fordi «de må laste opp en PDF»: de tre kontoene er den gjenværende skrivestien. To av dem skal være editor eller en egendefinert rolle som ikke kan installere plugin. PDF-en går til uploads, som ikke kan kjøre PHP. Trenger de et nytt plugin, er det en PR, ikke en fredag.

Hvis origin fortsatt står på delt Domeneshop uten SSH, er uke én også flytteplanen. Uforanderlig kjøretid kommer ikke av et plugin. Den kommer av et image. Si det til styret før dere lover NSM-språk i en anskaffelse.

Backup er ikke herding, men det er hvordan dere forlater en hendelse. Off-site, versjonert, restore testet på en klone som ikke er produksjon. En backup som bare bor på samme VPS, er en andre kopi av samme disk. Vi gjenoppretter en staging-klone før vi kaller jobben ferdig, fordi en backup dere aldri har gjenopprettet, er en fil, ikke en plan.

#Revisjon og videre lesing

WordPress-sikkerhetsrevisjonen er identitet, kjøretid, kant og logger på den faktiske verten, ikke en generisk sjekkliste. Vi åpner wp-admin-eksponering og plugin-lockfilen først. Lighthouse-lignende poeng er ikke et sikkerhetssignal. Revisjonen er ikke en NSM-revisjon. Hvis kunden trenger tilsynsspråk, henter de en revisor. Vi leverer stakken og evidenset.

EU-operatørplikter (logging, hendelsesklokker, navngitte kontakter) ligger i NIS2- og DORA-vurderingen. Arkitektur som krymper PHP på offentlig origin, står i headless WordPress-arkitektur 2026. Headless er ikke en sikkerhetskontroll i seg selv. Det er en mindre PHP-flate hvis fronten er statisk og wp-admin er privat. Vipps Login mot origin og cache-tags hører hjemme der, ikke som erstatning for BankID foran admin.

Datatilsynet og personopplysningsloven styrer hva dere kan lagre om personer. De erstatter ikke WAF. De forteller hvor lenge innloggingslogger med IP kan ligge, og at en databehandleravtale med hosten skal finnes før ordrene gjør det.

#Konklusjon

WordPress-kjernen er ikke den svake delen. Den svake delen er en offentlig innlogging, en skrivbar disk, et sikkerhetsplugin som kjører etter at PHP har startet, og logger som dør med verten. Passkeys, et identitetsbevisst wp-admin (i Norge: BankID eller ID-porten foran verten), et skrivebeskyttet image, en WAF som kan virtuell-patche, CSP med ekte noncer, en lockfil, og logger utenfor boksen. Det er listen. En pluginside som sier «beskyttet» står ikke på den.

Skriv med URL, pluginliste og om wp-admin er offentlig, hvis dere vil ha det inspisert. Sikkerhetsrevisjonen er den kommersielle flaten.

PCI, ISO 27001, NSM-grunnprinsipper: ingen av dem er et plugin. PCI betyr at kortdata aldri ligger i WordPress. ISO er operatørprosessen rundt det denne guiden allerede lister. NSM er rammeverket over. Hvis en leverandør selger «SOC2 WordPress», be om rapporten på hostingen deres, ikke et merke i footeren. Vi selger ikke det merket.