Webshops draaien op software die continu onderhoud vraagt, maar soms is één detail genoeg voor een grote impact. Sansec meldt dat aanvallers een nieuwe, nog niet gepatchte kwetsbaarheid in Magento Open Source en Adobe Commerce misbruiken om zonder in te loggen malafide code op de webserver uit te voeren. Het resultaat is niet alleen een eenmalige inbraak, maar ook de installatie van een StyleSmuggler backdoor die blijft terugkomen.
Volgens Sansec begon de eerste golf van aanvallen op 4 september en publiceert het bedrijf de informatie alvast, omdat webshops op dat moment al werden gecompromitteerd. Adobe heeft op het moment van de melding nog geen eigen advisory, CVE-nummer, patch of tijdelijke oplossing gepubliceerd.
Wat is StyleSmuggler en waarom is het ernstig?
De kern van de melding is dat een succesvolle aanval leidt tot code execution op de server van de webshop. Daarna wordt een persistente backdoor geplaatst: de aanvaller probeert de toegang duurzaam te maken, zodat het systeem niet simpelweg “terugkomt” naar normaal zodra een sessie eindigt.
Sansec stelt dat alle huidige versies zijn getroffen, met concrete voorbeelden zoals 2.4.9. Daarnaast zegt Sansec de volledige aanvalsketen te hebben nagebootst op schone installaties van Magento Open Source 2.4.7, 2.4.8 en 2.4.9.
Ongeauthenticeerde aanval: code draait zonder inloggen
Een bijzonder punt in de beschrijving is dat de aanval niet begint met inloggen. Sansec schetst een twee-fasenaanpak:
- Stap 1: de aanvaller plant PHP-code in een bestand dat Magento zelf kan schrijven, bijvoorbeeld tijdens het genereren van een failure report.
- Stap 2: de aanvaller laat Magento de code uitvoeren door een standaard workflow te triggeren: de “Payment Transaction Failed Reminder”-mail.
Belangrijk: de code draait terwijl Magento de boodschap verwerkt. Daardoor is het theoretisch mogelijk dat de aanval zelfs slaagt wanneer e-mailbezorging faalt; niemand hoeft de mail “handmatig” te openen.
Welke versies zijn geraakt volgens Sansec?
Sansec zegt dat alle huidige versies in principe kwetsbaar zijn. Het bedrijf noemt onder meer Magento Open Source 2.4.9 als getroffen en beschrijft ook een specifiek slachtoffer dat draaide op 2.4.6-p15, wel met Adobe’s beveiligingsupdates uit juli en augustus 2026 toegepast.
Voor versie 2.4.6 geeft Sansec aan dat dit de meest recente patchstand is voor die release-lijn en dat Adobe die stand labelt zoals in de augustus bulletinvermelding. Toch bleef de aanval mogelijk, wat de urgentie vergroot.
Adobe Commerce: nog onduidelijk, maar misbruik gebeurt wel
Sansec heeft nog geen reproduceerbare keten gepubliceerd voor Adobe Commerce of Adobe Commerce on Cloud, en Adobe heeft nog niet bevestigd welke versies precies geraakt zijn. Ook ontbreekt informatie over het aantal gecompromitteerde winkels.
Daar staat tegenover dat een incident-response partij, Disrex Group, melding maakt van daadwerkelijk waargenomen compromissen: twee shops waren gecompromitteerd en een derde was wel aangevallen, maar niet doorgebroken. Disrex zegt daarbij onafhankelijk dezelfde soort sporen te hebben gezien.
Hoe ziet de StyleSmuggler backdoor eruit?
Sansec beschrijft de implant als een achtergrondproces dat zich vermomt onder de naam [kworker/u:8:0], terwijl die naam normaal hoort bij een Linux kernel thread. De echte binary wordt geïnstalleerd in de home-directory van de webservergebruiker, niet in de webroot.
Verder draait het mechanisme met cron. De cron-entry wordt elke vijf minuten herstart, waardoor de backdoor blijft terugkomen. Volgens Disrex is de cron niet als vervangende crontab gemarkeerd, maar direct weg geschreven via spoolmechanismen, waardoor logs er anders uit kunnen zien dan je verwacht bij “gewone” crontab-aanpassingen.
Concrete detectie-indicatoren (IOCs)
Sansec publiceert een set indicatoren. Hieronder staan de belangrijkste categorieën, zodat je kunt vergelijken wat je in logs en op systemen ziet. Let op: dit zijn indicatoren, geen definitief bewijs op zichzelf.
- Process: [kworker/u:8:0] (eigendom van een niet-root gebruiker)
- Bestanden: onder meer ~/.local/share/.gvfsd/gvfsd-user en bijbehorende lock-bestanden
- Cron: periodieke herstart met een commando naar de gvfsd-user locatie (met varianten richting /tmp)
- Hashes (SHA-256): meerdere voorbeelden zijn gepubliceerd, waaronder een sample van Sansec en verschillende versies “op schijf” versus “in geheugen”
- Netwerk: onder meer een downloadhostdomein en IP-adressen gerelateerd aan command-and-control
Sansec noemt daarnaast een scanner (eComscan) als detectiemiddel voor Shield-klanten, waarbij versie 1.9.7 het proces zou termineren voor geabonneerde omgevingen.
Actiepunten als je webshop draait op Magento of Adobe Commerce
Er is op het moment van de publicatie geen officiële vendor-fix beschikbaar. Dat betekent dat je nu vooral moet denken in beperken, detecteren en incident-response.
1) Beperk de aanvalskans: GraphQL uitschakelen (tijdelijk)
Sansec’s interim advies voor winkels die niet draaien met hun Shield-product: disable GraphQL tot er een tijdelijke fix beschikbaar is. Disrex nuanceert dit: headless en progressive web app storefronts hebben GraphQL meestal nodig, terwijl klassieke en Hyvä storefronts dat vaak niet doen.
2) Blokkeer exploitverkeer op webserver-niveau
Disrex publiceert nginx- en Apache-regels die verzoeken blokkeren wanneer de exploitparameters in de URL query string staan. De tests geven daarbij een belangrijk leermoment: als dezelfde parameters via POST of een JSON body worden aangeleverd, zien nginx en Apache die query-string niet op dezelfde manier en kan de request toch PHP bereiken.
De conclusie van Disrex is daarmee vooral: serverregels helpen tegen de campagne zoals die op dat moment loopt, maar ze “patchen” de kwetsbaarheid niet volledig.
3) Hardening-aanpak in Magento dependency-injection scans
Een van de mitigaties van Disrex is een aangepaste guard om drie methodes in Magento’s dependency-injection code scanners te beschermen. Het doel is te voorkomen dat scanners buiten de command-line context kunnen worden uitgevoerd.
Disrex geeft ook aan dat één van de betrokken bestanden (ClassesScanner.php) door ten minste één derde partij module wordt aangeroepen, wat problemen kan veroorzaken voor de admin-interface. Daarom adviseert Disrex beheerders om in hun vendor-directory te zoeken voordat ze deze wijziging doorvoeren.
4) Extra serverlaag: PHP proc_open en noexec voor uitvoerbare downloads
Naast “application-level” hardening noemt Disrex twee serverinstellingen die niet afhangen van het precies kennen van de volledige exploit chain:
- Voeg proc_open toe aan PHP disable_functions, zodat de dropper een proces niet kan starten.
- Moun t /tmp, /var/tmp en /dev/shm met noexec, zodat gedownloade binaire bestanden niet uitgevoerd kunnen worden.
5) Als je denkt dat je al besmet bent: volg een zorgvuldige opschoonvolgorde
Voor incident-response geeft Disrex een volgorde die rekening houdt met bewijs en met het feit dat de backdoor zichzelf herstelt. Zo zegt Disrex expliciet dat je eerst bewijs veiligstelt, daarna pas de cron-entry verwijdert en het proces stopt. Ook adviseert Disrex om niet meteen te herstarten, omdat een kopie onder /proc mogelijk de laatste “live” versie van de binary is.
Daarna: flush session opslag en roteer geheimen. Disrex noemt het flushen van sessions en het roteren van onder meer crypt/key in app/etc/env.php, plus alle admin wachtwoorden en API-keys van betaalproviders en andere integraties die in dat bestand staan.
Daarnaast waarschuwt Sansec voor het draaien van schoonmaakacties zoals “composer install” tijdens het opruimen, omdat die timestamps kan overschrijven en daarmee forensische sporen minder betrouwbaar kan maken.
Wat je kunt leren uit deze aanval
De StyleSmuggler backdoor laat zien hoe een e-commerce platformketen kan worden misbruikt via normale “functionality” zoals e-mailtemplating en systeemlogs. Ook toont het incident dat patching alleen niet genoeg is: als de exploit nog niet door de vendor is afgedekt, moet je met detectie en beperkingen werken.
Als je meer wilt lezen over hoe uitbraken zich in webomgevingen kunnen uiten, dan sluit ons eerdere artikel over phishing met onzichtbare Unicode om filters te omzeilen goed aan bij het thema: aanvallers zoeken routes langs de “standaard” mechanismen van je omgeving.
Samenvatting: houd StyleSmuggler hoog op je prioriteitenlijst
Sansec meldt een actieve exploit die leidt tot server-side code execution in Magento Open Source en Adobe Commerce, gevolgd door de installatie van een StyleSmuggler backdoor. De aanval is ongeauthenticeerd, en de persistente component werkt via cron zodat toegang kan blijven terugkeren.
Zolang Adobe nog geen officiële patch of workaround publiceert, zijn de meest praktische stappen: GraphQL tijdelijk uitzetten waar mogelijk, webverkeer gericht blokkeren op basis van de aanvallogica, en server- en Magento-hardening toepassen. Denk daarnaast direct aan detectie en incident-response, inclusief het veiligstellen van bewijs en het roteren van sleutels en credentials bij een vermoeden van compromittering.
Bron: https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html
