wp2shell: Eine RCE in Standard-WordPress, in zehn Stunden für 25 US-Dollar gefunden

Am 17. Juli 2026 veröffentlichte Searchlight Cyber wp2shell, eine Remote-Code-Execution-Kette vor der Authentifizierung im WordPress-Kern, für die weder ein Plugin noch ein Theme noch eine Anmeldung nötig ist. Eine anonyme Anfrage gegen eine Standardinstallation genügt: „Die Attacke hat keine Vorbedingungen und kann von einem anonymen Nutzer in einer Standardinstallation von WordPress ohne Plugins ausgenutzt werden“, heißt es in dem Sicherheitshinweis des Unternehmens. Die Kette kombiniert zwei Schwachstellen – CVE-2026-63030, eine Route-Confusion-Schwachstelle im Batch-Endpunkt der WordPress-REST-API, die der Sicherheitshinweis des Projekts als kritisch einstuft, und CVE-2026-60137, eine SQL-Injection im author__not_in-Parameter von WP_Query, die er als mittelschwer einstuft. WordPress veröffentlichte am selben Tag WordPress 7.0.2, und die Sicherheitshinweise des Projekts nennen WordPress 6.9.5, WordPress 6.8.6 und WordPress 7.1 beta2 als Versionen, die dieselben Fixes enthalten. Searchlight beruft sich auf Schätzungen von mehr als 500 Millionen WordPress-Websites. Der Forscher hinter der Kette, Adam Kues, sagt, sie sei aus einem GPT-5.6 Sol Ultra-Lauf hervorgegangen, der auf einem Prompt basierte, das OpenAI für ein Mathematikproblem veröffentlicht hatte: bis zu vier Agenten, mindestens sechs Stunden für die Suche und etwa vier weitere für die Eskalation, rund 25 US-Dollar für die Modellnutzung. Der Eintrag ist als Forschungsergebnis verzeichnet – hoher Schweregrad auf der eigenen Skala des Archivs, Konfidenzstufe A, kein dokumentierter Schaden in der realen Welt, auf einen einzigen Tag datiert – und das Orca AI Incident Archive führt ihn mit den darunter verlinkten Primärdokumenten auf.

Die Offenlegung erfolgte koordiniert. Searchlight hielt die technischen Details am 17. Juli zurück und gab Verteidigern das Wochenende Zeit für ein Upgrade; Kues veröffentlichte am 20. Juli den vollständigen technischen Bericht. Bis dahin war der verkettete Exploit bereits unabhängig reproduziert worden: Searchlight zufolge bauten Calif und Hacktron die vollständige Kette nach, bevor weitere Proofs of Concept auf GitHub auftauchten. Die beiden eigenen Sicherheitshinweise von WordPress nennen dieselben korrigierten Versionen, und CISA nahm beide CVEs am 21. Juli in ihren Known Exploited Vulnerabilities-Katalog auf.

Zwei Bugs und die Arrays, die aus dem Tritt geraten

Der Einstiegspunkt ist eine Funktion und kein Fehler. WordPress 5.6 führte 2020 den Batch-Endpunkt ein, damit ein Client mehrere virtuelle REST-Anfragen innerhalb einer HTTP-Anfrage senden konnte, beispielsweise um eine Gruppe von Beiträgen auf einmal neu zu betiteln. Der Endpunkt ist erreichbar, unabhängig davon, ob der Aufrufer authentifiziert ist, und jede Unteranfrage trägt die Authentifizierung, die der Aufrufer geliefert hat. Eine direkte Anfrage an eine WordPress-REST-Route durchläuft eine Pipeline mit vier Schritten: erforderliche und gültige Parameter prüfen, sie bereinigen, den Permission-Callback ausführen und dann den Endpunkt-Callback ausführen. Endpunkte verlassen sich für ihre Typannahmen auf diese Pipeline – dass eine Beitrags-ID eine Ganzzahl ist, dass ein Titel ein String ist.

