WordPress-sikkerhet, oppdateringer og hardening

Et WordPress-nettsted blir sjelden tatt med en ny teknikk. Det blir tatt gjennom en feil som allerede var rettet og som ingen rakk å installere. Denne artikkelen starter med den siste sikkerhetsutgivelsen i kjernen og følger hele veien: hva som ble rettet, hva som oppdateres av seg selv, hva som ikke gjør det, hvordan du oppdaterer uten å knekke nettstedet, og hva som gjelder når noe likevel går galt.

#Hva WordPress 7.1.3 rettet

WordPress 7.1.3 kom 6. oktober 2026 med 7 sikkerhetsrettinger og 4 feilrettinger. Utgivelsesnotatet lister feiltypene:

• lagret XSS på administrasjonssiden for kommentarer, utløst via ventende kommentarer
• et tjenestenektproblem i WP_Http::make_absolute_url()
• en andreordens SQL-injeksjon i WXR-eksporten
• en svakhet som lot brukere med Forfatter-rollen feste innlegg øverst
• uautentisert innsyn i kommentarer på private og upubliserte innlegg
• XSS i Imgur-innbygginger
• forfalskbare parametere i kroken {status}_{type} som ga navnekollisjon mellom handlinger

Blant krediteringene er Thomas Chauchefoin (Trail of Bits) og Ananda Dhakal (Patchstack). Anthropic er kreditert for tre av feilene: tjenestenekt, SQL-injeksjonen og svakheten med festede innlegg.

Den 17. september 2026 hadde WordPress 7.1.1 allerede kommet med 11 sikkerhetsrettinger, blant dem lagret XSS i wpautop(), autentisert path traversal i REST-malkontrolleren og overskriving av vilkårlige innlegg fra Bidragsyter-rollen.

Lest nøkternt viser listen feil som krever en innlogget rolle, en ventende kommentar eller en bestemt funksjon. Derfor blir de utsatt. Argumentet for å skynde seg er regnestykke, ikke dramatikk: rettingen og diffen er offentlig samme dag som utgivelsen, og tiden mellom den dagen og dagen du oppdaterer er vinduet der en kjent feil ligger på nettstedet ditt. Notatet minner også om at “bare den nyeste versjonen av WordPress støttes aktivt” (egen oversettelse), med sikkerhetsrettinger som ved behov tilbakeføres til eldre grener (for øyeblikket til og med 4.7).

#Hvordan WordPress sikkerhetsteam håndterer sårbarheter i kjernen

Ifølge wordpress.org/about/security består sikkerhetsteamet til WordPress av mer enn 50 betrodde eksperter, blant dem hovedutviklere og sikkerhetsforskere. Teamet utvikler og tester rettingene selv og publiserer dem i feilrettingsutgivelser. Siden beskriver også at teamet samarbeider med store webhoteller og sikkerhetsleverandører om utrullingen og om WAF-regler som demper angrep før alle har oppdatert.

Det gir to konsekvenser for driften. For kjernen kommer rettingen fra én koordinert kilde, og den automatiske bakgrunnsoppdateringen er leveringskanalen. Står den på, er det meste av jobben for kjernen gjort. For plugins og temaer er bildet et annet: sårbarheter meldes til utvikleren og til plugin- eller temateamet, og hvor raskt rettingen kommer avhenger av én vedlikeholder. Derfor ligger mesteparten av oppdateringsarbeidet ditt i plugin-listen, ikke i kjernen.

#Hvilke deler av WordPress oppdateres automatisk

Notatet for 7.1.3 sier at nettsteder som støtter automatiske bakgrunnsoppdateringer starter oppdateringen selv. Oppgraderingsdokumentasjonen beskriver konstanten: true slår på utviklings-, mindre og store utgivelser, false slår alle av og 'minor' tillater bare de mindre. Sjekk tre ting på hvert nettsted: at konstanten ikke står på false i wp-config.php etter en utvikler som ville fryse en versjon, at nettstedet ikke er et versjonskontroll-uttrekk som stille hopper av, og at hosten faktisk leverer oppdateringen. Kjør wp core version på serveren dagen etter en sikkerhetsutgivelse, så får du svar på det siste.

