WordPress 7.1.3 lukker syv sikkerhedshuller – opdater nu

WordPress 7.1.3 udkom den 6. oktober 2026 og lukker syv sikkerhedshuller i selve WordPress-kernen, samtidig med at fire almindelige fejl bliver rettet. Det er den tredje sikkerhedsudgivelse på 19 dage (vores optælling fra 7.1.1 den 17. september), og det er forståeligt, hvis man som dansk sideejer har mistet overblikket over, hvilket tal der egentlig skal stå i bunden af kontrolpanelet.

Det korte svar: Du skal være på 7.1.3 — eller på den nyeste udgave af den ældre gren, din side kører på. Det lidt længere svar er, at denne opdatering er en af de rolige. Der er ikke tildelt CVE-numre til de syv fejl, og hverken WordPress eller sikkerhedsfirmaet Patchstack melder om angreb, der udnytter dem. Det, der derimod haster lige nu, er et hul i et plugin ved navn Bricksforge. Det har fået sit eget afsnit længere nede.

Tre udgivelser på 19 dage: her er forskellen

De tre opdateringer handler om tre forskellige ting, og det er nyttigt at holde dem adskilt.

7.1.1 er den, vi beskrev i artiklen om comment2shell-hullet, hvor en anonym kommentar kan kapre administratorens session.

7.1.2 har vi ikke tidligere skrevet om, og den var den alvorligste af de tre. Den lukkede en enkelt fejl, som WordPress selv betegner som kritisk: En besøgende uden login kunne under bestemte betingelser få WordPress til at indlæse en PHP-fil uden for det aktive temas mapper. Hvis både serveropsætningen og temaet opfyldte betingelserne, kunne det ifølge WordPress' udgivelsesnote ende med, at angriberen kunne køre sin egen kode på serveren. Fejlen blev indberettet af Robert Ressl.

7.1.3 er den aktuelle. Alle rettelser fra de to foregående er med, så du skal ikke installere dem i rækkefølge. Én opdatering til den nyeste version dækker det hele.

Hvilken version skal din side stå på?

WordPress vedligeholder kun den nyeste version aktivt, men sikkerhedsrettelser bliver som en service også lagt ud til ældre grene. Den 6. oktober kom der derfor nye udgaver til flere grene på én gang:

Tallene for 7.1 og 7.0 står på WordPress' officielle udgivelsesliste. 6.9.10, 6.8.11 og 6.7.10 har vi kontrolleret i WordPress' egen versionsdokumentation, hvor de alle er dateret 6. oktober og opregner de samme syv rettelser. For endnu ældre grene skriver WordPress, at rettelserne føres tilbage til 4.7, efterhånden som de er klar. Patchstack noterede på udgivelsesdagen, at grenene 4.7 til 6.5 endnu ikke var opdateret. Kører du noget så gammelt, er det reelle råd at komme op på en nyere gren.

Sådan tjekker du: Log ind i kontrolpanelet, og gå til Kontrolpanel → Opdateringer. Øverst står den version, siden kører. Sider med automatiske baggrundsopdateringer slået til har efter alt at dømme allerede opdateret sig selv, men kig efter alligevel.

De syv huller i 7.1.3

Her er listen, sådan som WordPress selv beskriver den, sammen med den vurdering af forudsætningerne, Patchstack har lavet:

To ting er værd at bemærke.

Den første er, at kun én af de syv fejl kan udnyttes helt uden forudsætninger, nemlig lækagen af kommentarer på private og upublicerede indlæg. Det er en fortrolighedsfejl og ikke en vej til at overtage siden, men den er relevant, hvis du bruger private indlæg til internt indhold med kommentarer.

Den anden er, at kommentarfejlen her ikke er den samme som comment2shell fra 7.1.1. Den nye rammer ifølge Patchstack version 7.1.0 til 7.1.2 og kræver, at en moderator klikker på et link i en ventende kommentar. De to fejl ligner hinanden i overskriften, men har hver sin rettelse, og du har brug for begge.

Bemærk også kolonnen til højre. Fire af de syv fejl er krediteret til Anthropic og til Trail of Bits i samarbejde med OpenAI. WordPress skriver ikke mere om metoden end det, og vi vil ikke gætte på den.

Patchstacks samlede vurdering er afdæmpet: Opdater, så snart du kan, men det er ifølge firmaets gennemgang af udgivelsen ikke en situation, hvor man skal slippe alt, hvad man har i hænderne.

Opdateringen rydder ikke gemte indlejringer

Der er én detalje, opdateringen ikke klarer for dig. Når du indsætter et link til for eksempel Imgur eller YouTube i et indlæg, henter WordPress indlejringskoden én gang og gemmer den. Patchstack gør opmærksom på, at 7.1.3 retter selve fejlen, men ikke fjerner indlejringer, der allerede er gemt. En skadelig Imgur-indlejring, som blev lagt ind før opdateringen, bliver altså ved med at blive vist.