Die Batch-API teilt die Pipeline in zwei Phasen auf, validiert jede Unteranfrage in einer Schleife und führt sie in einer zweiten aus, und sie führt zwei Arrays, $matches und $validation, deren Einträge sich Eintrag für Eintrag entsprechen sollen. In class-wp-rest-server.php wird, wie Kues es beschreibt, eine Unteranfrage, die selbst ein WordPress-Fehler ist, an $validation angehängt und trifft dann auf ein continue, wodurch die Zeile übersprungen wird, die an $matches anhängt. Ab diesem Punkt ist jeder Treffer um eine Position nach hinten verschoben. Die Ausführungsschleife kombiniert die Unteranfrage an einem Index mit der an diesem Index aufgezeichneten Validierung, aber mit dem Handler, der einer anderen Route zugeordnet ist – sodass ein Parameter gegen die Regeln eines Endpunkts geprüft und dann vom Code eines anderen ausgeführt wird.

Das ist es, was einen gewöhnlich aussehenden Listenparameter in eine Injection verwandelt. Die Route der Posts-Sammlung bildet ihr öffentliches author_excludeArgument auf author__not_in ab. Wenn der Wert ein Array ist, führt WordPress absint über jedes Element aus und sortiert sie; wenn der Wert ein Skalar ist, wird er unverändert in das SQL-Fragment eingefügt, das zu NOT IN ($author__not_in) wird. Ein String wie 0) OR 1=1 -- landet daher im Abfragetext. Normal aufgerufen würde die Route ihn ablehnen, weil author_exclude ein Array aus Ganzzahlen sein muss; der desynchronisierte Batch-Aufruf ist es, der einen String durchlässt.

Zwei Hindernisse blieben bestehen, und beide wurden durch Verschachteln des Tricks gelöst. Die Batch-API lehnt GET-Anfragen ab, und die Injection sitzt auf einer GET-Route; und die Validierung der Request-Methode ist selbst als Parametervalidierung implementiert, die derselbe Desync umgehen kann. Kues’ veröffentlichter Payload sendet eine fehlerhafte äußere Subrequest, um die Methodenprüfung zu desynchronisieren, dann einen inneren Batch, dessen zweite Subrequest das bösartige author_exclude gegen einen Handler trägt, der es nicht validiert, dann den GET, der es ausführt. Eine UNION-basierte Injection gibt beliebige Datenbankwerte in Zeilen zurück, die wie gewöhnliche Beiträge geformt sind.

Der Modelllauf: ein Mathematik-Prompt, auf eine Codebasis gerichtet

Kues schrieb den Prompt nicht von Grund auf selbst. OpenAI hatte den Prompt veröffentlicht, den es bei der Arbeit an der Cycle-Double-Cover-Vermutung verwendet hatte, und Kues schrieb, er habe gelesen, das Modell habe diese Vermutung kürzlich gelöst, und niemand in der Sicherheitscommunity scheine über den Prompt zu sprechen. Seine Überlegung war, dass er, wenn er gut genug für schwierige Mathematik sei, wahrscheinlich auch gut genug für Sicherheitsforschung sei. Er passte ihn an und richtete ihn auf WordPress.

Das Setup war bewusst eng gefasst. Er klonte die neueste stabile WordPress-Version in ein Verzeichnis namens main/ und löschte dessen .git-Verzeichnis, wobei er dem Modell sagte, es solle keine Changelogs, keine Git-Historie und nicht das offene Internet nutzen, um den Code mit einer gepatchten Version zu vergleichen — sein angegebener Grund war, dass für die Entdeckung neuartiger Schwachstellen das Konsultieren von Historie oder Web eine Verschwendung von Tokens sei. Ein leeres third_party/-Verzeichnis wurde angeboten, damit das Modell Abhängigkeiten wie PHP- oder MySQL-Quellcode klonen konnte, falls es befand, dass die Kette Bugs in den Bibliotheken unterhalb von WordPress brauchte. Die Aufgabe war als Pre-Authentication-RCE in einer typischen Produktionsbereitstellung auf MySQL spezifiziert, mit bis zu vier Agenten und mindestens sechs Stunden. Kues schrieb, dass er die Konfigurationsanforderung ausdrücklich angebe, weil Modelle ansonsten „schummeln“ — indem sie extrem unwahrscheinliche Konfigurationsoptionen wählen oder Vorbedingungen erfinden, die ein Angreifer niemals erreichen könnte.