For plugins og temaer sier dokumentasjonen at bakgrunnsoppdateringer bare skjer i spesielle tilfeller, “slik det avgjøres av svaret fra WordPress.org-API-et, som styres av WordPress sitt sikkerhetsteam” (egen oversettelse). Siden WordPress 5.5 kan du slå automatiske oppdateringer av eller på for hvert plugin og tema i skjermbildene du allerede bruker. Å slå alt på er ikke en strategi. Slå det på for små plugins med god utgivelseshistorikk, og la nettbutikk, skjemaer og medlemskap gå via staging.

#Hva skjer når en plugin stenges i katalogen

Ifølge veiledningen til plugin-katalogen meldes sårbarheter til plugin-teamet, som forsøker å nå utvikleren, og “de fleste plugins stenges for å hindre nye nedlastinger til problemet er løst” (egen oversettelse). Stengingen hindrer nye installasjoner. Den rekker ikke inn på nettstedet ditt, så et stengt plugin du installerte i fjor kjører fortsatt. Sammenlign aktive plugins med det katalogen fortsatt lister én gang i kvartalet, og bytt ut dem som er stengt eller forlatt. Det samme gjelder forsyningskjedeangrep, der et plugin du stoler på bytter eier og neste oppdatering er angrepet. Les også notatet om oppdateringsforsinkelsen hos WordPress.org.

#Hvordan oppdatere WordPress trygt på et ekte nettsted

Om en oppdatering er verdt risikoen avhenger av om du kan angre den. Rutinen som fungerer:

1. Ta en sikkerhetskopi du har gjenopprettet minst én gang. En sikkerhetskopi du aldri har testet er et håp.
2. Kjør oppdateringene på staging og gå gjennom stiene som gir inntekt eller samler inn data: kasse, skjemaer, innlogging, søk.
3. Oppdater produksjon i et vindu med lav trafikk og gå gjennom de samme stiene på nytt.
4. Se i PHP-feilloggen etter nye varsler, for et plugin kan svikte i det stille.
5. Kjenn tilbakerullingen før du starter. Hvis det går galt, viser veiledningen om å gjenopprette en tidligere versjon etter en mislykket oppdatering hvordan.

To WP-CLI-kommandoer gjør det meste av oversikten: wp plugin list --update=available viser hva som venter, og wp core check-update viser kjernens status. Sikkerhetsutgivelser tas først, resten følger ukentlig. En vedlikeholdsavtale er i hovedsak at noen gjør dette etter en fast plan og skriver det ned.

For norske team som bruker hosting med ett-klikks staging (mange EU-hostere tilbyr det) er terskelen lav. For egne VPS-er i Hetzner, DigitalOcean eller en norsk leverandør: bruk wp-cli eller en deploy-pipeline, og hold staging bak HTTP-auth eller VPN. En åpen staging-klone med produksjonsdata er i seg selv et personvernproblem.

Unngå også «staging» som bare er en undermappe på samme database. Delte tabeller og delte cookies skaper falsk trygghet. Ekte staging har egen database og egen URL.

#Hvordan WordPress ruller tilbake en mislykket plugin-oppdatering

Siden WordPress 6.3 har kjernen en innebygd tilbakerulling for manuelle oppdateringer av plugins og temaer. Ifølge utviklernotatet for 6.3 flyttes den installerte versjonen til wp-content/upgrade-temp-backup/plugins/ eller wp-content/upgrade-temp-backup/themes/ før oppdateringen starter. Feiler installasjonen, flyttes den tilbake. Lykkes den, slettes kopien. Site Health fikk samtidig to kontroller: om backupmappen er skrivbar, og om det er nok diskplass til å oppdatere trygt.

