WordPress 7.1.4: kritisk sikkerhetsoppdatering. Dette må du gjøre nå
WordPress 7.1.4 retter 22 sårbarheter, blant annet en svakhet i selve oppdateringsprosessen som kan gi fjernkjøring av kode. Her er hva oppdateringen fikser, hva du bør gjøre nå, og hvorfor det er den fjerde sikkerhetsoppdateringen på seks uker.
Onsdag 28. oktober 2026 kom WordPress 7.1.4. «Because this is a security release, it is recommended that you update your sites immediately», skriver WordPress. Med andre ord: oppdater nå.
Ifølge sikkerhetsselskapet Patchstack teller WordPress 22 sårbarheter i denne runden, fordelt på 17 sikkerhetsvarsler. Forrige sikkerhetsoppdatering, 7.1.3, hadde sju. Her er hva som er rettet, hva du bør gjøre, og hvorfor dette er blitt en fast rutine for alle med en WordPress-side.
Hva fikser WordPress 7.1.4?
Den mest alvorlige feilen sitter i selve oppdateringsprosessen. Mens WordPress oppdaterer seg, ligger en komplett kopi av WordPress i mappen wp-content/upgrade/ i noen sekunder. Patchstack beskriver at kopien ligger på en adresse som kan gjettes, og at den kan misbrukes til å kjøre kode på serveren, uten innlogging. Vinduet er svært kort, og angrepet regnes som vanskelig å få til i praksis. Men det åpner seg igjen hver gang siden oppdateres.
Resten er stort sett lagret XSS. Det betyr at noen med en brukerkonto på siden, som regel med rollen bidragsyter eller høyere, kan legge inn kode som kjøres når en redaktør eller administrator åpner innlegget. Feilene sitter blant annet i:
- blokker som Kategorier, Bilde, Spilleliste og kommentarnavigasjon
- Interactivity API, som brukes av nyere blokker og temaer
- tilpasseren (Customizer), der upubliserte endringer også kunne leses av hvem som helst
- skjermen for sletting av personopplysninger og brukerlistene på multisite
I tillegg er det rettet at notater på innlegg kunne leses av brukere uten tilgang til innlegget, og rotsertifikatene som følger med WordPress er oppdatert.
Hvor alvorlig er det?
For en typisk bedriftsside med én eller to administratorer er de fleste av disse hullene vanskelige å utnytte, fordi angriperen først må ha en brukerkonto. Det endrer seg hvis siden lar folk registrere seg, har mange skribenter, eller har gamle kontoer for folk som ikke lenger jobber der.
Oppdatert 6. november: Hullet i oppdateringsprosessen (CVE-2026-119977) angripes nå. Wordfence skriver at angriperne begynte å prøve seg samme dag som 7.1.4 kom, og har stoppet over 240 000 forsøk. Les hva du bør sjekke i artikkelen om angrepene.
Da 7.1.4 kom, skrev verken WordPress eller Patchstack at hullene var utnyttet. Men en sikkerhetsoppdatering er også en oppskrift: så snart den er ute, kan alle se hva som er endret. NSM, som nettopp hevet det nasjonale cyberrisikonivået til «høyt», sier at virksomheter nå har timer, ikke dager, på å lukke kjente sårbarheter.
Fire sikkerhetsoppdateringer på seks uker
7.1.4 er ikke et enkeltstående tilfelle. WordPress 7.1 kom 19. august, og siden har det kommet fire sikkerhetsoppdateringer:
| Versjon | Dato | Sikkerhetsfikser |
|---|---|---|
| 7.1.1 | 17. september | 11 |
| 7.1.2 | 22. september | 1 (kritisk, uten innlogging) |
| 7.1.3 | 6. oktober | 7 |
| 7.1.4 | 28. oktober | 22 |
Tallene for 7.1.1 til 7.1.3 er hentet fra WordPress sine versjonssider. Tallet for 7.1.4 er WordPress sin egen telling slik Patchstack gjengir den.
En del av forklaringen er at KI har gjort det mye raskere å lete etter feil. I 7.1.3 og 7.1.4 står Anthropic oppført som den som rapporterte flere av hullene, og en av feilene i 7.1.3 ble funnet av Trail of Bits sammen med OpenAI. Det er bra at hullene blir funnet og tettet. Men det betyr også at den som eier en WordPress-side, må regne med en jevn strøm av oppdateringer framover. Det samme skjer med PHP, språket WordPress er skrevet i: les artikkelen om PHP2Shell.
Dette må du gjøre nå
- Oppdater til 7.1.4. Gå til Kontrollpanel og Oppdateringer, og klikk «Oppdater nå». Står du på en eldre gren, skal du på den nyeste versjonen i grenen, for eksempel 7.0.8, 6.9.11 eller 6.8.12.
- Sjekk at det faktisk skjedde. Automatiske oppdateringer kan være slått av hos webhotellet eller av en utvidelse. Se versjonsnummeret med egne øyne.
- Stopp tilgangen til
wp-content/upgrade/. Patchstack anbefaler å blokkere mappen på webserveren og sjekke at innholdet ikke kan listes ut. En brannmur som kjører inne i WordPress, kan ikke stoppe akkurat dette, skriver Patchstack. Spør webhotellet hvis du ikke vet hvordan. - Rydd i brukerne. Nesten alle hullene krever en konto med rollen bidragsyter eller høyere. Slett kontoer som ikke brukes, og gi folk den laveste rollen de klarer seg med.
- Oppdater utvidelser og tema også. WordPress-kjernen er bare én del. Utvidelser og tema får egne sikkerhetsoppdateringer, og de må inn like raskt.
- Kjører du WordPress 4.6 eller eldre, får du ingen fiks. Da er det på tide å bytte, ikke oppdatere.
Er du usikker på hva siden din kjører, viser den gratis nettsjekken blant annet om siden har en utdatert WordPress-versjon.
Eller: slipp hele jobben
Alt over må gjentas neste gang det kommer en oppdatering, og med dagens tempo blir det om noen uker. For mange bedrifter er spørsmålet derfor ikke hvordan de oppdaterer WordPress, men om de trenger WordPress i det hele tatt.
En statisk nettside bygget med Astro ligger ferdig som filer. Det kjører ikke PHP, det finnes ingen database og ingen innlogging til et publiseringsverktøy på selve nettsiden. Ingen av hullene i 7.1.4 har noe å angripe der. Domene, e-post og kontoer hos leverandørene må fortsatt sikres, men listen over ting som må oppdateres raskt, blir kort. Jeg har skrevet mer om forskjellen på plattformene og om hva drift av en nettside innebærer.
Med Website-vaktmester bygger og drifter jeg siden for dere, med hosting inkludert, og publiserer det dere sender meg. Det koster fra 2 450 kr/mnd eks. mva. ved årsbetaling, med 30 dagers oppsigelse. Trenger dere en ny side først, starter vi med en ny nettside.
