WordPress gennemtvang en nødopdatering. Blev alle websites opdateret?

Af Greg Nowak. Senest opdateret 2026-07-18.

WordPress 7.0.2 blev udgivet den 17. juli 2026 for at rette ét kritisk sikkerhedsproblem og ét med høj alvorlighedsgrad. WordPress anbefalede, at opdateringen blev installeret med det samme, og aktiverede på grund af problemernes alvor tvungne opdateringer via systemet til automatiske opdateringer på berørte websites.

Det bør hurtigt beskytte en stor del af de samlede WordPress-installationer. Det beviser ikke, at alle de websites, du har ansvar for, er blevet opdateret.

I udgivelsesmeddelelsen står der, at den automatiske behandling begynder på websites, som understøtter baggrundsopdateringer. Den betingelse er vigtig. Bureauer, websiteejere og tekniske teams har stadig brug for dokumentation fra hver enkelt installation, især når de administrerer en blanding af produktionssites, stagingmiljøer og gamle projekter med uklare ejerforhold.

Det retter nødopdateringen

Det kritiske problem er en angrebskæde, der omfatter to sårbarheder. CVE-2026-60137 vedrører utilstrækkelig rensning af parameteren author__not_in i WP_Query. SQL injection kan blive mulig, når et plugin eller tema sender input, der ikke er tillid til, til denne parameter.

CVE-2026-63030 er et problem med route confusion i REST API'ets batch-endpoint. Kombineret med SQL injection-sårbarheden kan det gøre det muligt for en angriber at gå fra SQL injection til remote code execution. WordPress' sikkerhedsmeddelelse klassificerer angrebskæden som kritisk og anbefaler øjeblikkelig opdatering.

Den berørte version er afgørende. WordPress 6.8 er sårbar over for SQL injection-problemet, men ikke over for den kritiske route confusion-kæde. WordPress 6.9 og 7.0 er berørt af begge dele. En post i et regneark, hvor der blot står »gammel WordPress«, er derfor ikke nok til at vælge den rette opdatering eller vurdere eksponeringen.

Installeret gren	Rapporteret eksponering	Version, der skal bekræftes	Nødvendig handling
Tidligere end 6.8	Ikke berørt af disse to problemer	Registrér den præcise version	Håndtér dens øvrige livscyklus separat; markér den ikke som berørt af denne udgivelse
6.8.x før 6.8.6	CVE-2026-60137	6.8.6	Opdatér og verificér
6.9.0–6.9.4	Begge sårbarheder	6.9.5	Opdatér straks, verificér og vurder eksponeringen
7.0.0–7.0.1	Begge sårbarheder	7.0.2	Opdatér straks, verificér og vurder eksponeringen
7.1 beta før beta2	Begge sårbarheder	7.1 beta2	Opdatér testinstallationen, og bekræft, at den ikke håndterer produktionstrafik

En praktisk verifikationsmatrix baseret på de berørte grene og backports, der er angivet i WordPress-udgivelsen og sårbarhedsregistrene.

Tvungen er ikke det samme som verificeret

WordPress' udgivelsesmeddelelse bekræfter, at tvungne opdateringer blev aktiveret for de berørte versioner. Det fremgår også tydeligt, at den automatiske behandling gælder for websites, der kan foretage baggrundsopdateringer.

Det driftsmæssige spørgsmål er mere afgrænset og mere nyttigt: Hvilke installationer nåede faktisk frem til den korrekte rettede version?

Det kan ikke besvares ved kun at kontrollere virksomhedens primære website. En WordPress-portefølje kan omfatte kampagnesites, regionale installationer, staging- og udviklingskopier, rester efter migreringer eller websites, der er faldet uden for den normale dashboardproces. Nogle kan ligge på en hostingkonto, som ingen kontrollerer regelmæssigt. Omfanget omfatter alle tilgængelige installationer, som organisationen fortsat har ansvar for.

Et brugbart websiteregister bør indeholde hostname, miljø, ejer, hostingplacering, installeret WordPress-version, forventet rettet version, opdateringsresultat, verifikationstidspunkt og den person, der håndterer eventuel opfølgning. Bevar »automatiske opdateringer aktiveret« og »rettet version observeret« som separate felter. De beskriver to forskellige ting.

En verifikationsproces, du kan stå inde for

1. Find hele porteføljen

Begynd med de kendte produktions- og stagingwebsites. Afstem listen med eksisterende hostingkonti, domæneregistre, dokumentation for deployments og vedligeholdelsesaftaler. Hvis ejerforholdet er uklart, skal det registreres udtrykkeligt. Behold websitet i køen, indtil nogen påtager sig ansvaret, lukker det eller bekræfter, at det ligger uden for opgavens omfang.