Begrensningen står i samme notat. «Feil» betyr at selve installasjonen returnerer en feil, for eksempel en tom nedlastingspakke eller filer som ikke kan flyttes. En oppdatering som installeres fint, men som knekker utsjekken, regnes som vellykket, og den gamle versjonen er da allerede slettet.

WordPress 6.6 gikk videre for automatiske plugin-oppdateringer. Forslaget som ble slått sammen beskriver flyten: nettstedet står i vedlikeholdsmodus mens automatiske oppdateringer kjører, WordPress sender en loopback-forespørsel til forsiden for å se etter fatale PHP-feil, og hvis den returnerer en feil, gjenopprettes den forrige versjonen av pluginet og adressen i admin_email får en e-post om det. Testinnlegget for 6.6 bekrefter at dette er standard fra 6.6.

Mekanismen fanger det åpenbare: en fatal feil som tar ned forsiden. Den fanger ikke en feil som bare viser seg i kassen, i et skjema eller i en cron-jobb, og forslaget nevner bare plugins, ikke temaer. Innebygd tilbakerulling erstatter derfor verken staging eller en backup du har gjenopprettet minst én gang.

#Hvordan styre automatiske oppdateringer i kode

Oppgraderingsdokumentasjonen beskriver flere brytere enn konstanten WP_AUTO_UPDATE_CORE. De er nyttige når ett team drifter mange nettsteder etter samme regler:

• AUTOMATIC_UPDATER_DISABLED i wp-config.php slår av alle automatiske oppdateringer, kjerne og alt annet. Dokumentasjonen fraråder det sterkt. Finner du konstanten på et nettsted, finn ut hvem som satte den og hvorfor.
• Filtrene auto_update_plugin og auto_update_theme får elementet som skal oppdateres, så du kan sjekke $item->slug og slå på automatikk bare for utvalgte plugins. Returnerer filteret false for alt, blokkeres også sikkerhetsoppdateringene WordPress.org ellers sender ut.
• auto_update_translation styrer oversettelsesfilene, som oppdateres automatisk som standard.
• auto_core_update_send_email styrer e-postene om kjerneoppdateringer. Filteret får typen (success, fail eller critical), så du kan dempe suksessvarsler og beholde varslene om feil.
• automatic_updates_is_vcs_checkout avgjør om en .git-, .hg- eller .svn-mappe i WordPress-katalogen eller en overordnet mappe skal stoppe automatiske oppdateringer.

Dokumentasjonen sier at filtrene skal ligge i et must-use plugin og ikke i wp-config.php, fordi WordPress ikke er ferdig lastet der og det kan gi konflikter, blant annet med WP-CLI. Et lite mu-plugin i versjonskontroll gjør i tillegg reglene synlige for neste utvikler som overtar nettstedet.

#Hvordan beskytte egne plugins mot feil oppdatering

Et skreddersydd plugin med samme slug som et plugin i WordPress.org-katalogen risikerte tidligere å bli overskrevet når katalogversjonen fikk en oppdatering. Utviklernotatet for WordPress 5.8 innførte plugin-headeren Update URI mot dette: peker verdien til noe annet enn WordPress.org, prøver ikke WordPress å oppdatere pluginet derfra. Update URI: false stopper oppdateringer helt, og filteret update_plugins_{$hostname} lar en egen oppdateringstjeneste levere nye versjoner. Legg headeren inn i alle interne plugins. Det tar ett minutt og fjerner en hel klasse uhell der fremmed kode havner på produksjon via oppdateringsknappen.

#Hvordan herde WordPress mens patchen venter

Ingen rutine er øyeblikkelig. Herdingen avgjør hva en angriper får til i mellomtiden.

