StyleSmuggler en recente aanvallen op Magento-winkels: hoe hackers te werk gaan en hoe u het risico beperkt

7 september 2026 9 min leestijd 2 weergaven

De afgelopen dagen hebben iets laten zien wat beheerders van webshops al lang weten, maar wat in het dagelijkse beheer gemakkelijk wordt genegeerd: een actueel systeem betekent niet altijd een veilig systeem. Wanneer er een 0-day-kwetsbaarheid verschijnt, wachten aanvallers niet op een officiële melding van de leverancier, een netjes toegewezen CVE-nummer en een geschikt moment om de patch te installeren. Bots scannen het internet, zoeken naar kwetsbare endpoints en proberen sneller persistente toegang te installeren dan de meeste bedrijven een vergadering kunnen beleggen.

Dat is precies wat er speelt bij StyleSmuggler, een actief misbruikte kwetsbaarheid die op 5 september 2026 door Sansec is gemeld. Volgens Sansec begonnen de aanvallen op 4 september en hebben ze betrekking op Magento Open Source en Adobe Commerce. De belangrijkste informatie voor winkeleigenaren is hard: de kwetsbaarheid werd ook waargenomen op installaties die als volledig bijgewerkt werden beschouwd.

Deze tekst is geen aanvalshandleiding. Het is een praktische samenvatting van hoe een moderne inbraak in een e-commercewinkel eruitziet en wat u hier en nu kunt doen, voordat er een officiële patch van de leverancier verschijnt of wordt bevestigd.

Wat is er gebeurd?

StyleSmuggler wordt beschreven als ongeautoriseerde RCE, oftewel de mogelijkheid om code op de server uit te voeren zonder in te loggen op het beheerpaneel. Simpel gezegd: de aanvaller heeft geen adminwachtwoord, geen overgenomen medewerkersaccount en geen SSH-toegang nodig. Een kwetsbare applicatie die vanaf internet bereikbaar is, volstaat.

Volgens openbare analyses bestaat de aanval uit meerdere fasen:

De aanvaller stuurt een gemanipuleerd verzoek naar Magento via het GraphQL-endpoint.
Kwaadaardige code komt terecht op een plek die Magento later zelf verwerkt.
De applicatie voert de code uit tijdens het standaardmechanisme voor het verwerken van e-mailberichten, onder meer bij een scenario met een betalingsfout.
Op de server wordt een backdoor geïnstalleerd, dus een persistent mechanisme om terug te keren.

Dit is een bijzonder gevaarlijk model, omdat er geen klik op een link door een medewerker en geen geslaagde inlogpoging nodig is. De winkel kan uitsluitend worden aangevallen omdat deze publiek toegankelijk is.

Hoe werken hackers tegenwoordig?

Inbraken in webshops lijken steeds minder vaak op het handmatig 'hacken' van één doelwit. Vaker ziet het eruit als een geautomatiseerde campagne:

het internet scannen op zoek naar een specifiek endpoint,
kant-en-klare pogingen versturen om de kwetsbaarheid te misbruiken,
een proces installeren dat zich voordoet als een legitiem onderdeel van het systeem,
toegang behouden via cron of een ander autostartmechanisme,
sessies, secrets, API-sleutels of betaalgegevens verzamelen,
eventueel een webshell, skimmer of extra backdoor installeren.

Bij StyleSmuggler zijn vooral twee details belangrijk. Ten eerste kan de backdoor zich buiten de winkelmap bevinden, waardoor een gewone controle van de Magento-bestanden niet voldoende is. Ten tweede kan het proces zich voordoen als een systeemonderdeel, bijvoorbeeld met een naam die lijkt op kworker, fc-cache of chronyd. Voor een ongetraind oog ziet dat er onschuldig uit, maar als het onder de webgebruiker draait, moet er een waarschuwingslampje gaan branden.

Waarom is alleen het patchniveau niet genoeg?

Bij een gewone kwetsbaarheid is het antwoord eenvoudig: we controleren de versie, voeren een update uit en sluiten het onderwerp af. Bij een 0-day is de situatie anders. Gedurende een bepaalde periode wordt de kwetsbaarheid misbruikt voordat de leverancier een patch publiceert, of voordat de patch eenduidig aan een specifieke aanval wordt gekoppeld.

Daarom moeten na zo’n incident twee vragen van elkaar worden gescheiden:

is de winkel nog steeds kwetsbaar?
is de winkel eerder al gecompromitteerd?

Dat is niet hetzelfde. Een WAF, een blokkade van GraphQL of een latere patch kan volgende pogingen beperken, maar verwijdert niet automatisch een backdoor die eerder kan zijn geïnstalleerd.

Wat moet u direct doen?

1. Beperk of schakel GraphQL tijdelijk uit

Als de winkel geen gebruikmaakt van GraphQL, is de eenvoudigste beslissing om /graphql tijdelijk te blokkeren totdat er een bevestigde patch is. Veel klassieke Magento-winkels, waaronder veel implementaties op basis van Hyvä, hebben geen publieke GraphQL nodig voor de werking van de frontend. Bij headless- en PWA-winkels ligt dat anders: daar kan een blokkade de verkoop stilleggen, waardoor nauwkeurigere WAF-regels of verkeersbeperkingen nodig zijn.

