Sikkerhedsudgivelse WordPress 7.1.4: hvad bureauer bør gøre i dag

Opdatering, 5. november 2026: Wordfence tæller nu over 240.000 blokerede forsøg mod denne fejl siden 28. oktober, med en top på over 74.000 den 30. oktober. CISA føjede CVE-2026-119977 til sit katalog Known Exploited Vulnerabilities den 2. november. Wordfence kalder stadig et vellykket angreb svært i praksis, fordi det kun virker i de sekunder, en opdatering kører. Deres råd er det samme som vores: opdater nu til 7.1.4 eller din grens backport, og bloker PHP-filer i wp-content/upgrade/ på webserveren, før du opdaterer. Gratisbrugere af Wordfence får firewallreglen den 27. november. Kilde: Wordfence, 5. november 2026.

Opdatering, 31. oktober 2026: angrebene vokser. Wordfence melder nu om næsten 59.000 blokerede forsøg på 24 timer mod de midlertidige installationsfiler i wp-content/upgrade/ (op fra 18.500 i de første 21 timer). Stadig ingen bekræftede indbrud. Er et kundesite endnu ikke på 7.1.4 eller sin grens backport, så opdater det i dag og luk upgrade-mappen på serveren; vent ikke til mandag.

WordPress 7.1.4 udkom den 28. oktober 2026 som sikkerhedsudgivelse. Den retter 22 sårbarheder fordelt på 17 meddelelser, og de samme rettelser er ført tilbage til hver understøttet gren ned til 4.7.39. Én af dem er usædvanlig: en fejl i selve kernens opdateringsproces, der ikke kræver login. Den er svær at udnytte, men angribere begyndte at lede efter den inden for et døgn, og det er det eneste problem i denne udgivelse, som en plugin-firewall ikke kan stoppe. Her er, hvad det betyder for de kundesites, du vedligeholder, og hvad du skal gøre i dag.

Hvad der er rettet

• Kodeudførelse uden login under en opdatering. Før 7.1.4 havde den mappe, WordPress pakker opdateringer ud i, inde i wp-content/upgrade/, et forudsigeligt navn, og oprydningen fjernede den index.php , der blokerer visning af mappens indhold. En angriber, der rammer de få sekunder, mens en opdatering kører, på et site hvor mappen kan nås fra nettet, kunne køre kode. Patchstack vurderer angrebets kompleksitet som høj og kalder ikke udnyttelse praktisk. Fordi den udpakkede kopi ikke indlæser dit sites plugins, kan et firewall-plugin på PHP-niveau ikke blokere denne forespørgsel.
• Lagret XSS fra konti med rollen Bidragyder og op, mest i Interactivity API (7 af de 17 meddelelser) og i flere kerneblokke.
• Customizer: upublicerede ændringssæt kunne ses af besøgende, der ikke er logget ind.

Hvem er ramt

Ethvert site på en version under 7.1.4 eller under den tilsvarende backport (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 og så videre, ned til 4.7.39). Sites på 4.6 eller ældre får slet ingen rettelse. XSS-problemerne betyder mest på sites, hvor kunder, skribenter eller gæsteforfattere har konti med rollen Bidragyder eller højere.

Tjek et site på to minutter

1. Version: gå i wp-admin til Kontrolpanel → Opdateringer, eller kør wp core version. Alt under 7.1.4 (eller din grens backport) skal opdateres.
2. Upgrade-mappe: åbn https://example.com/wp-content/upgrade/ i et privat vindue. En 403 eller 404 er det, du vil se. En filliste eller en tom 200-side betyder, at mappen kan nås fra nettet.
3. Konti: filtrér under Brugere på Bidragyder, Forfatter og Redaktør. Fjern dem, ingen bruger.

Hvad du gør nu

1. Opdater kernen til 7.1.4 eller backporten for din gren. Små sikkerhedsudgivelser installerer normalt sig selv; tjek, at det er sket, for hosts og nogle plugins slår automatiske kerneopdateringer fra. Sørg først for en frisk backup, og tjek bagefter forsiden, en formular og checkout.
2. Bloker webadgang til upgrade-mappen på webserveren, ikke i et plugin. På Apache en .htaccess fil i wp-content/upgrade/ med Require all denied. På nginx location ^~ /wp-content/upgrade/ { deny all; }. WordPress skriver stadig til mappen via PHP, så opdateringer virker fortsat. På managed hosting, hvor du ikke kan ændre serveren, så bed din host om at gøre det.
3. Sites på 4.6 eller ældre: planlæg nu flytningen til en understøttet version. Der kommer ingen rettelse til dem.

Angribere leder efter denne fejl, men ingen vellykkede indbrud er bekræftet, så et opdateret site med lukket upgrade-mappe behøver hverken gendannelse eller nye nøgler alene på grund af denne udgivelse. Ser du derimod ukendte filer i wp-content/upgrade/ eller nye administratorkonti, så behandl det som et kompromis: gendan fra en backup fra før filerne dukkede op, og skift derefter adgangskoder og salts. Vores rutine til en sårbarhedsdag har alle trinene.

Sådan hjælper Verploy

Hver opdatering kontrolleres. Risikable opdateringer testes først på en kopi. WordPress-kernen tæller altid som risikabel: den testes på en privat kopi af sitet, før live-sitet ændres, og fejler et tjek efter livegang, rulles sitet automatisk tilbage. Natlige krypterede backups i EU giver dig et rent punkt at vende tilbage til, og kendte sårbarheder vises pr. site med et link til kilden.

Kilde: Patchstack, “WordPress 7.1.4 Security Release”, 28. oktober 2026, patchstack.com. Advarsel om udnyttelse fra Wordfence, 29. oktober 2026, som rapporteret af SecurityOnline; tal for 24 timer som rapporteret af CyberPress, 31. oktober 2026. Tjekket 31. oktober 2026.