• Ingen filredigering. define('DISALLOW_FILE_EDIT', true); i wp-config.php fjerner tema- og plugin-redigereren fra dashbordet, så en stjålet administratorøkt ikke kan skrive PHP fra nettleseren.
• Ingen PHP i opplastinger. Blokker kjøring i wp-content/uploads på webserveren. En opplastingsfeil ender da som en lagret fil, ikke som et skall.
• Stramme rettigheter. wp-config.php lesbar bare for nettstedets bruker, og ingen mapper med skrivetilgang for alle.
• Få administratorer. Flere av rettingene i 7.1.x avhenger av en rolle. Færre privilegerte kontoer gir færre utnyttbare veier. Gi redaktører Redaktør-rollen, ikke Administrator.
• Sterk innlogging. Passkeys eller 2FA på alle kontoer som kan publisere eller installere.
• XML-RPC av hvis ingen app eller Jetpack-tilkobling trenger det: add_filter('xmlrpc_enabled', '__return_false');.

Hele listen, med servereksempler, står i guiden til herding.

#Hva beskytter en WAF mot i WordPress

Web Application Firewalls (Cloudflare, Sucuri, hosterens egen WAF, eller plugin-basert virtuell patching fra aktører som Patchstack) er nyttige. De er ikke en erstatning for oppdateringer.

En WAF er god på:

• Rate limiting mot brute force på innlogging
• Blokkering av kjente exploit-signaturer og skadelige user-agents
• Virtuell patching: midlertidig blokkering av et kjent angrepsmønster mens du tester oppdateringen i staging
• Geo- eller ASN-filtrering når du ser åpenbare skannemønstre

En WAF er svak eller blind på:

• Logikkfeil i eget custom-plugin («hvis ?token= matcher, gi admin»)
• Kompromitterte legitime admin-økter (stjålet cookie etter phishing)
• Feil filrettigheter som lar en opplastet PHP-fil kjøre
• Bakdører som allerede ligger i wp-content/uploads fra et tidligere brudd
• Supply-chain-problemer der et oppdatert plugin selv er kompromittert (sjeldnere, men dokumentert i økosystemet)

Derfor er rekkefølgen alltid: oppdater og herd først, bruk WAF som ekstra lag og som buffer i patch-vinduet. Å «sette på Cloudflare» og late som jobben er ferdig, er en vanlig feil, spesielt når DNS peker riktig, men opprinnelsesserveren fortsatt åpner wp-admin direkte på IP.

#Hvorfor PHP-versjonen hører med i oppdateringsrutinen

WordPress-oppdateringer hjelper lite hvis PHP under dem ikke lenger får sikkerhetsrettinger. Kravsiden på wordpress.org anbefaler PHP 8.3 eller nyere, MySQL 8.0 eller nyere eller MariaDB 10.11 eller nyere, og HTTPS. Den sier at WordPress også kjører på PHP 7.4 og MySQL 5.5.5, men at disse versjonene har nådd slutten av levetiden og kan utsette nettstedet for sårbarheter.

Oversikten på php.net viser per oktober 2026 at PHP 8.2 bare får sikkerhetsrettinger, og at de stopper 31. desember 2026. PHP 8.3 får sikkerhetsrettinger til 31. desember 2027, mens 8.4 og 8.5 fortsatt har aktiv støtte. Eldre grener enn 8.2 får ingen rettinger. Sjekk versjonen under Verktøy, Nettstedshelse, fanen Info, eller med php -v på serveren, og planlegg byttet i staging på samme måte som en større WordPress-oppdatering. Et gammelt plugin som ikke tåler en nyere PHP-versjon er et argument for å bytte ut pluginet, ikke for å bli værende på en PHP-gren uten rettinger.

#Hva Datatilsynet og GDPR forventer etter et brudd

Artikkel 32 i GDPR krever “egnede tekniske og organisatoriske tiltak” (egen oversettelse) for å beskytte personopplysninger. Artikkel 33 krever melding til tilsynsmyndigheten uten ugrunnet opphold og om mulig senest 72 timer etter at du ble kjent med bruddet, med mindre det neppe medfører risiko for de registrertes rettigheter og friheter. Brudd på pliktene i artikkel 25 til 39 faller i det lavere bøtenivået i artikkel 83 nr. 4: inntil 10 millioner euro eller 2 prosent av global årsomsetning, avhengig av hva som er høyest.

