wp2shell: een standaard WordPress-RCE, gevonden in tien uur voor $25

Op 17 juli 2026 publiceerde Searchlight Cyber wp2shell, een pre-authenticatieketen voor remote code execution in de WordPress-kern die geen plugin, geen thema en geen login nodig heeft. Een anonieme aanvraag tegen een standaardinstallatie is voldoende: "De aanval heeft geen voorwaarden en kan door een anonieme gebruiker worden misbruikt in een standaardinstallatie van WordPress zonder plugins," aldus het advies van het bedrijf. De keten combineert twee bugs: CVE-2026-63030, een route-confusionfout in het batch-eindpunt van de WordPress REST API die door het advies van het project als kritiek wordt bestempeld, en CVE-2026-60137, een SQL-injectie in de author__not_in parameter van WP_Query die door het advies als matig wordt bestempeld. WordPress bracht dezelfde dag WordPress 7.0.2 uit, en de adviezen van het project vermelden WordPress 6.9.5, WordPress 6.8.6 en WordPress 7.1 beta2 als versies met dezelfde fixes. Searchlight verwijst naar schattingen van meer dan 500 miljoen WordPress-sites. De onderzoeker achter de keten, Adam Kues, zegt dat die voortkwam uit een GPT-5.6 Sol Ultra-run op basis van een prompt die OpenAI had gepubliceerd voor een wiskundeprobleem: maximaal vier agents, minstens zes uur op jacht en ongeveer vier uur extra voor escalatie, ongeveer $25 aan modelgebruik. Het record is geregistreerd als een onderzoeksbevinding — hoge ernst op de eigen schaal van het archief, vertrouwen op A-niveau, geen geregistreerde schade in de praktijk, gedateerd op één enkele dag — en the Orca AI Incident Archive bevat het, met de primaire documenten daaronder gelinkt.

De openbaarmaking was gecoördineerd. Searchlight hield de technische werking op 17 juli achter en gaf verdedigers het weekend om te upgraden; Kues publiceerde op 20 juli de volledige technische uitleg. Inmiddels was de geketende exploit al onafhankelijk gereproduceerd: volgens Searchlight herbouwden Calif en Hacktron de volledige keten voordat andere proof-of-concepts op GitHub verschenen. De twee eigen beveiligingsadviezen van WordPress noemen dezelfde gepatchte versies, en CISA voegde beide CVEs op 21 juli toe aan zijn Known Exploited Vulnerabilities-catalogus.

Twee bugs, en de arrays die uit de pas lopen

Het toegangspunt is eerder een feature dan een fout. WordPress 5.6 introduceerde in 2020 het batch-endpoint zodat een client meerdere virtuele REST-aanvragen binnen één HTTP-aanvraag kon versturen, bijvoorbeeld om een set berichten tegelijk een nieuwe titel te geven. Het endpoint is bereikbaar ongeacht of de aanroeper is geauthenticeerd, en elke subaanvraag draagt de authenticatie die de aanroeper heeft meegegeven. Een directe aanvraag naar een WordPress REST-route doorloopt een pipeline van vier stappen: vereiste en geldige parameters controleren, ze saneren, de permission-callback uitvoeren en daarna de endpoint-callback uitvoeren. Endpoints vertrouwen op die pipeline voor hun typeaannames — dat een bericht-ID een integer is, dat een titel een string is.

De batch-API splitst de pijplijn in tweeën, valideert elke subaanvraag in één lus en voert ze in een tweede uit, en deze houdt twee arrays bij, $matches en $validation, waarvan de items bedoeld zijn om index voor index op één lijn te staan. In class-wp-rest-server.php wordt, zoals Kues het beschrijft, een subaanvraag die zelf een WordPress-fout is, toegevoegd aan $validation en stuit dan op een continue, en de regel die aan $matches toevoegt, wordt overgesprongen. Vanaf dat punt is elke match één positie naar achteren verschoven. De uitvoeringslus koppelt de subaanvraag op één index aan de validatie die op die index is vastgelegd, maar de handler is aan een andere route gekoppeld — dus een parameter wordt tegen de regels van het ene endpoint gecontroleerd en vervolgens door de code van een ander uitgevoerd.