Was in der laufenden Ausgabe zurückkam, war die Behauptung einer SQL-Injection vor der Authentifizierung. Kues zweifelte daran: WordPress gehöre zu den am intensivsten geprüften Zielen aller Zeiten und habe in jenem Jahrzehnt keine bedeutsame Schwachstelle vor der Authentifizierung gehabt, schrieb er. Er installierte eine Standard-WordPress-Instanz auf einem Remote-Server und bat das Modell, die E-Mail-Adresse des Administrators zu stehlen; innerhalb weniger Minuten gab es die Adresse aus, die er zum Einrichten der Instanz verwendet hatte. Dann fragte er, ob sich die Nur-Lese-Injection eskalieren lasse, und etwa vier Stunden später antwortete das Modell, dass dies möglich sei – zum Administrator, ohne ein Passwort zu knacken und ohne Offline-Berechnung.

Seine eigene Kostenrechnung: 50 % eines wöchentlichen Nutzungskontingents, das er mit ungefähr 25 US-Dollar anteilig auf ein Abonnement von 200 US-Dollar ansetzte, für einen Exploit, der in nur etwas mehr als zehn Stunden erstellt wurde. Der menschliche Teil war nicht kostenlos – Kues verbrachte den folgenden Tag damit, nachzuvollziehen, was das Modell getan hatte, und schrieb, dass er für das Verständnis der Post-Exploitation-Arbeit deutlich länger brauchte, als deren Erstellung gedauert hatte. Sein Urteil ist ungewöhnlich direkt und eng begrenzt: „Ich erhebe keine allgemeinen Ansprüche, aber ich kann mit völliger Sicherheit sagen, dass kein Sicherheitsforscher diese Exploit-Kette in 10 Stunden ohne KI hätte finden und abschließen können.“

Vom schreibgeschützten SELECT zum Administrator

Die Eskalation ist der Teil der Aufzeichnung, der am wichtigsten ist, denn dort wurde aus einem Datenbank-Lesevorgang die Kontrolle über den Server. Kues’ Schilderung stellt sie als Abfolge von sechs Schritten dar, bei denen jeweils eine gewöhnliche WordPress-Funktion gegen eine andere eingesetzt wird.

Zuerst den In-Memory-Post-Cache vergiften. WordPress unterhält einen Cache pro Anfrage für WP_Post-Objekte, sodass derselbe Post, auf den innerhalb einer Anfrage mehrmals verwiesen wird, nur einen Datenbank-Roundtrip kostet. Die SQL-Injection kann Posts fabrizieren, sodass der Angreifer genau kontrolliert, was im Cache landet – aber diese fabrizierten Posts sind keine Zeilen in der Datenbank, und der Cache geht mit der Anfrage verloren.

Zweitens: gefälschte Beiträge in echte Zeilen verwandeln. Die Embed-Funktion von WordPress speichert aufgelöste Einbettungen in der Datenbank als Beiträge vom Typ oembed_cache. Das Einbetten eines lokalen Beitrags über einen relativen Pfad, wie in [embed]/?p=S[/embed], führt dazu, dass WordPress den HTTP-Abruf überspringt und nie prüft, ob der referenzierte Beitrag existiert, sodass eine Zeile angelegt wird. Drei solcher Einbettungen mit unterschiedlichen Query-String-Tokens erzeugen drei unterschiedliche Cache-Hashes, und so erhält der Angreifer mehrere Zeilen, mit denen er arbeiten kann.

Drittens: Umgehen Sie das eine Feld, das unverändert bleibt.Wenn die In-Memory-Version und die Datenbankversion eines Beitrags nicht übereinstimmen, gleicht WordPress sie mit einem Aufruf ab, der ausdrücklich post_content aus der Embed-Ausgabe setzt. Alles an dem Beitrag ist vom Angreifer kontrolliert außer seinem Inhalt, und genau das ist das Feld, das ein customize_changeset verwendet, um das JSON ausstehender Theme- und Website-Änderungen zu speichern.

Viertens: das Zyklus-Gadget. Beiträge haben Eltern, und WordPress lehnt Zyklen ab: Der wp_insert_post_parent-Filter steigt im Baum nach oben und löst beim Finden einer Schleife ein Update aus, das post_parent auf null setzt. Dieser Aufruf überschreibt post_content nicht, sodass die fabrizierte In-Memory-Version den Abgleich überlebt — ein Changeset, dessen JSON intakt ist, gestützt auf eine echte Zeile.

Fünftens: die Befugnisse des Administrators ausleihen. Ein Changeset, dessen Status besagt, dass es für die Zukunft geplant ist, dessen Datum aber in der Vergangenheit liegt, wird sofort angewendet. Jeder Eintrag in seinem JSON nennt eine user_id, und der Eintrag in Kues’ Kette nennt user_id 1, den Administrator, sodass WordPress vorübergehend diese Identität annimmt, um die Änderung anzuwenden. Die erste Änderung ist eine harmlos wirkende Aktualisierung von nav_menus_created_posts.

