Unabhängige Belege für die Ausnutzung liefert die Magento-Hosting- und Entwicklungsfirma Disrex Group, die zwei kompromittierte Shops betreute sowie einen dritten, der angegriffen, aber nicht übernommen wurde. Gegenüber The Hacker News erklärte Disrex, beide betroffenen Shops liefen unter Magento Open Source und würden über die eigene Hosting-Marke RexHosting betrieben.
Store A lief auf 2.4.8 und war Kunde von Sansec Shield – das Modul war installiert, aktiviert und lizenziert. Der Treffer erfolgte um 23:10 UTC am 4. September, Stunden bevor Sansecs erste Blockierregeln für diese Lücke aktiv waren. Store B, kein Shield-Kunde, lief auf 2.4.7-p2, einem Patchstand von August 2024 und damit acht Stufen hinter dem aktuellen 2.4.7-p10; erster Treffer um 00:55 UTC am 5. September. Beide Shops wurden innerhalb des rund achtstündigen Fensters zwischen der ersten von Sansec beobachteten Ausnutzung und dem Bestehen einer Abwehr kompromittiert. „Der Patchstand war hier irrelevant, und das ist der Teil, den Händler am dringendsten hören müssen", so Disrex.
Laut Sansec arbeitet der Angriff zweistufig: Zunächst wird PHP-Code in eine Datei geschrieben, die Magento selbst anlegt, etwa beim Erzeugen eines Fehlerberichts. Anschließend bringt der Angreifer Magento dazu, diese Datei auszuführen, indem er die Standard-E-Mail „Payment Transaction Failed Reminder" auslöst. Der Code läuft beim Rendern der Nachricht – niemand muss sie öffnen, und der Angriff gelingt auch, wenn der Mailversand scheitert. Die vollständige Kette hat Sansec noch nicht veröffentlicht.
Das Implantat tarnt sich laut Sansec als Hintergrundprozess unter dem Namen [kworker/u:8:0]; die Binärdatei liegt unter ~/.local/share/.gvfsd/gvfsd-user im Home-Verzeichnis des Site-Benutzers, nicht im Web-Root, und ein Cron-Eintrag startet sie alle fünf Minuten neu. Disrex beschreibt sie als gestripptes, statisch gelinktes Rust-Programm von rund 1,9 MB für x86-64 und arm64; der Cron-Eintrag wird direkt in die Spool-Datei unter /var/spool/cron/crontabs/ geschrieben. In einem Shop stand dieselbe Zeile 1.728-mal, und nach dem Löschen fügte das Implantat sie binnen einer Sekunde wieder hinzu.
Auffällig: Auf einem der Shops baute das Implantat keinerlei ausgehende Verbindung auf. Es hielt 28 Verbindungen zur lokalen Redis-Instanz auf Port 6379 und las daraus Magentos Session-Speicher. Zwei Mitschnitte von jeweils über 200 MB enthielten kein einziges Paket an die von Sansec genannte Download- oder Steuerungsadresse.
Beide Shops liefen in isolierten Konten ohne sudo-Rechte; das Implantat lief als unprivilegierter Site-Benutzer. Disrex bestätigt keine Seitwärtsbewegung, keine Datenabflüsse, keine fremden Admin-Konten, keinen Payment-Skimmer und keine Datenbank-Hintertür. Die Eindämmung erfolgte am selben Tag, rund elf beziehungsweise vierzehn Stunden nach Erstkontakt; alle Sitzungen wurden invalidiert, Zugangsdaten werden vorsorglich rotiert.
Sansecs veröffentlichte Prüfung sucht in var/report/ nach dem Marker X_TRACE_. Disrex zufolge liefen beide eigenen Infektionen jedoch über var/log/system.log und wären übersehen worden – beide Verzeichnisse müssen also durchsucht werden. Zudem hat sich der Marker bereits verändert: Am Vormittag des 5. September sah Disrex einen Trigger-Header der Form X-TRACE- gefolgt von zehn Hex-Zeichen, am Nachmittag denselben Header ohne das Wort TRACE.
Ein eComscan-Lauf auf Store A um 10:00 UTC meldete den Shop als sauber, obwohl 1.728 Cron-Zeilen vorhanden waren – Ursache war laut Disrex der Scan-Pfad, der auf das Document Root zeigte, während das Implantat eine Ebene darüber lag. Sansec empfiehlt eComscan zur Erkennung; Version 1.9.7 beende den Prozess für Shield-Kunden.
Einen Herstellerfix gibt es nicht. Neben Sansecs GraphQL-Abschaltung existieren inoffizielle Gegenmaßnahmen von Disrex, ProxiBlue und Graycore sowie zwei Servereinstellungen: proc_open in disable_functions aufnehmen und /tmp, /var/tmp und /dev/shm mit noexec einhängen. Adobes nächste planmäßige Sicherheitsveröffentlichung ist laut Sansec der 8. September; ob sie den Fehler abdeckt, ist offen. Die Hoster Nexcess und Liquid Web veröffentlichten am 5. September gleichlautende Hinweise zu Vorsichtsmaßnahmen, ohne bestätigte Kundenkompromittierungen zu nennen. Disrex zählte 26 verschiedene Quelladressen; die in Sansecs Advisory genannte Einzeladresse hätte weniger als ein Viertel des Traffics gestoppt. Die Angreifer wurden bislang von niemandem benannt.