Dat is wat een ogenschijnlijk gewone lijstparameter in injectie verandert. De route voor de berichtenverzameling koppelt het openbare author_excludeargument aan author__not_in. Wanneer de waarde een array is, voert WordPress absint uit op elk element en sorteert ze; wanneer de waarde een scalair is, wordt deze ongewijzigd samengevoegd in het SQL-fragment dat NOT IN ($author__not_in) wordt. Een tekenreeks zoals 0) OR 1=1 -- belandt daardoor in de querytekst. Normaal gesproken zou de route dit weigeren, omdat author_exclude een array van gehele getallen moet zijn; de gedesynchroniseerde batchaanroep is wat een tekenreeks erdoorheen laat.

Er bleven twee obstakels over, en beide werden opgelost door de truc te nesten. De batch-API weigert GET-verzoeken, en de injectie bevindt zich op een GET-route; en de validatie van de verzoekmethode is zelf geïmplementeerd als parametervalidatie, die door dezelfde desync kan worden omzeild. De gepubliceerde payload van Kues stuurt een misvormd buitenste subverzoek om de methodecontrole te desynchroniseren, vervolgens een binnenste batch waarvan het tweede subverzoek de kwaadaardige author_exclude naar een handler stuurt die deze niet valideert, en dan de GET die het uitvoert. Een op UNION gebaseerde injectie retourneert willekeurige databasewaarden in rijen die op gewone posts lijken.

De modelrun: een wiskundeprompt, gericht op een codebase

Kues schreef de prompt niet vanaf nul. OpenAI had de prompt gepubliceerd die het gebruikte tijdens het werken aan het Cycle Double Cover-vermoeden, en Kues schreef dat hij had gelezen dat het model dat vermoeden onlangs had opgelost en dat niemand in de beveiligingsgemeenschap over de prompt leek te praten. Zijn redenering was dat als het goed genoeg was voor moeilijke wiskunde, het waarschijnlijk ook goed genoeg was voor beveiligingsonderzoek. Hij paste het aan en richtte het op WordPress.

De opzet was bewust smal. Hij kloonde de nieuwste stabiele WordPress-versie naar een map genaamd main/ en verwijderde daaruit de .git-map; hij vertelde het model geen changelogs, git-historie of het openbare internet te gebruiken om de code tegen een gepatchte versie te diffen — zijn genoemde reden was dat het raadplegen van historie of het web voor het ontdekken van nieuwe kwetsbaarheden een verspilling van tokens is. Een lege third_party/-map werd aangeboden zodat het model afhankelijkheden zoals PHP- of MySQL-broncode kon klonen als het oordeelde dat de keten bugs in de bibliotheken onder WordPress nodig had. De taak was gespecificeerd als pre-authenticatie-RCE in een typische productieomgeving op MySQL, met maximaal vier agenten en ten minste zes uur. Kues schreef dat hij de configuratievereiste expliciet vermeldt omdat modellen anders "vals spelen" — door extreem onwaarschijnlijke configuratieopties te kiezen, of door voorwaarden te verzinnen die een aanvaller nooit zou kunnen bereiken.

Wat terugkwam in de lopende uitvoer, was een bewering over een SQL-injectie vóór authenticatie. Kues betwijfelde dat: WordPress is een van de meest grondig gecontroleerde doelwitten aller tijden, schreef hij, en had dat decennium geen betekenisvolle kwetsbaarheid vóór authenticatie gehad. Hij installeerde een standaard WordPress-instantie op een externe server en vroeg het model om het e-mailadres van de beheerder te stelen; binnen een paar minuten drukte het het adres af dat hij had gebruikt om de instantie op te zetten. Daarna vroeg hij of de alleen-lezen-injectie kon worden geëscaleerd, en ongeveer vier uur later antwoordde het model dat dat kon — tot beheerder, zonder enig wachtwoord te kraken en zonder offline berekening.

Zijn eigen kostenberekening: 50% van een wekelijks gebruiksbudget, dat hij pro rata op ongeveer $25 van een abonnement van $200 schatte, voor een exploit die in iets meer dan tien uur was gemaakt. Het menselijke deel was niet gratis — Kues bracht de volgende dag door met het ontrafelen van wat het model had gedaan, en schreef dat hij veel langer nodig had om de post-exploitatie werkzaamheden te begrijpen dan om ze te genereren. Zijn oordeel is ongewoon bot en nauw begrensd: "Ik maak geen algemene claims, maar ik kan met volledige zekerheid zeggen dat geen enkele beveiligingsonderzoeker deze exploitketen binnen 10 uur zonder AI had kunnen vinden en voltooien."

Van een alleen-lezen SELECT naar beheerder

De escalatie is het deel van het verslag dat het meest van belang is, omdat daar een databaselezing overging in controle over de server. Kues' relaas presenteert het als een reeks van zes stappen, waarbij elke stap een gewone WordPress-functie tegen een andere uitspeelt.

