Aanvallers maken misbruik van een nieuwe, nog niet gepatchte kwetsbaarheid Magento Opensource en Adobe Commerce waarmee ze kwaadaardige code op de server van een online winkel kunnen uitvoeren zonder in te loggen, zei het Nederlandse e-commerce beveiligingsbedrijf Sansec in een advies dat op 5 september werd gepubliceerd.
Sansec, die de fout ontdekte en deze een naam gaf Stijlsmokkelaarzei dat de aanvallen op 4 september begonnen. “Sansec publiceert vroeg omdat winkels momenteel worden gecompromitteerd”, aldus het bedrijf.
Vanaf 6 september heeft Adobe geen advies, CVE-identifier, patch of oplossing gepubliceerd, en de Adobe Commerce-beveiligingsbulletin-index vermeldt niets na de update van 11 augustus.
Bij een succesvolle aanval kan de aanvaller code uitvoeren op de server van de winkel en wordt een permanente achterdeur geïnstalleerd. Sansec zei dat alle huidige versies getroffen zijn, inclusief 2.4.9, en dat het de volledige niet-geverifieerde keten reproduceert op schone Magento Open Source-installaties van 2.4.7, 2.4.8 en 2.4.9.
Het eerste slachtoffer draaide versie 2.4.6-p15 met de beveiligingsupdates van juli en augustus 2026 van Adobe toegepast, wat het nieuwste patchniveau is dat Adobe biedt voor die releaselijn en een patch die in het augustusbulletin 2.4.6-2026-aug wordt genoemd.
Sansec heeft geen reproductie gepubliceerd op Adobe Commerce of op Adobe Commerce on Cloud, en Adobe heeft niet bevestigd om welke versies het gaat. Sansec heeft niet gezegd hoeveel winkels zijn gecompromitteerd.
Het tussentijdse advies van de onderzoekers voor winkels die het Shield-product niet gebruiken, is om GraphQL uit te schakelen totdat Adobe een tijdelijke oplossing uitbrengt.
Disrex-groepeen Magento-hosting- en ontwikkelingsbedrijf dat reageerde op twee van de gecompromitteerde winkels, merkt op dat headless en progressieve web-app-storefronts GraphQL vereisen, terwijl de meeste klassieke en Hyvä-storefronts dat niet doen.
De volgende geplande beveiligingsrelease van Adobe is op 8 september, zei Sansec, en het is nog niet bekend of die release deze bug zal verhelpen.
De bevindingen van Disrex zijn onafhankelijk bewijs van uitbuiting van buiten Sansec. In een op 5 september gepubliceerde repository voor incidentenreacties zegt het bedrijf dat het twee winkels heeft afgehandeld die op 5 september zijn gecompromitteerd en een derde die is aangevallen maar niet is geschonden, en dat de webserverregels zijn gebaseerd op aanvalsverkeer dat is vastgelegd op een van de gecompromitteerde winkels.
Die winkel draaide Magento 2.4.7-p2, een beveiligingspatchniveau waarvan de versiegeschiedenis van Adobe dateert tot augustus 2024, acht niveaus achter de huidige 2.4.7-p10. De winkel Disrex-labels Winkel A was een klant van Sansec Shield en werd op 4 september om 23:10 UTC getroffen, uren voordat de eerste blokkeringsregels van Sansec van kracht gingen.
De repository heeft zijn eigen waarschuwing. “Deze repository is binnen een paar uur met behulp van AI geschreven tijdens een live-incident”, zegt de README, eraan toevoegend dat de repository niet is beoordeeld, dat de Apache-regels nooit tegen een live Apache-server zijn uitgevoerd en dat de meeste opruimcommando’s zijn geschreven in plaats van uitgevoerd.
De indicatoren van Sansec beschrijven het implantaat als een vermomd achtergrondproces (kworker/u:8:0)een naam die hoort bij een Linux-kernelthread, met een binair bestand geïnstalleerd op ~/.local/share/.gvfsd/gvfsd-user onder de homedirectory van de sitegebruiker in plaats van in de webroot, en een cron-invoer die hem elke vijf minuten opnieuw opstart.
Disrex beschreef het binaire bestand als een gestript, statisch gekoppeld Rust-programma van ongeveer 1,9 MB gebouwd voor x86-64 en arm64, en zei dat de cron-invoer rechtstreeks naar het spoolbestand onder /var/spool/cron/crontabs/dus het systeemlogboek toont geen vervanging van de crontab.
Eén winkel had dezelfde lijn 1.728 keer, en het implantaat voegde deze binnen een seconde na verwijdering opnieuw toe.
In een van de twee winkels maakte het implantaat helemaal geen uitgaande verbinding. Het had 28 verbindingen met de eigen Redis-instantie van de winkel op poort 6379. Het las de sessieopslag van Magento ervan, zei Disrex, en geen van de twee pakketopnamen, elk groter dan 200 MB, werd in beslag genomen. Tegelijkertijd was het implantaat live en bevatte het een enkel pakket naar de downloadhost of het command-and-control-adres dat Sansec vermeldde.
Sansec zei dat voor Shield-klanten die werden aangevallen voordat de regels live gingen, het geen aanwijzingen heeft dat de achterdeur daadwerkelijk werd gebruikt, en adviseerde het Magento-inloggegevens te wisselen waar het proces ook is geïdentificeerd.
Volgens de schets van Sansec werkt de aanval in twee fasen. Het plant eerst PHP-code in een bestand dat Magento zelf schrijft, bijvoorbeeld bij het genereren van een storingsrapport. Vervolgens zorgt het ervoor dat Magento dat bestand uitvoert door de standaard e-mail “Betalingstransactie mislukt herinnering” van het platform te activeren. De code wordt uitgevoerd terwijl Magento het bericht weergeeft, zodat niemand het hoeft te openen en de aanval kan slagen, zelfs als de e-mailbezorging mislukt.
Sansec heeft de volledige exploitatieketen nog niet gepubliceerd en zei dat een uitsplitsing van de keten, de druppelaar en het implantaat in een update zullen volgen.
Disrex’ lezing van de keten, gepubliceerd in een mechanismebeschrijving naast de regels ervan, is dat een richtlijn binnen de geïnjecteerde tekst een reeks van Magento’s eigen klassen in code aanstuurt die uitsluitend bestaat om de compiler voor afhankelijkheidsinjectie op de opdrachtregel te bedienen.
Die code eindigt met het opnemen van een bestandspad dat de aanvaller heeft gekozen: het logboek dat een moment eerder is vergiftigd. De uitgevoerde PHP-dropper probeert achtereenvolgens zes PHP-functies om een proces te starten, downloadt en start vervolgens het implantaat. Disrex noemt drie bestanden onder setup/src/Magento/Setup/Module/Di/Code/ als het punt waar de keten eindigt. Sansec heeft deze lezing niet bevestigd en Disrex publiceert het verzamelde verzoek niet.
Voor de eerste fase zijn twee locaties van belang. Sansec’s gepubliceerde cheque-zoekopdrachten var/report/ voor de markering X_TRACE_. Disrex zei dat beide infecties waren vergiftigd var/log/system.log in plaats daarvan en zou door die controle zijn gemist, dus beide mappen moeten worden doorzocht.
De marker is al verschoven: Disrex zag een triggerheader van het formulier X-TRACE- gevolgd door tien hexadecimale tekens op de ochtend van 5 september en dezelfde header zonder het woord TRACE tegen de middag, dus een zoekopdracht moet overeenkomen met de vorm en niet met de exacte string.
Een typefout van array_merge() met een geheel getal-argument in system.logonmiddellijk na de opname, is het bewijs dat de exploit is geslaagd, zei Disrex. Een onopvallende variant retourneert echter een lege array en laat niets achter in het logbestand.
Voor het proces zei Disrex dat een echte kernelthread eigendom is van root en geen intern geheugen heeft, dus een naam tussen haakjes op de sitegebruiker met echt geheugengebruik is het implantaat. Het implantaat stelt zijn opdrachtregel in op de letterlijke reeks tussen haakjes, zodat er een controle wordt geschreven tegen die van het proces comm veld komt met niets overeen.
Disrex ontdekte ook dat het binaire bestand dat in het geheugen van de ene winkel draait een andere build was dan het bestand op schijf, en adviseert om het lopende proces te hashen vanaf /proc/ evenals het bestand. Onverwachte uitbarstingen van ‘Betalingstransactie mislukt herinnering’-e-mails zijn een reden om onderzoek te doen, zei Sansec, hoewel legitieme geweigerde betalingen dezelfde melding genereren.
De volgende indicatoren zijn gepubliceerd door Sansec en in de indicatorenlijst van Disrex:
- Proces:
(kworker/u:8:0)eigendom van een niet-rootgebruiker - Bestand:
~/.local/share/.gvfsd/gvfsd-user - Bestand:
~/.local/share/.gvfsd/.gvfsd_<8hex>.lock - Bestand:
/tmp/.gvfsd_<8hex>.lock - Bestand:
/tmp/.kw_ - Cron:
*/5 * * * * execmet een variant die wijst naar/.local/share/.gvfsd/gvfsd-user /tmp/.kw_ - SHA-256:
e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7(Sansec’s voorbeeld) - SHA-256:
8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef(op schijf in beide Disrex-winkels) - SHA-256:
251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220(draait in het geheugen van één Disrex-winkel) - Domein:
247.cdnflare(.)xyz(host voor het downloaden van malware) - IP-adres:
99.84.67(.)186:443(command-and-control over WebSocket en TLS, per Sansec) - IP-adres:
88.216.72(.)181(bron van de aanvaller, volgens Sansec) - IP-adres:
5.181.86(.)133(aanvallerbron verzendt bulk, per Disrex)
Sansec beveelt zijn eComscan-scanner aan om het implantaat te detecteren, en genoemde versie 1.9.7 zal het proces voor Shield-klanten beëindigen.
Disrex rapporteerde het tegenovergestelde resultaat voor één winkel: eComscan draaide met de achtergrondprocessen en controles van geplande taken ingeschakeld terwijl het implantaat live was, met 1.728 cron-lijnen aanwezig, en rapporteerde dat de winkel schoon was. Disrex zei niet welke eComscan-versie draaide en wanneer.
Er is geen oplossing van een leverancier om te installeren. Totdat Adobe er één op de markt brengt, zijn de opties de tijdelijke afsluiting van GraphQL door Sansec; drie onofficiële maatregelen gepubliceerd door Disrex, ProxiBlue en Graycore; en twee serverinstellingen die niet afhankelijk zijn van de fout.
Disrex publiceerde nginx- en Apache-regels die verzoeken blokkeren die de parameters van de exploit in de URL-queryreeks bevatten. Zijn eigen test in een live winkel toonde de limiet aan: dezelfde parameters die in een POST-body werden verzonden, bereikten PHP, net als een JSON-body, omdat nginx en Apache alleen de querystring inspecteren, zei Disrex. Disrex beschrijft de regels als het stoppen van de campagne zoals deze momenteel loopt, en niet als de kwetsbaarheid.
De belangrijkste oplossing van Disrex voegt een controle toe aan drie methoden in de afhankelijkheidsinjectiecodescanners van Magento, waardoor wordt voorkomen dat ze buiten de opdrachtregel worden uitgevoerd. De handmatige bewerking wordt bij elke installatie van de componist ongedaan gemaakt, dus Disrex verzendt het ook als een bronpatch voor componist-patches die opnieuw van toepassing is bij implementatie en, zo staat er, onveranderd van toepassing van 2.4.6 tot en met 2.4.9.
Eén van de drie bestanden, ClassesScanner.php, wordt via HTTP aangeroepen door ten minste één module van een derde partij, mageplaza/module-admin-permissions, en door deze te bewaken wordt het beheerdersscherm van die module verbroken, dus vertelt Disrex beheerders dat ze hun leveranciersdirectory moeten doorzoeken voordat ze deze aanraken.
De bewaker werd getest op een harnas in plaats van in een hardloopwinkel, en Disrex zegt dat het op zichzelf geen volledige oplossing is. Een GitHub-gebruiker, ProxiBlue, publiceerde dezelfde bewaker op 5 september, samen met drie onofficiële patches. Noch Sansec, noch Adobe hebben bevestigd dat deze scanners het punt zijn waar de keten eindigt.
Graycore, LLC publiceerde op 5 september een Magento-module op GitHub en Packagist waarvan de huidige code, zegt Graycore, drie punten in de keten verhardt: de e-mailsjabloonblokrichtlijn weigert backend-blokken, de rasterrij-URL-generator controleert een klasse voordat deze wordt gebouwd, en PHP-openingstags in fatale foutrapporten van de Web API zijn kapot.
De versie op Packagist was op het moment van schrijven een eerdere release waarvan de enige oplossing gericht was op een PayPal GraphQL-resolver die inmiddels is verwijderd. De README zegt: “Dat is een verharding, geen oplossing” en waarschuwt dat andere paden door de kwetsbaarheid open blijven en dat een winkel mogelijk al in gevaar is gebracht.
Twee serverinstellingen zijn helemaal niet afhankelijk van het kennen van de keten, zei Disrex. In een van de twee winkels waren de eerste vier van de zes PHP-functies die de dropper probeerde uitgeschakeld; proc_open Dat was niet het geval, en de druppelaar gebruikte het om het implantaat te starten open_basedir niets doen om het kindproces in bedwang te houden.
Toevoegen proc_open naar PHP’s disable_functionsen montage /tmp, /var/tmp En /dev/shm met noexec zodat een gedownload binair bestand niet kan worden uitgevoerd, zijn de lagen die Disrex vóór elke regel in zijn repository plaatst.
Voor een winkel die al is geïnfecteerd, bepaalt de opruimgids van Disrex de volgorde: bewaar eerst het bewijsmateriaal, verwijder de cron-invoer voordat je het proces beëindigt omdat het proces het herstelt, start niet opnieuw op omdat de kopie onder /proc kan het enige overgebleven binaire bestand zijn en voer composer install niet uit om op te ruimen, omdat het de tijdstempels overschrijft die laten zien wat er is aangeraakt.
Vervolgens wordt aanbevolen de spoelsessie op te slaan, aangezien het implantaat dit leest, en de rotatie te draaien crypt/key in app/etc/env.phpevenals elk beheerderswachtwoord, elke API-sleutel van de betalingsprovider en elke andere integratiereferentie in dat bestand.
Hostingproviders Nexcess en Liquid Web plaatsten op 5 september identieke incidentmeldingen, waarin ze verklaarden dat ze hun serveromgevingen aan het herzien waren en voorzorgsmaatregelen namen.
Geen van beide claimt een bevestigd compromis voor de klant of een eigen reproductie van de fout. Disrex registreerde 26 verschillende bronadressen in zijn twee winkels, waarvan er twee een infrastructuur hosten die bulk verzendt en de rest een residentiële proxypool die elk twee tot zes verzoeken verzendt, en zei dat het blokkeren van het adres van de enkele aanvaller in het advies van Sansec minder dan een kwart van het verkeer dat het zag, zou hebben tegengehouden. Geen enkele bron heeft de aanvallers genoemd.
The Hacker News heeft contact opgenomen met Adobe, Sansec, Disrex en Graycore voor commentaar en zal het verhaal bijwerken als we iets horen.