Sechstens: Spielen Sie die Anfrage unter dieser Identität erneut ab. Das Veröffentlichen eines Beitrags löst eine dynamisch benannte Aktion aus, {status}_{post_type}. Da der Beitrag gefälscht ist, kann es sich bei diesem Status und Typ um alles Mögliche handeln – einschließlich parse und request, was den parse_request-Hook ergibt und die Anfragepipeline von vorn neu startet, während die ausgeliehene Administratoridentität weiterhin gilt. Die ursprüngliche Batch-Anfrage enthielt eine Unteranfrage, die einen neuen Administrator erstellt; sie schlug beim ersten Durchlauf als Gast fehl und gelingt bei der Wiederholung. Von dort meldet sich der Angreifer mit diesem neuen Konto an und lädt ein Backdoor-Plugin aus einer ZIP-Datei hoch, was Codeausführung bedeutet.

Die Technik ist an eine Bedingung geknüpft. The Hacker News berichtete unter Berufung auf Cloudflare, dass CVE-2026-63030 nur dann Remote-Code-Ausführung ermöglicht, wenn kein persistenter Objektcache verwendet wird; die Injection selbst ist ab WordPress 6.8 vorhanden, während die vollständige Kette 6.9 oder später erfordert. Eine Standardinstallation verfügt über keinen persistenten Objektcache, weshalb Searchlights Formulierung „keine Voraussetzungen“ und Cloudflares Einschränkung denselben Standardfall aus unterschiedlichen Richtungen beschreiben.

Was die Primärdokumente belegen

Die eigenen Sicherheitshinweise von WordPress sind die stärkste Bestätigung, denn hier räumt der Hersteller die Funktionsweise ein und liefert den Fix aus. GHSA-ff9f-jf42-662q, als kritisch eingestuft, beschreibt eine Schwäche durch Batch-Routen-Verwechslung in der REST-API von WordPress 6.9 und höher, die sich mit der Injection kombiniert, um Codeausführung zu erreichen, und bedankt sich bei Adam Kues von Assetnote und Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, als mittelschwer eingestuft, beschreibt die author__not_in-Injektion ab WordPress 6.8 und höher und stellt fest, dass beide Probleme in WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 und WordPress 7.1 beta2 behoben sind. Die NVD-Einträge für die beiden CVEs, bewertet vom WPScan-CNA statt von NIST, weisen 9.8 für CVE-2026-63030 mit dem Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H und 5.9 für CVE-2026-60137 mit AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N auf — im ersten Fall ein über das Netz erreichbarer Fehler, für den keine Privilegien erforderlich sind, und im zweiten ein Fehler, der eine hohe Angriffskomplexität erfordert und nur Auswirkungen auf die Vertraulichkeit hat. Das eigene Schweregradfeld des Archivs für diesen Eintrag lautet hoch, während WordPress die Batch-Schwäche als kritisch bezeichnet; dabei handelt es sich um zwei verschiedene Skalen, die auf eine ganze Kette und auf eine einzelne Komponente angewendet werden, nicht um eine Uneinigkeit über die Fehler selbst.

Die Katalogeinträge von CISA, wie sie in den Anreicherungsfeldern des NVD wiedergegeben werden, wurden am 21. Juli 2026 mit Behebungsfristen vom 24. Juli für CVE-2026-63030 und vom 4. August für CVE-2026-60137 hinzugefügt. CISA benennt die erste als „WordPress Core Interpretation Conflict Vulnerability“ und die zweite als „WordPress Core SQL Injection Vulnerability“. Searchlight veröffentlichte zudem unter wp2shell.com einen öffentlich zugänglichen Prüfer, damit Betreiber eine Instanz testen konnten, ohne auf eine Signatur eines Scanners warten zu müssen.

Die unabhängige Reproduktion ist von Searchlight selbst dokumentiert und daher eine Behauptung über Dritte statt eines Berichts Dritter: Calif und Hacktron haben die vollständige Kette nachgebaut, bevor andere Proofs of Concept auf GitHub erschienen, laut dem Bericht vom 20. Juli. Was sich unabhängig verifizieren lässt, ist der Effekt – Proofs of Concept, Exploitation-Traffic und Anbieter-Telemetrie innerhalb weniger Tage, weiter unten behandelt.

