Fredag klokken kvart i seks om aftenen

WordPress udsendte den 17. juli 2026 en sikkerhedsopdatering, der dækker to sårbarheder i kernen. Forskerholdet hos Searchlight Cyber, som fandt den alvorligste af de to, gav den navnet wp2shell. De registrerede identifikatorer er CVE-2026-63030, en ruteforveksling i REST-API'ets batch-endepunkt kombineret med SQL-injektion, og CVE-2026-60137, en SQL-injektion, der kan nås gennem parameteren author__not_in i WP_Query.

Klokken 17.45 amerikansk østkysttid samme dag, som patchen udkom, offentliggjorde Rapid7 sin analyse og noterede to ting. Tekniske detaljer om udnyttelsen var endnu ikke offentliggjort, og man kendte ikke til offentligt bekræftet udnyttelse i praksis. Læste man den vurdering fredag, havde man al mulig grund til at tro, at man havde en normal arbejdsuge til at planlægge opdateringen.

Det havde man ikke. PatchStack begyndte at rapportere udnyttelse af begge CVE'er kort før klokken 19 østkysttid samme aften, cirka en time efter Rapid7's øjebliksbillede. Søndag den 19. juli havde VulnCheck verificeret over to dusin unikke proof of concept-exploits rettet mod fejlen.

To fejl, og jeres version har to forskellige svar

Det meste af dækningen behandler det her som én hændelse med ét navn. Der er tale om to sårbarheder med forskellig rækkevidde, og den forskel afgør, hvad I reelt skal gøre. Rammer man ved siden af i den ene eller den anden retning, spilder man en weekend eller lader et hul stå åbent.

CVE-2026-63030, kæden til fjernudførelse af kode, rammer WordPress 6.9.0 til og med 6.9.4 og 7.0.0 til og med 7.0.1. Den er rettet i 6.9.5 og 7.0.2 og i 7.1-betalinjen fra Beta 2. CVE-2026-60137, SQL-injektionen i WP_Query, rækker længere tilbage. Den rammer 6.8.0 til og med 6.8.5 foruden de samme 6.9- og 7.0-intervaller, og rettelsen til den ældre gren er 6.8.6.

Den praktiske konsekvens er, at en side, der kører på 6.8.x, læser overskrifterne om wp2shell, tjekker om den ligger i 6.9- eller 7.0-intervallet, konkluderer at den ikke er ramt, og stopper der. Den side er ikke udsat for hele kæden til ikke-autentificeret kodeudførelse, men den er udsat for SQL-injektionen, og den skal stadig videre til 6.8.6. Versionstjek holdt op mod det forkerte CVE er den mest sandsynlige måde, en organisation griber det her forkert an på i denne uge.

Sikkerhedsnettet dækker de sider, der betyder mindst

WordPress-vedligeholderne reagerede ved at gennemtvinge opdateringer på berørte installationer, der havde automatiske opdateringer slået til. Det er den rigtige beslutning, og den har beskyttet et meget stort antal sider hen over weekenden, uden at nogen skulle røre dem.

Se på, hvilke sider den ikke beskyttede. Automatiske opdateringer bliver slået fra med vilje, og begrundelserne er altid de samme: en ændringsstyringsproces, et plugin der gik i stykker ved en tidligere mindre udgivelse, en kæde fra test til drift, en bureaukontrakt der lægger opdateringsansvaret hos et menneske, et regelsæt der forbyder ugennemgåede ændringer i produktion. Hver eneste af de begrundelser er et tegn på en installation, som nogen anser for vigtig nok til at styre.

Det automatiske sikkerhedsnet er altså omvendt korreleret med forretningskritikalitet. Hobbybloggen opdaterede sig selv fredag aften. Kundeportalen, bookingsystemet og siden, der tager imod betalinger, blev stående på den sårbare version hen over en weekend, hvor mængden af fungerende angrebskode gik fra ingenting til over to dusin. Har jeres organisation slået automatiske opdateringer fra som et modenhedstiltag, er det denne weekend, den beslutning kostede jer.

Hvad weekendens kurve i virkeligheden måler

Det brugbare tal her er ikke en CVSS-score, og leverandørerne er alligevel ikke helt enige om alvoren. Rapid7 anfører CVSS 7.5 for kæden til fjernudførelse af kode, mens den tilhørende sikkerhedsmeddelelse behandler den som kritisk, og VulnCheck rangerer SQL-injektionen som den kritiske af de to. At skændes om, hvilket tal der skal stå i sagen, er en dårlig udnyttelse af den tid, I har.

Tallet, der betyder noget, er intervallet mellem patch og våbenklar exploit. Her blev det målt i timer frem til de første rapporter om udnyttelse og i cirka to døgn frem til bred offentlig tilgængelighed af exploits. Det er det reelle serviceniveau, jeres patchproces skal leve op til, og næsten ingen organisations erklærede politik gør det. Et udbedringsvindue på tredive dage, som er almindeligt i compliance-rammeværker, er ikke en patchpolitik for en fejl som denne. Det er en beskrivelse af, hvor længe I var udsat.

Der er en detalje mere i de senere exploits, som lukker den sædvanlige nødudgang. VulnCheck rapporterer, at der søndag var dukket yderligere implementeringer af fjernudførelse af kode op, som omgår administrator-autentificering fuldstændigt. Hold, der havde tænkt sig at læne sig op ad hærdede administratorkonti, begrænsede loginsider eller tofaktor-autentificering på wp-admin som kompenserende kontrol, bør forstå, at de tiltag ikke ligger på dette angrebs vej.

Fire ting, det er værd at gøre i dag

For det første: lav opgørelsen, før I patcher. Find hver eneste WordPress-installation, jeres organisation reelt ejer, inklusive markedsføringssiderne, kampagnesiderne, konferencesiden fra for to år siden og alt det, et bureau, der for længst er væk, har bygget. Den sårbare installation er næsten aldrig den, der står i aktivregistret. Det er den, ingen huskede stadig leverede trafik.

For det andet: hold hver enkelt op mod det rigtige CVE. Alt på 6.8.x skal til 6.8.6. Alt på 6.9.x skal til 6.9.5. Alt på 7.0.x skal til 7.0.2. Lad ikke én antagelse om et versionsinterval dække hele bestanden.

For det tredje: behandl enhver upatchet installation, der vendte mod internettet hen over weekenden, som muligt kompromitteret snarere end blot sårbar, og led efter beviserne i stedet for at gå ud fra, at de ikke findes. At patche lukker døren. Det fjerner ikke nogen, der allerede er indenfor. For det fjerde, og det er det, der holder: skriv ned, hvad jeres organisations faktiske tid til patch var ved denne hændelse, og sammenlign den med det tal, I offentliggør i jeres politik. Afstanden mellem de to tal er det, der skal rettes, for den næste sårbarhed i kernen kører på det samme ur.

Læs videre: nginx-rettelsen er ude, exploitet kommer i august  |  ServiceNow patchede sin egen sky først, dig 103 dage senere