Datatilsynet skriver at den behandlingsansvarlige som hovedregel har plikt til å melde brudd på personopplysningssikkerheten til Datatilsynet, og at alle virksomheter må risikovurdere sikkerhetshendelser og avgjøre om de er et slikt brudd. Forordningen sier ikke “installer oppdateringer”. Men en nettbutikk som samler kundedata og lot et plugin med publisert retting stå i uker, får vanskelig for å forsvare det tiltaket. Ta vare på dokumentasjonen som viser det motsatte: datoer for oppdateringer, staging-testen, planen for tilbakerulling. Den samme dokumentasjonen hjelper i en revisjon av EU-samsvar.

#Hvordan oppdage et hacket WordPress-nettsted

SEO-spam er laget slik at eieren ikke merker det. Sidene vises til Googlebot og ikke til besøkende, så en ren forside beviser ingenting. Disse kontrollene gjør det:

• wp core verify-checksums og wp plugin verify-checksums --all sammenligner filene med de offisielle utgivelsene og peker ut endringer.
• Let etter PHP-filer som er nyere enn wp-config.php, og start med temamappen.
• wp user list --role=administrator skal bare vise folk du kjenner igjen.
• En filendring ingen i teamet kan forklare er en hendelse. Gå rett til inneslutning.

Vil du at kontrollene gjøres av noen som ikke eier nettstedet, dekker en sikkerhetsrevisjon av WordPress utdaterte komponenter, eksponerte brukere og serveroppsett i ett løp.

#Vanlige WordPress-sikkerhetsfeil i norske bedrifter

Flere mønstre går igjen hos norske SMB-er og byråkunder:

Betalings- og bookingstack uten eier. Vipps, Klarna, Stripe, Easy Digital Downloads, Bookly eller Amelia oppdateres «når det er tid». Betalingspluginet er akkurat der angripere leter, fordi utbyttet er direkte. Sett eier: én person som abonnerer på sikkerhetsnyheter for akkurat de slugene.

Produksjonsdata i staging uten vask. Kopier av kundelister, ordrehistorikk og medlemskap på en åpen staging-URL er et personvernproblem før noen i det hele tatt hacker deg. Masker eller begrens tilgang. Datatilsynet bryr seg om behandlingssikkerhet, ikke om du kalte miljøet «dev».

Byrå + kunde uten tydelig ansvar. Kunden tror byrået patcher. Byrået tror kunden klikker i wp-admin. Skriv det ned: hvem overvåker oppdateringer, hvem godkjenner staging-til-prod, hvem har 2FA på hostingpanelet. Uten den setningen blir patchen utsatt til etter Black Week eller julehandel - akkurat når du minst har tid til brannslukking.

«Sikkerhetsplugin» som erstatning for herding. Et plugin som skanner filer er nyttig som signal. Det erstatter ikke filrettigheter, oppdateringer, eller fjerning av install.php-tilgang etter installasjon. Følg sjekkpunktene i developer handbook herding før du kjøper enda en lisens.

E-post og SMTP-nøkler. Et kompromittert SMTP-plugin eller en lekket SendGrid/Mailgun-nøkkel brukes til phishing i firmanavnet ditt. Roter nøkler når folk slutter, og begrens API-scopes.

#Hva du bør sjekke på WordPress-nettstedet denne uken

Bekreft at 7.1.3 er installert på alle nettsteder. List plugins med ventende oppdateringer og sorter dem etter hva hvert enkelt har tilgang til. Fjern det som er forlatt. Tell administratorkontoene og kutt dem. Legg så neste gjennomgang i kalenderen, for neste sikkerhetsutgivelse venter ikke.