Fredag kvart i sex på kvällen
WordPress släppte en säkerhetsuppdatering den 17 juli 2026 som täckte två sårbarheter i kärnan. Forskarteamet på Searchlight Cyber, som hittade den allvarligare av de två, gav den namnet wp2shell. De spårade beteckningarna är CVE-2026-63030, en ruttförväxling i REST-API:ets batch-ändpunkt kombinerad med SQL-injektion, och CVE-2026-60137, en SQL-injektion som går att nå via parametern author__not_in i WP_Query.
Klockan 17.45 östlig tid samma dag som patchen publicerade Rapid7 sin analys och noterade två saker. Tekniska detaljer om exploits hade ännu inte publicerats, och man kände inte till något publikt bekräftat utnyttjande i verkligheten. Den som läste den bedömningen på fredagen hade all anledning att tro att det fanns en vanlig arbetsvecka att planera in uppdateringen i.
Så var det inte. PatchStack började rapportera utnyttjande av båda CVE:erna strax före klockan 19 östlig tid samma kväll, ungefär en timme efter Rapid7:s ögonblicksbild. Söndagen den 19 juli hade VulnCheck verifierat över två dussin unika proof of concept-exploits riktade mot bristen.
Två brister, och er version har två olika svar
Det mesta av rapporteringen behandlar det här som en händelse med ett namn. Det är två sårbarheter med olika räckvidd, och den skillnaden avgör vad ni faktiskt måste göra. Att tänka fel åt något av hållen kostar antingen en helg eller lämnar ett hål öppet.
CVE-2026-63030, kedjan för fjärrkörning av kod, berör WordPress 6.9.0 till och med 6.9.4 samt 7.0.0 till och med 7.0.1. Den är åtgärdad i 6.9.5 och 7.0.2, och i 7.1-betalinjen i Beta 2. CVE-2026-60137, SQL-injektionen i WP_Query, når längre bakåt. Den berör 6.8.0 till och med 6.8.5 utöver samma intervall i 6.9 och 7.0, och patchen för den äldre grenen är 6.8.6.
Den praktiska följden är att en webbplats som står kvar på 6.8.x läser rubrikerna om wp2shell, kontrollerar om den ligger i intervallet 6.9 eller 7.0, drar slutsatsen att den inte berörs och stannar där. Den webbplatsen är inte utsatt för hela kedjan för icke-autentiserad kodkörning, men den är utsatt för SQL-injektionen och behöver ändå gå till 6.8.6. Versionskontroller gjorda mot fel CVE är det troligaste sättet för en organisation att göra fel den här veckan.
Skyddsnätet täcker de webbplatser som spelar minst roll
WordPress underhållare svarade med att tvinga fram uppdateringar på berörda installationer där automatiska uppdateringar var påslagna. Det är rätt beslut och det kommer att ha skyddat ett mycket stort antal webbplatser över helgen utan att någon rörde dem.
Titta på vilka webbplatser det inte skyddade. Automatiska uppdateringar stängs av medvetet, och skälen är alltid desamma: en ändringshanteringsprocess, ett tillägg som gick sönder vid en tidigare mindre version, en kedja från test till produktion, ett byråavtal som lägger uppdateringsansvaret på en människa, ett regelverk som förbjuder ogranskade ändringar i produktion. Vart och ett av de skälen är ett tecken på en installation som någon anser vara viktig nog att förvalta.
Det automatiska skyddsnätet är alltså omvänt korrelerat med verksamhetskritikalitet. Hobbybloggen uppdaterade sig själv på fredagskvällen. Kundportalen, bokningssystemet och webbplatsen som tar emot betalningar stod kvar på den sårbara versionen under en helg då fungerande exploit-kod gick från noll till över två dussin. Om er organisation stängde av automatiska uppdateringar som ett mognadsmått är det den här helgen det beslutet kostade er något.
Vad helgens kurva egentligen mäter
Det användbara talet här är inte en CVSS-poäng, och leverantörerna är ändå inte helt eniga om allvarlighetsgraden. Rapid7 anger CVSS 7.5 för kedjan med fjärrkörning av kod medan motsvarande säkerhetsmeddelande behandlar den som kritisk, och VulnCheck rangordnar SQL-injektionen som den kritiska av de två. Att tvista om vilken siffra som ska in i ärendet är en dålig användning av den tid ni har.
Talet som betyder något är intervallet mellan patch och färdigt vapen. Här mättes det i timmar fram till de första rapporterna om utnyttjande och i ungefär två dygn fram till bred publik tillgång på exploits. Det är den verkliga servicenivå som er patchprocess måste klara, och nästan ingen organisations uttalade policy klarar den. Ett åtgärdsfönster på trettio dagar, vanligt i efterlevnadsramverk, är ingen patchpolicy för en brist som den här. Det är en beskrivning av hur länge ni var utsatta.
Det finns en andra detalj i de senare exploits som stänger den vanliga reservutvägen. VulnCheck rapporterar att det på söndagen hade dykt upp ytterligare implementationer för fjärrkörning av kod som kringgår administratörsautentisering helt. Team som tänkte luta sig mot härdade administratörskonton, begränsade inloggningssidor eller tvåfaktor på wp-admin som kompenserande kontroll bör förstå att de åtgärderna inte ligger i vägen för det här angreppet.
Fyra saker värda att göra i dag
För det första, inventera innan ni patchar. Hitta varje WordPress-installation som er organisation faktiskt äger, inklusive marknadsföringssidorna, kampanjsidorna, konferenswebbplatsen från för två år sedan och allt som en byrå som numera är borta byggde. Den sårbara installationen står nästan aldrig i tillgångsregistret. Det är den som ingen kom ihåg fortfarande levererade trafik.
För det andra, kontrollera var och en mot rätt CVE. Allt på 6.8.x går till 6.8.6. Allt på 6.9.x går till 6.9.5. Allt på 7.0.x går till 7.0.2. Låt inte ett enda antagande om versionsintervall täcka hela beståndet.
För det tredje, behandla varje opatchad installation som vette mot internet under helgen som möjligen komprometterad snarare än bara sårbar, och leta efter bevisen i stället för att anta att de saknas. Att patcha stänger dörren. Det avlägsnar inte någon som redan är inne. För det fjärde, och det är den punkt som håller över tid, skriv ned vad er organisations faktiska tid till patch var vid den här händelsen och jämför den med den siffra ni publicerar i er policy. Glappet mellan de två talen är det som ska åtgärdas, för nästa sårbarhet i kärnan kommer att löpa på samma klocka.
Läs vidare: nginx-fixen är ute, exploiten kommer i augusti | ServiceNow patchade sitt eget moln först, dig 103 dagar senare