Vergiftig eerst de in-memory postcache. WordPress houdt per verzoek een cache bij van WP_Post-objecten, zodat dezelfde post die meerdere keren in één verzoek wordt gebruikt, slechts één database-roundtrip kost. De SQL-injectie kan posts fabriceren, dus de aanvaller bepaalt precies wat er wordt gecachet — maar die gefabriceerde posts zijn geen rijen in de database, en de cache verdwijnt samen met het verzoek.

Ten tweede: verander gefabriceerde berichten in echte rijen.De embedfunctie van WordPress slaat opgeloste embeds op in de database als berichten van het type oembed_cache. Als je een lokaal bericht insluit via een relatief pad, zoals in [embed]/?p=S[/embed], slaat WordPress het HTTP-ophalen over en wordt nooit gecontroleerd of het bericht waarnaar wordt verwezen bestaat, waardoor er een rij wordt aangemaakt. Drie zulke embeds met verschillende query-stringtokens leveren drie verschillende cachehashes op, en zo krijgt de aanvaller meerdere rijen om mee te werken.

Ten derde: omzeil het ene veld dat vast blijft staan. Wanneer de in-memory- en databaseversies van een bericht niet overeenkomen, verzoent WordPress ze met een aanroep die expliciet post_content instelt op basis van de embed-uitvoer. Alles aan het bericht wordt door de aanvaller bepaald, behalve de inhoud, en dat is precies het veld dat een customize_changeset gebruikt om de JSON van openstaande wijzigingen aan thema en site op te slaan.

Ten vierde, het cyclusgadget. Berichten hebben ouders, en WordPress weigert cycli: de wp_insert_post_parentfilter loopt de boom omhoog en roept bij het vinden van een lus een update aan die post_parent op nul zet. Die aanroep overschrijft post_content niet, dus de gefabriceerde versie in het geheugen overleeft de reconciliatie — een changeset, met zijn JSON intact, ondersteund door een echte rij.

Ten vijfde: leen de autoriteit van de beheerder. Een changeset waarvan de status aangeeft dat deze voor de toekomst is gepland, maar waarvan de datum in het verleden ligt, wordt onmiddellijk toegepast. Elke vermelding in de JSON ervan noemt een user_id, en de vermelding in de keten van Kues noemt user_id 1, de beheerder, zodat WordPress tijdelijk die identiteit aanneemt om de wijziging toe te passen. De eerste wijziging is een onschuldig ogende update van nav_menus_created_posts.

Ten zesde, herhaal de aanvraag als die identiteit. Het publiceren van een bericht activeert een actie met een dynamisch gegenereerde naam, {status}_{post_type}. Omdat het bericht verzonnen is, kunnen die status en dat type van alles zijn — inclusief parse en request, wat de parse_request-hook oplevert en de aanvraagpipeline van voren af aan herstart, terwijl de geleende beheerdersidentiteit nog steeds van kracht is. De oorspronkelijke batch-aanvraag bevatte een subaanvraag die een nieuwe beheerder aanmaakte; deze mislukte bij de eerste doorgang als gast en slaagt bij de herhaling. Van daaruit logt de aanvaller in met dat nieuwe account en uploadt een backdoor-plug-in uit een ZIP-bestand, wat code-uitvoering betekent.

Aan de techniek is een voorwaarde verbonden. The Hacker News meldde, met verwijzing naar Cloudflare, dat CVE-2026-63030 alleen remote code execution oplevert wanneer er geen persistente objectcache in gebruik is; de injectie zelf is aanwezig vanaf WordPress 6.8, terwijl de volledige keten 6.9 of later vereist. Een standaardinstallatie heeft geen persistente objectcache, en daarom beschrijven Searchlights formulering "geen voorwaarden" en Cloudflares kwalificatie hetzelfde standaardgeval vanuit verschillende invalshoeken.

Wat de primaire documenten vaststellen