Was wird behauptet, aber nicht belegt?

Zwei Credits für eine Injection lassen sich im öffentlichen Bericht nicht in Einklang bringen. WordPress' Advisory für CVE-2026-60137 gibt an, die Schwachstelle sei „von TF1T, dtro und haongo als Team entdeckt und verantwortungsvoll offengelegt“ worden. Searchlights Darstellung präsentiert dieselbe Pre-Authentication-Injection als das, was sein Modelllauf zutage gefördert habe, und erwähnt dieses Team nicht; WordPress' Advisory schreibt Kues nur die Batch-Route-Verwechslung zu und erwähnt kein Modell. Keines der beiden Dokumente erklärt die Überschneidung, und nichts, was dieser Artikel ausfindig machen konnte, löst sie auf – die Möglichkeit, dass es sich um zwei unabhängige Funde desselben Fehlers handelte, ist nicht ausgeschlossen, und die Möglichkeit, dass ein Bericht eine spätere Wiederentdeckung ist, ist ebenfalls nicht belegt. Der Bericht entscheidet dies nicht, und dieser Artikel tut es ebenso wenig.

Die in der Schlagzeile von Searchlight vom 20. Juli genannte Zahl wird durch den eigenen Text nicht gestützt. Dort heißt es: „Exploit-Broker zahlen 500.000 US-Dollar für eine WordPress-RCE. Ich habe eine mit GPT5.6 Sol Ultra und 25 US-Dollar gefunden.“ Der Haupttext dokumentiert die 25 US-Dollar und die zehn Stunden mit konkreten Angaben; er enthält keine Namen von Brokern, keine Angebote, keine Korrespondenz und keine Quelle für die 500.000-Dollar-Zahl. Kein für diesen Artikel gefundener unabhängiger Bericht bestätigt einen für wp2shell gezahlten oder angebotenen Preis. Die 500.000 US-Dollar sind als Formulierung der Schlagzeile zu lesen, nicht als etablierter Marktpreis.

Der Geltungsbereich des Archiv-Eintrags selbst ist enger als die Geschichte um ihn herum. Er hält einen Forschungsbefund vom Tag der Offenlegung fest, kennzeichnet keinen realen Schaden und ist auf einen einzigen Tag datiert, den 17. Juli 2026. Das ist keine Aussage, dass danach nichts geschah: Innerhalb von Stunden nach der Warnmeldung wurde über Ausnutzungsverkehr berichtet, und CISA katalogisierte beide CVEs vier Tage später. Die Kennzeichnung umfasst, was der Eintrag beschreibt – die Entdeckung und die koordinierte Offenlegung – und die anschließende Ausnutzung wird von anderen Parteien anhand ihrer eigenen Belege unten dokumentiert.

Ausnutzung nach der Sicherheitsmeldung

Jake Knott, leitender Sicherheitsforscher bei watchTowr, sagte gegenüber The Hacker News: „Bis in die frühen Morgenstunden des Samstags (UTC) war eine erfolgreiche Ausnutzung bereits in vollem Gange; zunächst wurde öffentlicher Exploit-Code verwendet, um gehashte Anmeldedaten zu exfiltrieren, wobei Remote-Code-Ausführung folgte, sobald weitere Details öffentlich gemacht worden waren." Derselbe Bericht zitiert KEVIntel-Telemetrie, die 13 eindeutige IP-Adressen aus der Schweiz, Deutschland, dem Vereinigten Königreich, Indonesien, Litauen, den Niederlanden und Singapur mit der Ausnutzung von CVE-2026-63030 in Verbindung bringt, und zitiert KEVIntel-Gründer Ryan Dewhurst mit den Worten, dass die Anfragen mit öffentlich verfügbaren Proofs of Concept übereinstimmten und dass blinde, UNION-basierte und boolean-basierte Payloads allesamt verwendet wurden.