For de fleste er det ikke et problem. Fejlen kræver en bruger med mindst rollen Bidragyder, så hvis du er den eneste, der skriver på siden, har ingen haft mulighed for at lægge noget ind. Har du derimod gæsteskribenter, frivillige eller tidligere ansatte med skriveadgang, er det værd at rydde op.

Patchstack skriver kun, at man skal rydde sidens cache efter opdateringen, og giver ingen opskrift. Den følgende fremgangsmåde er derfor vores, baseret på WordPress' egen dokumentation:

• Hvor ligger det? Dels som felter på det enkelte indlæg, hvis navne begynder med _oembed_, dels som skjulte indlæg af typen oembed_cache.
• Med kommandolinjeværktøjet WP-CLI: Kommandoen wp embed cache clear 123 sletter de gemte indlejringer for indlægget med id 123. Den skal køres for hvert berørt indlæg. De skjulte oembed_cache-indlæg kan vises med wp post list --post_type=oembed_cache.
• Uden kommandolinje: Der findes ingen knap til det i kontrolpanelet. Bed dit webhotel eller din udvikler om at rydde oEmbed-cachen, og tag en backup først.

Tøm bagefter også den almindelige sidecache, hvis du bruger et cache-plugin eller et CDN, så besøgende ikke får serveret en gammel kopi.

Det, der haster: Bricksforge-hullet udnyttes nu

Mens kerneopdateringen kan klares i ro og mag, er der et plugin, hvor det forholder sig omvendt. Bricksforge, en betalt udvidelse til sidebyggeren Bricks, har et hul med nummeret CVE-2026-85097, som ifølge Patchstack bliver udnyttet i aktive angreb.

Fejlen ligger i pluginets formularfunktion, Pro Forms. Ifølge Patchstacks analyse kontrollerer Bricksforge filtypen, når en fil bliver uploadet, men stoler bagefter på de oplysninger, afsenderen selv angiver ved indsendelsen af formularen. En angriber kan derfor uploade en fil, der ligner et billede, og få den gemt med en PHP-endelse. Patchstack har registreret forsøg fra 63 forskellige IP-adresser og vurderer, at der er tale om automatiseret udnyttelse.

Om versionsnumrene er kilderne ikke helt enige. Patchstack nævner 3.1.8.10 som den rettede version. Producentens egen offentlige ændringslog viser i stedet en version 4.0.1 fra den 8. oktober med teksten, at et sikkerhedsproblem i Pro Forms' filupload er rettet, og at alle sider med Pro Forms er berørt, også hvis formularerne ikke har uploadfelter. Ændringsloggen nævner ikke CVE-nummeret. Det praktiske råd er derfor: Kører du 3.x, skal du op på mindst 3.1.8.10, og kører du 4.0.0, skal du op på 4.0.1.

Opdateringen fjerner ikke en fil, der allerede er lagt ind. Har din side kørt en sårbar version siden den 7. oktober, bør du selv eller dit webhotel se efter følgende:

• PHP-filer i mappen /wp-content/uploads/bricksforge/tmp/. Her skal der kun ligge midlertidige uploads.
• Filer med navne, der begynder med login_admin_ og ender på .php, i /wp-content/uploads/2026/10/.
• Kald i serverloggen til /wp-json/bricksforge/v1/form_submit, som indeholder parameteren temporaryFileUploads.
• Et kald til bricksforge_regenerate_nonce efterfulgt af en upload og en formularindsendelse.

Finder du noget af det, skal siden behandles som kompromitteret. Det samme mønster så vi i sidste uge med Ninja Forms-hullet, hvor opdateringen heller ikke fjernede bagdøren, og tidligere i angrebene mod Elementor Pro og Super Forms. En mere genstridig variant er beskrevet i artiklen om den bagdør, der genskaber sig selv gennem wpForo.

Konklusion

For langt de fleste danske sideejere er opgaven overskuelig: Tjek, at siden står på 7.1.3 eller den nyeste udgave af din gren, og lad automatiske opdateringer være slået til. Har du flere skribenter med adgang, så få ryddet de gemte indlejringer. Bruger du Bricksforge, er det den opgave, der skal løses først, og den slutter ikke med opdateringen.

Det er uvist, om 7.1.3 bliver den sidste sikkerhedsudgivelse i denne omgang. WordPress har ikke annonceret en ny, og tre udgivelser på under tre uger er tæt. Krediteringerne viser, at flere sikkerhedshold end tidligere gennemgår kernen, og de syv fejl i 7.1.3 er rettet, uden at der er meldt om angreb. Sådan var det ikke med wp2shell-kæden tidligere i år, hvor angrebskode var i omløb kort efter offentliggørelsen. Den forskel er værd at huske, næste gang kontrolpanelet beder om en opdatering.