Een voorbeeldrichting voor nginx:

map $uri $gql_block { default 0; ~*^/+(index\.php/+)?graphql(\.php)?(/|$) 1;}

In elke Magento-vhost, vóór de overige location-blokken:

if ($gql_block) { return 403;}

Na het wijzigen van de configuratie:

nginx -t && systemctl reload nginx

Als Varnish vóór de winkel draait, is het verstandig om daarnaast de cache te legen:

varnishadm ban 'req.url ~ .'

Na de implementatie moet u verschillende varianten van het pad controleren, niet alleen het ideale /graphql. De test moet onder meer /graphql, /GraphQL, /graphql/, /graphql.php, /index.php/graphql en varianten met dubbele slashes omvatten. Het verwachte resultaat voor GraphQL is 403, en voor de homepage van de winkel een normale respons, bijvoorbeeld 200.

2. Blokkeer de bekende vector `styles[...]`

Als u niet heel GraphQL kunt uitschakelen, pas dan ten minste regels toe die de waargenomen parameter styles[...] in de query string en bekende post-exploitatiepatronen blokkeren.

Voor nginx kunnen regels in deze richting worden gebruikt:

if ($query_string ~* 'styles(\[|%5[bB])') { return 403;}if ($request_uri ~* '/paypal/transparent/response/.*(eval|base64_decode|%3[cC]%3[fF])') { return 403;}if ($request_uri ~* '%3[cC]%3[fF]|<\?') { return 403;}

