StyleSmuggler: Magento zero-day actief misbruikt.

StyleSmuggler is een keten van twee stappen die elk afzonderlijk onschuldig zijn.

Stap 1: de aanvaller stuurt een ongeauthenticeerde request met een payload die Magento netjes wegschrijft naar het logbestand. Wat er in var/log/system.log belandt, is geldige PHP-code.

Stap 2: via een template directive kan de aanvaller kiezen welke class Magento instantieert, inclusief de constructor-argumenten. Die keten loopt door naar een autoloader uit de AWS SDK, die een opgegeven bestand simpelweg includet. Die autoloader controleert alleen of het bestand bestaat, nooit wat erin staat. En PHP maakt geen onderscheid tussen code- en tekstbestanden: alles tussen de PHP-tags wordt uitgevoerd, of het bestand nu .php of .log heet.

Magento logt dus de code, en een autoloader includeert het logbestand. Netto resultaat: unauthenticated remote code execution. Geen admin-account nodig, geen API-key, geen klik van een medewerker.

De eerste aannames zaten er trouwens naast. In de eerste uren dachten meerdere partijen dat het in de PayPal-module zat, omdat dat de zichtbare ingang was. De fout zit in de template parser. PayPal uitzetten of de Payflow-URL blokkeren stopt varianten niet — dat is later ook expliciet getest.

Magento Open Source en Adobe Commerce 2.4.6 tot en met 2.4.9. Het eerste slachtoffer dat Sansec vond draaide 2.4.6-p15 met de patches van juli en augustus 2026 netjes geïnstalleerd. Patchlevel zegt hier dus weinig: op het moment van de aanval was er simpelweg geen patch.

Bij het schrijven van dit bericht is er nog geen officiële Adobe-patch en nog geen CVE-nummer. Adobe heeft een security release gepland op 8 september, maar we verwachten niet dat StyleSmuggler daarin zit — die release stond al lang voor deze zero-day op de rol. Reken er dus op dat er later deze week nog een keer gepatcht moet worden zodra de echte fix er is.

Twee lagen deden het zware werk, en geen van beide had een patch nodig.

Hypernode werkte de WAF op hun platform bij met regels die dit aanvalsverkeer tegenhouden. Dat gold direct voor alle shops die daar draaien, zonder actie van ons of van jou. Daarbovenop draaien we voor al onze klanten Sansec Shield, dat al vanaf 07:15 UTC blokkeerde — ruim voordat er een patch, een CVE of zelfs een publieke writeup was.

In de tussentijd hebben we ook op applicatieniveau bescherming toegevoegd met een onofficiële community-patch. Die installeert als Magento-module en dicht drie ingangen: backend blocks in email template directives, validatie van de URL generator classes in grid rows, en het onschadelijk maken van PHP open tags in Web API error reports. Het is hardening, geen fix — maar het betekent dat we niet volledig van WAF-regels afhankelijk zijn.

Dat is precies waarom we die lagen standaard inrichten in plaats van er per shop over te discussiëren. Bij een zero-day is er geen patch om op te wachten. De vraag is dan niet of je gepatcht bent, maar hoe snel er iets voor je blokkeert en hoe snel je ziet dat er iets is binnengekomen.

Ben je bij ons klant? Dan ben je al veilig. Je hoeft niets te doen.

Staat je shop niet bij ons? Dan is dit het korte overzicht.

