Clop hat eine neue Onion-Adresse angekündigt; die alte Domain soll übergangsweise erreichbar bleiben und danach abgeschaltet werden. Zugleich weist die Gruppe jede Verbindung zu ShinyHunters zurück: „Wir kennen sie nicht, wir haben nie mit ihnen zusammengearbeitet, und derzeit stehen wir nicht mit ihnen in Kontakt; außerdem haben wir ihnen keinerlei Informationen gegeben und werden das auch künftig nicht tun", erklärte Clop gegenüber BleepingComputer.
Die Behauptung, es seien wertvolle operative oder finanzielle Daten abgeflossen, bestreitet die russischsprachige Gruppe. „Wir haben das Grav-Plugin nicht aktualisiert – auch wenn es irgendwann passiert ist –, aber auf dem Server befanden sich nur Inhalte (es gab dort absolut keine Daten oder Finanzaktivitäten, und es hätte sie auch nicht geben können). Ihre Behauptung ist daher wertlos – genau wie ihre Worte", so Clop.
Auffällig ist, dass Clop mittlerweile still von der Leak-Seite von ShinyHunters entfernt wurde – ein Vorgang, der üblicherweise auf laufende Verhandlungen hindeutet, obwohl Clop jeden Kontakt bestreitet. Auf Nachfrage von BleepingComputer wollte ShinyHunters dazu keine weiteren Fragen beantworten.
Technisch lief der Angriff nach Darstellung von ShinyHunters über Grav CMS in Version 1.7.43. Die Gruppe sprach von einer Schwachstelle beim Datei-Upload über Formulare, die ohne Authentifizierung ausgenutzt werden kann: Der verwundbare Code übernahm Werte aus formularbezogenen POST-Parametern, um temporäre Upload-Verzeichnisse anzulegen, ohne sie zuvor als sichere Pfadbestandteile zu prüfen. Konkret benannte ShinyHunters den Parameter unique_form_id, dessen Wert in einen temporären Pfad eingefügt wurde.
Mit Traversal-Sequenzen wie ../../../shhq als eindeutiger Formularkennung ließ sich Grav laut der Gruppe dazu bringen, einen Upload-Pfad außerhalb des vorgesehenen Verzeichnisses tmp/forms anzulegen. Die hochgeladene Datei konnte damit an anderer Stelle innerhalb der Grav-Installation abgelegt werden.
Nachdem BleepingComputer die technischen Details an Grav weitergegeben hatte, bestätigten die Entwickler die Darstellung: „Ja, das ist eine echte Schwachstelle, und die Beschreibung des Bedrohungsakteurs ist zutreffend." Die Lücke wird als CVE-2026-42608 geführt, wurde vertraulich gemeldet und in Grav 2.0 (2.0.0-beta.2) behoben; das Advisory erschien am 27. April. Der Fix ergänzte eine Funktion sanitizeId(), die nur noch Kennungen aus einer Positivliste akzeptiert – exakt die Gegenmaßnahme, die auch ShinyHunters gegenüber BleepingComputer beschrieben hatte.
Das Problem lag im älteren Zweig: Der Fix war nicht auf Grav 1.7 zurückportiert worden. „Die Lücke war die 1.7-Linie", sagte Grav. „Grav 2.0 ist die aktuelle Hauptversion, aber viele Seiten laufen noch auf 1.7, und dort war der Fix noch nicht zurückportiert." Inzwischen haben die Entwickler das nachgeholt und Grav 1.7.53.4 veröffentlicht.
Grav stellte zudem klar, dass der Fehler im Kern der Software steckt und nicht im Form-Plugin: „Der Bug lebt im Grav-Core, nicht im Form-Plugin, deshalb ändert die Version des Form-Plugins (7.3.0 in ihrem Beispiel) nichts daran, ob eine Seite verwundbar ist. Entscheidend ist die Core-Version." Betreiber des 1.7-Zweigs sollen auf 1.7.53.4 aktualisieren; Nutzer aktueller 2.x-Versionen sind seit Monaten geschützt.