2. Aflæs den installerede version

Registrér den observerede kerneversion i hvert miljø, og sammenlign den med den rettede udgivelse for den pågældende gren. I denne hændelse er 6.8.6, 6.9.5 og 7.0.2 separate sikkerhedsbackports, ikke indbyrdes udskiftelige betegnelser.

WordPress' sikkerhedsmeddelelse angiver version 6.9.0 til og med 6.9.4 samt 7.0.0 til og med 7.0.1 som berørt af den kritiske angrebskæde. NVD-registreringen for CVE-2026-60137 omfatter også sårbare 6.8.x-udgivelser før 6.8.6.

3. Opdatér alt, der stadig er eksponeret

Hvis en berørt version stadig er installeret, skal du ikke vente på endnu en automatisk opdateringscyklus. Installér den relevante understøttede opdatering, bekræft, at kommandoen eller handlingen i dashboardet gennemføres, og aflæs derefter den installerede version igen. Det er denne observerede tilstand efter opdateringen, der er værd at gemme som dokumentation.

4. Kontrollér WordPress' kernefiler

Når versionen er korrekt, skal du køre wp core verify-checksums. WP-CLI downloader de officielle checksums for den aktuelle WordPress-version og sammenligner dem med de installerede filer. Kommandoen kører, før WordPress indlæses, så verifikationen er mindre afhængig af selve applikationen.

Locale og version skal svare til installationen. WP-CLI stiller --locale og --version til rådighed til dette. --include-root kan markere elementer i rodmappen, der ikke tilhører WordPress, mens --format=json gør resultaterne nemmere at indsamle på tværs af flere websites.

Et fejlet eller uventet checksum er et fund, der skal undersøges. Et rent resultat er nyttigt, men begrænset: Det bekræfter, at de kontrollerede kernefiler svarer til de officielle checksums for den pågældende version. Det frikender ikke konti, logs, plugins, temaer, konfiguration eller forretningsfunktionalitet.

5. Test det, websitet er sat i verden for

Afslut med en kort funktionstest. Den præcise liste afhænger af websitet, men kan omfatte levering af sider, autentificering, formularer, søgning, checkout, publicering, integrationer og planlagte opgaver. Registrér, hvad der blev testet, og om opdateringen medførte behov for korrigerende arbejde eller rollback.

Når opdatering bør føre til en hændelsesgennemgang

Et website, der findes med 6.9.0–6.9.4 eller 7.0.0–7.0.1, befandt sig i det berørte versionsinterval for den kritiske angrebskæde. Det viser ikke, at websitet er blevet kompromitteret. Det berettiger dog til en grundigere undersøgelse end blot at installere opdateringen og diskret lukke sagen.

Årsager til at eskalere omfatter en uforklarlig checksumfejl, ukendte administratorkonti, uventede filændringer, mistænkelige requests i de tilgængelige logs eller usikkerhed om, hvor længe installationen var eksponeret. Bevar relevant dokumentation, før noget erstattes eller slettes. Websitets formål, de adgange, det har, og de konkrete fund bør afgøre, hvor omfattende gennemgangen skal være.

Fraværet af en advarsel er ikke det samme som dokumentation for et rent system. Omvendt er en forsinket opdatering ikke i sig selv grundlag for at erklære et sikkerhedsbrud uden underbyggende dokumentation.

Gør den næste hasteopdatering lettere

Automatiske opdateringer er værdifuld leveringsinfrastruktur. Verifikation på tværs af hele porteføljen er en separat driftsopgave, og en robust WordPress-opsætning kræver begge dele.

Greg kan hjælpe med at udarbejde websiteregistret, kontrollere versioner og kernefiler med WP-CLI, finde deaktiverede eller fejlede baggrundsopdateringer, installere de rette patches til de enkelte grene og teste de brugerrejser, der betyder noget. Hvis eksponering eller uregelmæssigheder kræver et nærmere eftersyn, kan arbejdet udvides til logs, administratorkonti og ændrede filer.

Den umiddelbare opgave er at dokumentere, at alle installationer inden for opgavens omfang har den korrekte rettelse. Det nyttige langsigtede resultat er et vedligeholdt register og en reproducerbar proces, som hurtigt kan levere det samme svar, når den næste kritiske sikkerhedsudgivelse kommer.

Relateret indhold på GrN.dk

Har du brug for hjælp til denne type arbejde?

Få verificeret alle dine WordPress-installationer. Kontakt Greg.

Kilder

Sidst ændret

2026-08-21