WordPress' eigen veiligheidsadviezen vormen de sterkste bevestiging, omdat de leverancier daarmee de werking toegeeft en de reparatie uitbrengt. GHSA-ff9f-jf42-662q, geclassificeerd als kritiek, beschrijft een zwakheid door verwarring van batchroutes in de REST API in WordPress 6.9 en hoger, die samen met de injectie tot code-uitvoering leidt, en schrijft de ontdekking toe aan Adam Kues bij Assetnote en Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, geclassificeerd als gemiddeld, beschrijft de author__not_in-injectie vanaf WordPress 6.8 en hoger, en vermeldt dat beide problemen zijn opgelost in WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 en WordPress 7.1 bèta2. De NVD-records voor de twee CVE's, gescoord door de WPScan-CNA en niet door NIST, kennen 9,8 toe aan CVE-2026-63030 met de vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, en 5,9 aan CVE-2026-60137 met AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — een via het netwerk bereikbare bug die geen rechten vereist in het eerste geval, en een die hoge aanvalscomplexiteit vereist en alleen impact op vertrouwelijkheid heeft in het tweede. Het eigen ernstveld van het archief voor deze vermelding luidt hoog, terwijl WordPress de batchfout als kritiek labelt; het zijn twee afzonderlijke schalen die worden toegepast op een hele keten en op één component, geen meningsverschil over de bugs zelf.

De catalogusvermeldingen van CISA, zoals weergegeven in de verrijkingsvelden van NVD, werden op 21 juli 2026 toegevoegd, met hersteldeadlines van 24 juli voor CVE-2026-63030 en 4 augustus voor CVE-2026-60137. CISA noemt de eerste "WordPress Core Interpretation Conflict Vulnerability" en de tweede "WordPress Core SQL Injection Vulnerability". Searchlight publiceerde ook een openbare checker op wp2shell.com, zodat beheerders een instantie konden testen zonder te wachten op een scannersignatuur.

De onafhankelijke reproductie is door Searchlight zelf gedocumenteerd en is daarom een bewering over derden, niet een verslag van een derde partij: volgens het verslag van 20 juli hebben Calif en Hacktron de volledige keten herbouwd voordat andere proof-of-concepts op GitHub verschenen. Wat onafhankelijk verifieerbaar is, is het effect — proof-of-concepts, exploitatietraffic en telemetrie van leveranciers binnen enkele dagen, hieronder besproken.

Wat wordt beweerd maar niet aangetoond?

Twee vermeldingen voor één injectie zijn in de openbare verslaglegging niet met elkaar te verenigen. De advisory van WordPress voor CVE-2026-60137 stelt dat het probleem "ontdekt en verantwoord gemeld is als team door TF1T, dtro en haongo". De weergave van Searchlight presenteert dezelfde pre-authenticatie-injectie als wat zijn modelrun heeft opgeleverd, en vermeldt dat team niet; de advisory van WordPress kent Kues alleen de verwarring rond de batchroute toe en vermeldt geen model. Geen van beide documenten verklaart de overlap, en niets wat dit artikel heeft gevonden lost dat op — de mogelijkheid dat het twee onafhankelijke vondsten van dezelfde bug waren, is niet uitgesloten, en de mogelijkheid dat één rapport een latere herontdekking is, is evenmin vastgesteld. De verslaglegging beslist daar niet over, en dit artikel evenmin.

Het getal in de kop van Searchlights bericht van 20 juli wordt niet ondersteund door de tekst zelf. Er staat: "Exploit-makelaars betalen $500.000 voor een WordPress-RCE. Ik vond er een met GPT5.6 Sol Ultra en $25". De tekst documenteert de $25 en de tien uur in concrete bewoordingen; hij bevat geen namen van exploit-makelaars, geen aanbiedingen, geen correspondentie en geen bron voor het bedrag van $500.000. Er is voor dit stuk geen onafhankelijk rapport gevonden dat een betaalde of aangeboden prijs voor wp2shell bevestigt. Lees de $500.000 als de framing van de kop, niet als een gevestigde marktprijs.

De reikwijdte van het archiefitem zelf is smaller dan het verhaal eromheen. Het registreert een onderzoeksbevinding op de dag van openbaarmaking, meldt geen schade in de echte wereld en is gedateerd op één enkele dag, 17 juli 2026. Dat is geen bewering dat er daarna niets is gebeurd: exploitatieverkeer werd binnen enkele uren na de waarschuwing gemeld, en CISA catalogiseerde beide CVE's vier dagen later. De markering dekt wat het item beschrijft — de ontdekking en de gecoördineerde openbaarmaking — en de daaropvolgende exploitatie wordt hieronder door andere partijen gedocumenteerd op basis van hun eigen bewijs.

Exploitatie na het advies