Voor Apache kan een vergelijkbaar mechanisme worden gebaseerd op mod_rewrite, waarbij ruwe en gecodeerde voorkomens van styles[ en pogingen om een PHP-tag in de URL te smokkelen worden geblokkeerd.

Belangrijke kanttekening: zulke regels zien de URL en de query string. Als een variant van de aanval de payload volledig naar de body van een POST-verzoek verplaatst, is alleen een webserverregel mogelijk niet voldoende. Dan is een WAF nodig die de body analyseert, ModSecurity, een oplossing zoals Sansec Shield of het tijdelijk uitschakelen van GraphQL.

3. Controleer of de winkel al is overgenomen

Het blokkeren van nieuwe pogingen is pas de helft van het werk. De andere helft is controleren of de aanval al sporen heeft achtergelaten.

Voer de controle uit als de systeemgebruiker van Magento:

crontab -l | grep -i gvfsdls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache 2>/dev/nullps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'grep -ril 'x_trace_' var/report/

Let vooral op:

bestanden in ~/.local/share/.gvfsd/,
fc-cache-bestanden op ongebruikelijke locaties,
tijdelijke mappen zoals /tmp/.kw_*, /tmp/.cache_*, /tmp/.fc-*,
cron-items die om de paar minuten worden uitgevoerd,
processen die zich voordoen als systeemprocessen, maar draaien als de winkelgebruiker,
PHP-bestanden in pub/media, waar ze normaal niet zouden moeten staan.

Voorbeeld van een snelle controle op webshells:

find pub/media -name '*.php' -print

Als het resultaat niet leeg is, moet dit als een incident worden behandeld en niet als een cosmetische afwijking.

4. Controleer de toegangslogs

Zoek in de logs naar pogingen gericht op GraphQL en naar ongebruikelijke verzoeken naar betaalpaden. De aanwezigheid van een verdacht verzoek betekent niet altijd een succesvolle inbraak, maar laat wel zien dat de winkel een doelwit was.

In de praktijk is het verstandig om te controleren op:

POST-verzoeken naar /graphql met ongebruikelijke parameters,
voorkomens van styles[ en de gecodeerde variant styles%5B,
verzoeken naar /paypal/transparent/response/ met verdachte fragmenten,
plotselinge reeksen verzoeken vanaf veel IP-adressen,
verkeer vanaf adressen die bekend zijn uit openbare IOC’s.

In werkmateriaal worden onder meer de volgende IOC’s genoemd: 185.157.160.251, 99.84.67.186, windwsecurity.run, ntp.timesync.to. Beperk de verdediging echter niet alleen tot deze waarden. Volgens incidentbeschrijvingen kwam een deel van het verkeer uit een grotere pool van adressen en tussenliggende infrastructuur.

5. Stel eerst bewijs veilig, ruim daarna op

Dit is een veelgemaakte fout: de beheerder ziet een verdacht proces, beëindigt het, verwijdert bestanden en begint pas daarna met de analyse. Bij een goed geschreven backdoor kan dit de belangrijkste sporen vernietigen en soms zelfs het terughalen van een sample bemoeilijken.

De volgorde moet conservatiever zijn:

Stel nginx-/Apache-, PHP-FPM-, systeem-, Magento- en cron-logs veilig.
Leg de lijst met processen, geopende bestanden en netwerkverbindingen vast.
Maak een kopie van verdachte bestanden voor analyse.
Verwijder cron-items die verantwoordelijk zijn voor het opnieuw starten van het proces.
Stop pas daarna processen en verwijder persistentie-mechanismen.
Dwing gebruikers- en beheerderssessies om uit te loggen.
Roteer secrets: crypt/key, adminwachtwoorden, API-sleutels voor betalingen, integraties, SMTP, ERP, PIM en marketplace.

Als de winkel betalingen of klantgegevens verwerkt, moet een bevestigde compromittering worden behandeld als een volledig beveiligingsincident, niet als een gewone 'virusverwijdering'.

Enkele principes die het risico daadwerkelijk verkleinen

Minimaliseer het publieke aanvalsoppervlak

Endpoints die de winkel niet gebruikt, zouden niet publiek toegankelijk moeten zijn. Dit geldt voor GraphQL, beheerderspanelen, stagingomgevingen, oude demodomeinen en vergeten kopieën van de winkel. In e-commerce is het heel vaak niet de productieomgeving die verliest, maar een oude stagingomgeving met een echte database en dezelfde secrets.

Scheid omgevingen en rechten

Het Magento-proces zou niet meer toegang moeten hebben dan nodig is. Geen sudo, een apart systeemaccount voor elke winkel, scheiding van Redis, afzonderlijke databases en beperkte uitgaande communicatie kunnen een compromittering van één winkel veranderen in een beperkt incident in plaats van een ramp voor de hele infrastructuur.

Monitor processen, cron en bestanden buiten de webroot

Alleen de Magento-map scannen is niet genoeg. Een backdoor kan zich bevinden in de homedirectory van de gebruiker, in /tmp, in de fontcache of op een andere plek die toegankelijk is voor het applicatieproces. Monitoring moet onder meer omvatten:

nieuwe cron-items,
ongebruikelijke processen onder de webgebruiker,
nieuwe uitvoerbare bestanden in tijdelijke mappen,
verbindingen naar Redis, databases en internet,
wijzigingen in app/etc/env.php,
nieuwe beheerdersaccounts.

Update, maar verwar updaten niet met incidentanalyse

Wanneer Adobe een patch publiceert, moet die worden geïnstalleerd. Maar na een 0-day-aanval beantwoordt alleen het installeren van de patch niet de vraag of iemand al binnen was. Daarom moet u na de patch nog steeds IOC’s, logs, sessies en secrets controleren.

Bereid kant-en-klare noodregels voor

Het is verstandig om in de repository of operationele documentatie kant-en-klare fragmenten voor nginx, Apache, Varnish en WAF te hebben. In een crisis is er geen tijd om regels vanaf nul te schrijven. Het testen van blokkades op staging voordat ze op productie nodig zijn, is ook een goede praktijk.

Wat moet een winkeleigenaar vandaag doen?

Als u Magento of Adobe Commerce draait, voer dan minimaal het volgende uit:

Maak een lijst van alle instanties: productie, staging, demo en werkkopieën.
Controleer waar GraphQL publiek toegankelijk is en of het daadwerkelijk nodig is.
Implementeer een tijdelijke GraphQL-blokkade of regels die styles[...] blokkeren.
Verifieer de blokkade met HTTP-tests.
Doorzoek de server op processen, cron, bestanden en logs die op StyleSmuggler wijzen.
Als u IOC’s vindt, stel bewijs veilig en behandel de zaak als een incident.
Werk na de officiële patch van de leverancier elke instantie bij, ook staging en oude kopieën.
Voer na de update opnieuw een controle en rotatie van secrets uit als de winkel gecompromitteerd kan zijn.

De slechtste beslissing is wachten tot 'de zaak duidelijk wordt'. Bij een actief misbruikte 0-day werkt tijd in het voordeel van de aanvaller. Zelfs een tijdelijke blokkade kan, als die goed is getest en bewust is geïmplementeerd, waardevolle uren opleveren.

Samenvatting

StyleSmuggler is een goed voorbeeld van modern risico in e-commerce: de aanval begint niet bij het adminpaneel, maar bij een publiek endpoint; eindigt niet met één bestand in de winkelmap, maar met een persistent proces buiten de webroot; en een actueel patchniveau geeft niet automatisch antwoord op de vraag of de winkel veilig was tijdens het aanvalsvenster.

De verdediging moet net zo praktisch zijn: het oppervlak beperken, de bekende vector blokkeren, compromittering controleren, bewijs veiligstellen, secrets roteren en pas daarna het onderwerp als onder controle beschouwen.

In zulke situaties wint niet degene met het mooiste beveiligingsbeleid, maar degene met kant-en-klare procedures, logs, gescheiden omgevingen en de mogelijkheid om snel noodregels te implementeren zonder het hele bedrijf stil te leggen.

Bronnen en materialen

Sansec: https://sansec.io/research/stylesmuggler-0day
The Hacker News: https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html
Adobe Security Bulletin voor Adobe Commerce: https://helpx.adobe.com/security/products/magento/apsb26-138.html