• Ga uit van "mogelijk geraakt" als je server online was in de nacht van 4 op 5 september, tot je het tegendeel hebt aangetoond. Niet omgekeerd.
• Zoek in je access logs naar requests met styles[ erin. Een 500-response op zo'n request is een bruikbaar detectiesignaal: dat is de include die stukliep.
• Controleer op processen die zich voordoen als kernel-threads (namen in blokhaken die niet van root zijn), cron-regels die er niet horen, en uitgaand verkeer naar onbekende hosts over ongebruikelijke poorten. Let op: de aanvallers wisselden binnen een dag van procesnamen en payload-hosts, dus vaste namen zijn een hint, geen checklist.
• Herstart niets en verwijder nog niets voordat je een backup voor forensisch onderzoek hebt. Een verwijderd binary dat nog draait, verlies je zo.
• Zet /graphql tijdelijk dicht op webserver- of firewallniveau als je het niet gebruikt. Gebruik je Hyvä Checkout of andere GraphQL-consumenten, dan is dat geen optie en moet je het van je WAF en de patches hebben.
• Pas de noodpatches toe die de DI-scanners CLI-only maken. Dat sluit de sink, ook voor POST-varianten die langs WAF-regels glippen.
• Voeg bescherming op applicatieniveau toe met de onofficiële community-patch. Installeert als module via composer, dicht drie ingangen. Test hem eerst op staging: het is een stop-gap zonder garanties.
• Roteer bij twijfel je credentials: admin-accounts, API-keys, database-wachtwoorden en integratie-tokens.
• Patch zodra Adobe met een fix komt, en houd Shield-updates in de gaten zolang er nieuwe entrypoints opduiken.

De les van dit weekend is niet "patch sneller". De eerste aanval was er een volle dag voordat iemand wist waar hij naar moest kijken, en het eerste slachtoffer was volledig gepatcht. Misbruik komt tegenwoordig vóór de ontdekking.

Wat dan wel werkt: lagen die er al staan voordat je ze nodig hebt, en iemand die op zaterdagmiddag meekijkt. In ons Magento Total Care abonnement zitten security patches, monitoring, Sansec Shield en dit soort incidentrespons gewoon inbegrepen. Geen losse offerte per noodgeval, geen discussie over wie er in het weekend aan de bak moet.

Vragen over je eigen shop? Bel of mail ons, ook als je geen klant bent.

Voor wie het na wil lopen: hoe dit weekend zich uur na uur ontrolde. Alle tijden in UTC.

• 4 sep, 22:20 — eerste bevestigde exploitatie. Een andere shop vindt later in eigen logs een treffer om 22:42. Op dat moment bestaat er nog geen publieke writeup: het misbruik loopt vóór de ontdekking.
• 4 sep, ~23:10 — een managed Magento-server wordt geraakt, vijftig minuten na de eerste.
• 5 sep, 00:59 — een van de getroffen partijen heeft het incident diezelfde nacht gecontaind en de kwetsbare sink in code dichtgezet. Nog steeds acht uur voordat er ergens een detectieregel bestaat.
• 5 sep, 07:15 — Sansec Shield begint met blokkeren. Geen patch, geen CVE, geen publicatie: puur op basis van waargenomen aanvalsverkeer.
• 5 sep, rond 11:50 — in de Magento-community komen de eerste meldingen binnen: verdachte achtergrondprocessen op onderling volledig losstaande shops. De enige gemeenschappelijke noemer is Magento op Hypernode. Kort daarna wordt het patroon duidelijk: een payload schrijft uitvoerbare PHP naar system.log. Hoe die code daarna wordt uitgevoerd, weet nog niemand.
• 5 sep, rond 11:55 — eerste noodgreep die rondgaat: de logbestanden symlinken naar /dev/null, na een backup voor forensisch onderzoek. Symptoombestrijding, maar het haalt de brandstof weg.
• 5 sep, 12:19 — Sansec publiceert het StyleSmuggler-onderzoek en geeft de kwetsbaarheid een naam. Rond hetzelfde moment wordt de volledige keten gereconstrueerd, inclusief de stacktrace die aantoont hoe het logbestand geïncludeerd raakt.
• 5 sep, ~12:54 — Sansec rolt via eComscan v1.9.6 een noodopruiming uit die de processen afschiet die zich voordoen als kernel-threads.
• 5 sep, rond 13:00 — herinfectie. Cron-regels en binaries komen binnen minuten terug op geraakte servers. Opschonen heeft geen zin zolang de ingang open staat.
• 5 sep, 14:57 — Hypernode rolt een platform-brede patch uit die het inkomende aanvalsverkeer tegenhoudt, gevolgd door opschoning van geraakte servers en extra endpoint security op die nodes.
• 5 sep, 22:28 — bij een getroffen shop wordt opnieuw een vergiftigd report weggeschreven. De keten voltooit niet, maar de payload-host, de procesnamen én de delivery vector zijn allemaal veranderd ten opzichte van de eerste golf. De aanvallers itereren in uren, niet in dagen.
• 5 en 6 sep — er komt een publieke mitigation repo met cleanup-guide en noodpatches die de kwetsbare DI-scanners CLI-only maken. In de community gaan Cloudflare WAF-regels rond. Sansec blijft Shield bijwerken naarmate ze alternatieve entrypoints vinden.
• 6 sep — de noodpatches worden getest tegen een werkende proof of concept op volledig gepatchte 2.4.6 en houden stand.
• 7 sep — nog geen officiële patch, nog geen CVE. De security release van Adobe staat gepland op 8 september.

• Sansec — StyleSmuggler research
• Disrex — technische analyse en noodpatches
• Mitigation repo met cleanup-guide en patches