Jake Knott, principal security researcher bij watchTowr, vertelde The Hacker News dat "in de vroege uren van zaterdagochtend (UTC) succesvolle exploitatie al in volle gang was, aanvankelijk met openbare exploitcode om gehashte inloggegevens te exfiltreren, gevolgd door remote code execution zodra aanvullende details openbaar werden." Hetzelfde rapport citeert KEVIntel-telemetrie die 13 unieke IP-adressen uit Zwitserland, Duitsland, het Verenigd Koninkrijk, Indonesië, Litouwen, Nederland en Singapore koppelt aan de exploitatie van CVE-2026-63030, en citeert KEVIntel-oprichter Ryan Dewhurst, die zegt dat de verzoeken overeenkwamen met openbaar beschikbare proofs of concept en dat blinde, UNION-gebaseerde en booleaanse payloads allemaal werden gebruikt.

De onderzoekers van Wiz, Shahar Dorfman en Gili Tikochinski, publiceerden op 20 juli en maakten de omvang duidelijk: 60% van de organisaties die WordPress gebruikten, had op het moment dat de CVE's werden gepubliceerd minstens één kwetsbare instantie, en 25% stelde een kwetsbare server bloot aan internet; dat daalde binnen 24 uur naar 50% en 10% toen het patchen begon. Ze registreerden kwaadwillige plugin-uploads via de admin-installer, gebruikersenumeratie tegen de users-endpoint, pogingen tot local file inclusion tegen wp-config, en toegang tot het beheerpaneel dat HTTP 200 retourneerde — de signatuur van een geslaagde login, niet van een probe. De malware die ze vonden, varieerde van een minimale PHP-backdoor van één regel tot een webshell van 150 KB vermomd als een legitiem WordPress-beveiligingsplugin genaamd CMSmap, met modules voor bestandsbeheer, databasetoegang, poortscannen en privilege-escalatie.

Wiz noteerde ook een grens aan wat kan worden geconcludeerd. Grootschalige scanning zonder post-exploitatie kwam vaak voor, in overeenstemming met opportunistisch massa-scannen en met legitieme beveiligingsscans, en het bedrijf verklaarde dat het geen laterale beweging of gegevensdiefstal had vastgesteld. Dat is een uitspraak over wat de telemetrie van één leverancier liet zien, geen bevinding dat er niets is ontvreemd.

Wat daarna veranderde, en wat open bleef

Voor operators was het reactiepad kort. Updaten naar WordPress 7.0.2, WordPress 6.9.5 of WordPress 6.8.6 is de oplossing. De noodalternatieven van Searchlight, voor sites die niet onmiddellijk konden updaten, waren het blokkeren van anonieme toegang tot de batch-API — hetzij door een plugin te installeren die anonieme toegang tot de REST API volledig blokkeert, hetzij door /wp-json/batch/v1 en ?rest_route=/batch/v1 op een webapplication firewall te blokkeren. Het bedrijf waarschuwde dat beide legitiem gebruik van de site kunnen beïnvloeden en als tijdelijke maatregelen moeten worden behandeld tot de update er is. De openbare checker op wp2shell.com test een instantie direct. De catalogusvermeldingen van CISA voegden een nalevingsklok toe: herstel door 24 juli voor CVE-2026-63030 en door 4 augustus voor CVE-2026-60137.

Wat de onderzoeksvraag betreft, is het deel dat niet werd opgelost wat het model feitelijk bijdroeg ten opzichte van zijn operator. Kues is precies over de verdeling: het model produceerde de keten in ongeveer tien uur, en het begrijpen ervan kostte hem langer dan het genereren ervan had gekost. Hij weigert algemene uitspraken te doen en zegt alleen dat het resultaat van tien uur niet haalbaar was voor een mens zonder hulp. De prompt zelf is geen geheim — hij stamt af van een prompt die OpenAI heeft gepubliceerd, en Searchlight reproduceerde zijn structuur in het verslag, inclusief de instructie om versiegeschiedenis te negeren en de eis dat de exploit werkt in een typische productieconfiguratie. Of dat recept naar andere codebases overdraagbaar is, is precies de vraag die Kues volgens eigen zeggen niet beantwoordt, en er is geen tweede run gepubliceerd.

Wat het dossier onopgehelderd laat, is dus beperkt maar van belang: welke van de twee genoemde partijen de injectie als eerste ontdekte, of een broker ooit het bedrag uit de kop heeft betaald, en wat de webshells die Wiz heeft waargenomen, als ze al iets deden, daadwerkelijk hebben weggenomen van de sites waar ze terechtkwamen. Over het laatste punt bestaat alleen een publieke verklaring van Wiz, namelijk dat zij geen laterale beweging of data-exfiltratie heeft vastgesteld — een afwezigheid van bewijs vanuit één gezichtspunt, als zodanig gepresenteerd.