Die Forscher Shahar Dorfman und Gili Tikochinski von Wiz bezifferten in einer am 20. Juli veröffentlichten Analyse das Ausmaß: 60 % der Organisationen, die WordPress nutzen, hatten zum Zeitpunkt der Veröffentlichung der CVEs mindestens eine anfällige Instanz, und 25 % hatten einen anfälligen Server dem Internet ausgesetzt; innerhalb von 24 Stunden, als mit dem Patchen begonnen wurde, sanken diese Werte auf 50 % bzw. 10 %. Sie verzeichneten bösartige Plugin-Uploads über den Admin-Installer, Benutzer-Enumeration gegen den Users-Endpunkt, Local-File-Inclusion-Versuche gegen wp-config sowie Zugriffe auf das Admin-Panel, die HTTP 200 zurückgaben — die Signatur eines erfolgreichen Logins und nicht die einer Probe. Die gefundene Malware umfasste sowohl eine minimale einzeilige PHP-Backdoor als auch eine 150 KB große Webshell, die als legitimes WordPress-Sicherheitsplugin namens CMSmap getarnt war, mit Modulen für Dateiverwaltung, Datenbankzugriff, Port-Scanning und Rechteausweitung.

Wiz vermerkte außerdem eine Einschränkung hinsichtlich dessen, was daraus geschlossen werden kann. Scans mit hohem Volumen ohne Post-Exploitation waren verbreitet, was sowohl zu opportunistischem Massenscanning als auch zu legitimen Sicherheitsscans passt, und das Unternehmen erklärte, es habe keine laterale Bewegung und keine Datenexfiltration festgestellt. Das ist eine Aussage darüber, was die Telemetrie eines Herstellers gezeigt hat, keine Feststellung, dass nichts entwendet wurde.

Was änderte sich danach, und was blieb offen?

Für Betreiber war der Reaktionsweg kurz. Ein Update auf WordPress 7.0.2, WordPress 6.9.5 oder WordPress 6.8.6 ist die Lösung. Die Notfallalternativen von Searchlight für Websites, die nicht sofort aktualisieren konnten, bestanden darin, den anonymen Zugriff auf die Batch-API zu blockieren – entweder durch die Installation eines Plugins, das den anonymen Zugriff auf die REST-API vollständig blockiert, oder durch das Blockieren von /wp-json/batch/v1 und ?rest_route=/batch/v1 auf einer Web Application Firewall. Das Unternehmen warnte, dass beides die legitime Nutzung der Website beeinträchtigen kann und bis zum Vorliegen des Updates als vorübergehende Maßnahmen behandelt werden sollte. Der öffentliche Checker unter wp2shell.com testet eine Instanz direkt. Die Katalogeinträge von CISA fügten eine Compliance-Frist hinzu: Behebung bis 24. Juli für CVE-2026-63030 und bis 4. August für CVE-2026-60137.

Bei der Forschungsfrage ist der Teil, der sich nicht klären ließ, der Beitrag, den das Modell tatsächlich im Verhältnis zu seinem Betreiber geleistet hat. Kues ist präzise, was die Aufteilung angeht: Das Modell erzeugte die Kette in ungefähr zehn Stunden, und sie zu verstehen dauerte für ihn länger, als ihre Erzeugung gedauert hatte. Er lehnt allgemeine Aussagen ab und sagt nur, dass das Zehn-Stunden-Ergebnis von einem Menschen ohne Unterstützung nicht erreichbar gewesen wäre. Der Prompt selbst ist kein Geheimnis – er stammt von einem, den OpenAI veröffentlicht hat, und Searchlight hat seine Struktur in dem Bericht nachgebildet, einschließlich der Anweisung, die Versionshistorie zu ignorieren, und der Vorgabe, dass der Exploit in einer typischen Produktionskonfiguration funktionieren muss. Ob sich dieses Rezept auf andere Codebasen übertragen lässt, ist genau die Frage, die Kues nach eigener Aussage nicht beantwortet, und ein zweiter Durchlauf wurde nicht veröffentlicht.

Was die Aktenlage ungeklärt lässt, ist daher eng begrenzt, aber folgenreich: welche der beiden als Urheber genannten Parteien die Injection zuerst entdeckt hat, ob ein Broker die in der Schlagzeile genannte Summe jemals gezahlt hat und was, wenn überhaupt, die von Wiz beobachteten Webshells tatsächlich von den Websites mitgenommen haben, auf denen sie gelandet sind. Zum letzten Punkt gibt es öffentlich nur die Aussage von Wiz, dass es keine laterale Bewegung und keine Datenexfiltration festgestellt habe – ein Ausbleiben von Belegen aus einer einzigen Beobachtungsposition, das auch als solches vorgebracht wird.