Vrijdag om kwart voor zes 's avonds

WordPress bracht op 17 juli 2026 een beveiligingsrelease uit voor twee kwetsbaarheden in de kern. Het onderzoeksteam van Searchlight Cyber, dat de ernstigste van de twee vond, gaf die de naam wp2shell. De geregistreerde kenmerken zijn CVE-2026-63030, routeverwarring in het batch-eindpunt van de REST API in combinatie met SQL-injectie, en CVE-2026-60137, een SQL-injectie die bereikbaar is via de parameter author__not_in van WP_Query.

Om 17.45 uur oostelijke tijd op de dag van de patch publiceerde Rapid7 zijn analyse en legde twee dingen vast. Technische exploitdetails waren nog niet gepubliceerd, en het bedrijf kende geen publiek bevestigd misbruik in het wild. Wie die inschatting op vrijdag las, had alle reden om te denken dat er een normale werkweek was om de update in te plannen.

Die was er niet. PatchStack begon vlak voor 19.00 uur oostelijke tijd diezelfde avond misbruik van beide CVE's te melden, ruwweg een uur na de momentopname van Rapid7. Op zondag 19 juli had VulnCheck meer dan twee dozijn unieke proof-of-concept-exploits geverifieerd die op het lek mikken.

Twee fouten, en uw versie heeft twee verschillende antwoorden

Het merendeel van de berichtgeving behandelt dit als een gebeurtenis met een naam. Het zijn twee kwetsbaarheden met verschillend bereik, en dat verschil bepaalt wat u werkelijk moet doen. In beide richtingen misgokken kost u een weekend of laat een gat openstaan.

CVE-2026-63030, de keten voor code-uitvoering op afstand, treft WordPress 6.9.0 tot en met 6.9.4 en 7.0.0 tot en met 7.0.1. Die is verholpen in 6.9.5 en 7.0.2, en in de 7.1-betalijn in Beta 2. CVE-2026-60137, de SQL-injectie in WP_Query, reikt verder terug. Die treft 6.8.0 tot en met 6.8.5 naast dezelfde 6.9- en 7.0-bereiken, en de fix voor de oudere tak is 6.8.6.

Het praktische gevolg is dat een site die op 6.8.x draait de koppen over wp2shell leest, nagaat of hij in het 6.9- of 7.0-bereik valt, concludeert dat hij niet getroffen is, en het daarbij laat. Die site staat niet bloot aan de volledige niet-geauthenticeerde keten voor code-uitvoering, maar wel aan de SQL-injectie, en moet alsnog naar 6.8.6. Versiecontroles die tegen de verkeerde CVE worden gedaan, zijn deze week de waarschijnlijkste manier waarop een organisatie de mist in gaat.

Het vangnet dekt juist de sites die er het minst toe doen

De WordPress-beheerders reageerden door updates af te dwingen op getroffen installaties waarop automatische updates aanstonden. Dat is de juiste keuze en het zal in het weekend een zeer groot aantal sites hebben beschermd zonder dat iemand ze hoefde aan te raken.

Kijk naar de sites die het niet beschermde. Automatische updates worden bewust uitgezet, en de redenen zijn altijd dezelfde: een wijzigingsprocedure, een plug-in die brak bij een eerdere kleine release, een pijplijn van staging naar productie, een bureaucontract dat de verantwoordelijkheid voor updates bij een mens legt, een nalevingsregime dat niet-geëvalueerde wijzigingen in productie verbiedt. Elk van die redenen is een teken dat iemand de installatie belangrijk genoeg vindt om te beheren.

Het automatische vangnet is dus omgekeerd gecorreleerd met bedrijfskritischheid. De hobbyblog werkte zichzelf op vrijdagavond bij. Het klantenportaal, het boekingssysteem en de site die betalingen aanneemt bleven een heel weekend op de kwetsbare versie staan, een weekend waarin werkende exploitcode van geen enkele naar meer dan twee dozijn ging. Heeft uw organisatie automatische updates uitgezet als teken van volwassenheid, dan is dit het weekend waarin die beslissing u geld heeft gekost.

Wat de weekendcurve werkelijk meet

Het nuttige getal is hier geen CVSS-score, en de leveranciers zijn het over de ernst sowieso niet volledig eens. Rapid7 noteert CVSS 7.5 voor de keten voor code-uitvoering op afstand, terwijl het bijbehorende advies die als kritiek behandelt, en VulnCheck bestempelt de SQL-injectie als de kritieke van de twee. Ruziën over welk cijfer in het ticket komt, is een slechte besteding van de tijd die u nog hebt.

Het getal dat er wel toe doet, is het interval tussen patch en bewapening. Hier werd dat gemeten in uren tot de eerste meldingen van misbruik en in ongeveer twee dagen tot brede publieke beschikbaarheid van exploits. Dat is het reële serviceniveau waaraan uw patchproces moet voldoen, en vrijwel geen enkele organisatie haalt dat met het beleid dat zij op papier heeft staan. Een hersteltermijn van dertig dagen, gebruikelijk in nalevingskaders, is geen patchbeleid voor een fout als deze. Het is een beschrijving van hoe lang u blootgesteld stond.

In de latere exploits zit een tweede detail dat de gebruikelijke terugvaloptie afsluit. VulnCheck meldt dat er op zondag aanvullende implementaties voor code-uitvoering op afstand waren opgedoken die beheerdersauthenticatie volledig omzeilen. Teams die van plan waren te leunen op geharde beheerdersaccounts, afgeschermde inlogpagina's of tweefactor op wp-admin als compenserende maatregel, moeten begrijpen dat die maatregelen niet in het pad van deze aanval liggen.

Vier dingen die vandaag de moeite waard zijn

Ten eerste, inventariseer voordat u patcht. Zoek elke WordPress-installatie die uw organisatie werkelijk bezit, inclusief de marketingmicrosites, de campagnelandingspagina's, de site van het congres van twee jaar geleden en alles wat een inmiddels vertrokken bureau heeft gebouwd. De kwetsbare installatie staat vrijwel nooit in het activaregister. Het is de installatie waarvan niemand zich nog herinnerde dat zij verkeer bediende.

Ten tweede, controleer elke installatie tegen de juiste CVE en kijk welke versie er daadwerkelijk geïnstalleerd is. Alles op 6.8.x gaat naar 6.8.6. Alles op 6.9.x gaat naar 6.9.5. Alles op 7.0.x gaat naar 7.0.2. Laat niet een enkele aanname over een versiebereik voor het hele landschap gelden.

Ten derde, behandel elke ongepatchte installatie die het weekend aan het internet hing als mogelijk gecompromitteerd in plaats van louter kwetsbaar, en zoek naar het bewijs in plaats van aan te nemen dat het ontbreekt. Patchen sluit de deur. Het verwijdert niemand die al binnen is. Ten vierde, en dat is de duurzame les, schrijf op wat de werkelijke tijd tot patchen van uw organisatie bij dit voorval was en vergelijk die met het cijfer uit het beleid dat u publiceert. Het gat tussen die twee getallen is wat u moet repareren, want de volgende kwetsbaarheid in de kern loopt op dezelfde klok.

Lees hierna: De nginx-patch is er, de exploit komt in augustus  |  ServiceNow patchte eerst de eigen cloud, u pas 103 dagen later