Säkerhetsversion WordPress 7.1.4: vad byråer bör göra i dag

Uppdatering, 5 november 2026: Wordfence räknar nu över 240 000 blockerade försök mot den här sårbarheten sedan 28 oktober, med en topp på över 74 000 den 30 oktober. CISA lade till CVE-2026-119977 i katalogen Known Exploited Vulnerabilities den 2 november. Wordfence kallar fortfarande en lyckad attack svår i praktiken, eftersom den bara fungerar under de sekunder en uppdatering körs. Deras råd är detsamma som vårt: uppdatera nu till 7.1.4 eller din grens backport, och blockera PHP-filer i wp-content/upgrade/ på webbservern innan du uppdaterar. Gratisanvändare av Wordfence får brandväggsregeln den 27 november. Källa: Wordfence, 5 november 2026.

Uppdatering, 31 oktober 2026: attackerna ökar. Wordfence rapporterar nu nästan 59 000 blockerade försök på 24 timmar mot de tillfälliga installationsfilerna i wp-content/upgrade/ (upp från 18 500 under de första 21 timmarna). Fortfarande inga bekräftade intrång. Om en kundwebbplats ännu inte kör 7.1.4 eller sin grens backport, uppdatera den i dag och stäng upgrade-mappen på servern; vänta inte till måndag.

WordPress 7.1.4 kom den 28 oktober 2026 som säkerhetsversion. Den åtgärdar 22 sårbarheter i 17 meddelanden, och samma åtgärder har förts tillbaka till varje stödd gren ner till 4.7.39. En av dem är ovanlig: en sårbarhet i själva kärnans uppdateringsprocess som inte kräver inloggning. Den är svår att utnyttja, men angripare började leta efter den inom ett dygn, och det är det enda problemet i den här versionen som en brandvägg i form av ett tillägg inte kan stoppa. Här är vad det betyder för kundwebbplatserna du underhåller, och vad du ska göra i dag.

Vad som åtgärdas

• Kodkörning utan inloggning under en uppdatering. Före 7.1.4 hade mappen som WordPress packar upp uppdateringar i, inuti wp-content/upgrade/, ett förutsägbart namn, och städningen tog bort den index.php som blockerar visning av mappens innehåll. En angripare som träffar de få sekunder en uppdatering körs, på en webbplats där mappen går att nå från webben, kunde köra kod. Patchstack bedömer attackens komplexitet som hög och kallar inte utnyttjande praktiskt. Eftersom den uppackade kopian inte laddar webbplatsens tillägg kan ett brandväggstillägg på PHP-nivå inte blockera den här förfrågan.
• Lagrad XSS från konton med rollen Medarbetare och uppåt, främst i Interactivity API (7 av de 17 meddelandena) och i flera kärnblock.
• Customizer: opublicerade ändringsuppsättningar kunde ses av besökare som inte är inloggade.

Vilka som berörs

Varje webbplats med en version under 7.1.4 eller under motsvarande backport (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 och så vidare, ner till 4.7.39). Webbplatser på 4.6 eller äldre får ingen åtgärd alls. XSS-problemen spelar störst roll på webbplatser där kunder, skribenter eller gästförfattare har konton med rollen Medarbetare eller högre.

Kontrollera en webbplats på två minuter

1. Version: gå i wp-admin till Adminpanel → Uppdateringar, eller kör wp core version. Allt under 7.1.4 (eller din grens backport) behöver uppdateras.
2. Upgrade-mappen: öppna https://example.com/wp-content/upgrade/ i ett privat fönster. En 403 eller 404 är vad du vill se. En fillista eller en tom 200-sida betyder att mappen går att nå från webben.
3. Konton: filtrera under Användare på Medarbetare, Författare och Redaktör. Ta bort de konton ingen använder.

Vad du gör nu

1. Uppdatera kärnan till 7.1.4 eller backporten för din gren. Små säkerhetsversioner installeras normalt av sig själva; kontrollera att det har skett, eftersom webbhotell och vissa tillägg stänger av automatiska kärnuppdateringar. Se först till att ha en färsk säkerhetskopia, och kontrollera sedan startsidan, ett formulär och kassan.
2. Blockera webbåtkomst till upgrade-mappen på webbservern, inte i ett tillägg. På Apache en .htaccess fil i wp-content/upgrade/ med Require all denied. På nginx location ^~ /wp-content/upgrade/ { deny all; }. WordPress skriver fortfarande till mappen via PHP, så uppdateringar fortsätter att fungera. På hanterad hosting där du inte kan ändra servern ber du ditt webbhotell att göra det.
3. Webbplatser på 4.6 eller äldre: planera nu flytten till en version som stöds. Det kommer ingen åtgärd för dem.

Angripare letar efter den här sårbarheten, men inga lyckade intrång har bekräftats, så en uppdaterad webbplats med stängd upgrade-mapp behöver varken återställning eller nya nycklar bara på grund av den här versionen. Ser du däremot okända filer i wp-content/upgrade/ eller nya administratörskonton, behandla det som ett intrång: återställ från en säkerhetskopia från innan filerna dök upp och byt sedan lösenord och salts. Vår rutin för en sårbarhetsdag har alla steg.

Så hjälper Verploy

Varje uppdatering kontrolleras. Riskabla uppdateringar testas först på en kopia. WordPress-kärnan räknas alltid som riskabel: den testas på en privat kopia av webbplatsen innan den publika webbplatsen ändras, och om en kontroll misslyckas efter publicering återställs webbplatsen automatiskt. Nattliga krypterade säkerhetskopior i EU ger dig en ren punkt att gå tillbaka till, och kända sårbarheter visas per webbplats med en länk till källan.

Källa: Patchstack, ”WordPress 7.1.4 Security Release”, 28 oktober 2026, patchstack.com. Varning om utnyttjande från Wordfence, 29 oktober 2026, enligt SecurityOnline; siffran för 24 timmar enligt CyberPress, 31 oktober 2026. Kontrollerat 31 oktober 2026.