StyleSmuggler (CVE-2026-75650): wat moet je nu doen?

CVSS 10.0. Geen inlog nodig. Actief misbruikt vóórdat er een patch bestond. Dat is StyleSmuggler, de kwetsbaarheid die sinds 4 september 2026 Magento- en Adobe Commerce-shops wereldwijd raakt. Beveiligingsbedrijf Sansec ontdekte de aanval, Adobe bracht op 7 september een noodpatch uit onder bulletin APSB26-146, en op 8 september zette CISA de kwetsbaarheid op zijn lijst van actief misbruikte kwetsbaarheden.

Dit is geen theoretisch risico. Aanvallers installeerden al een Rust-gebaseerde Linux-backdoor en PHP-webshells op gecompromitteerde shops, nog vóórdat Adobe een fix had. Hieronder de feiten, zonder overdrijving, en wat je er concreet mee moet doen.

Wat is StyleSmuggler (CVE-2026-75650) precies?

StyleSmuggler is een unauthenticated remote code execution-kwetsbaarheid (RCE) in Magento Open Source en Adobe Commerce, geregistreerd als CVE-2026-75650. Een aanvaller hoeft niet ingelogd te zijn en kan zonder enige vorm van authenticatie code op je server uitvoeren.

De naam komt van hoe de aanval werkt: PHP-code wordt "gesmuggeld" via style-properties in Magento's template-systeem, op een manier die bestaande beveiligingsfilters omzeilt. Volgens het onderzoek van Sansec gebeurt dit in twee stappen: eerst wordt kwaadaardige code opgeslagen via het template-systeem, daarna wordt die code uitgevoerd zodra Magento een bepaalde e-mailtemplate rendert, bijvoorbeeld de melding bij een mislukte betaling. Code-executie is ook buiten die e-mailflow mogelijk.

Welke Magento- en Adobe Commerce-versies zijn geraakt?

Volgens Adobe's eigen bulletin APSB26-146 gaat het om:

• Adobe Commerce 2.4.4 tot en met 2.4.9 (2026-aug en eerder)
• Magento Open Source 2.4.6 tot en met 2.4.9 (2026-aug en eerder)
• Adobe Commerce B2B 1.3.3 tot en met 1.5.3

Sansec meldt een breder bereik, namelijk elke 2.4.x-versie van 2.4.4 tot 2.4.9 voor zowel Commerce als Open Source, en vermeldt dat Scandiweb de fix heeft teruggeport naar 41 oudere releases (2.2.0 tot 2.4.3-p3). Sansec heeft die backport zelf niet beoordeeld. Bronnen verschillen dus licht in de exacte ondergrens. Conclusie: draai je enige 2.4.x-versie, ga uit van kwetsbaar totdat je de hotfix hebt bevestigd. Welke versie precies wanneer sowieso geen support meer krijgt, los van deze kwetsbaarheid, staat in Magento 2.4 versies en end-of-support.

De eerlijke versie: zelfs beveiligingsbedrijven zijn het niet volledig met elkaar eens over de exacte ondergrens. Dat is geen reden om te wachten op consensus. Het is een reden om bij twijfel te patchen in plaats van eerst een discussie over versienummers te voeren.

De aanduiding "2026-aug en eerder" in Adobe's bulletin verwijst naar de laatste reguliere patch-release vóór deze noodpatch. Heb je die augustus-release en alles daarvoor nog niet geïnstalleerd, dan loop je sowieso al achter op het reguliere onderhoud, los van StyleSmuggler. Dat is precies het soort achterstand dat een vaste upgrade-cyclus voorkomt.

Tijdlijn: hoe snel dit ging

Drie dagen tussen actief misbruik en een officiële patch is kort. Het is ook precies waarom zero-days gevaarlijker zijn dan reguliere kwetsbaarheden: er was geen inhaalslag mogelijk vóór de eerste aanvallen. Vanaf 7 september is "ik wist het niet" geen houdbaar argument meer.

Hoe werkt de StyleSmuggler-exploit?

Een aanvaller stuurt eerst een request met verborgen PHP-code naar een endpoint dat die waarde logt of opslaat via het template-systeem. Daarna triggert een tweede actie — vaak het automatisch verzenden van een e-mail bij een mislukte betaling — dat Magento die opgeslagen code daadwerkelijk uitvoert. Geen klik van een klant nodig, geen admin-toegang, geen social engineering.

Wat dit anders maakt dan een gemiddelde kwetsbaarheid: het misbruikt een bestaand, legitiem Magento-mechanisme (het e-mailtemplate-systeem) in plaats van een exotische edge case. Dat is waarom het zo breed en zo snel is uitgebuit.

Waarom template-engines een terugkerend doelwit zijn (CWE-1336)

De onderliggende zwakte heeft een eigen classificatie: CWE-1336, onvoldoende neutralisatie van speciale elementen in een template-engine. Dat is geen Magento-specifiek probleem. Elk systeem dat gebruikersinvoer ooit laat samenvloeien met een stuk tekst dat later als code wordt geïnterpreteerd, loopt dit risico.

Bij Magento zit het venster in het e-mailtemplate-systeem: een onderdeel dat van oorsprong bedoeld is om nette, opgemaakte e-mails te sturen, niet om willekeurige code uit te voeren. Dat maakt StyleSmuggler lastiger te detecteren dan een aanval op een duidelijk "gevaarlijk" onderdeel zoals een file-upload. Niemand controleert standaard of een mislukte-betaling-e-mail kwaadaardige code bevat.

Voor eigenaren van een shop betekent dit vooral: een WAF of virtuele patch die alleen bekende, voor de hand liggende aanvalsroutes blokkeert, is geen garantie tegen de volgende variant. Structurele updates blijven de basis, monitoring is de aanvulling, niet de vervanging.

Wat moet je nu doen: patch, scan, roteer

Drie stappen, in deze volgorde. Overslaan van stap 2 en 3 is de fout die we het vaakst zien.

1. Patch direct. Installeer hotfix VULN-39341 via repo.magento.com, of de composer-patch die bij jouw versie past. Bevestig de patchstatus met Magento's eigen patch-statustool. Dit sluit de deur voor nieuwe aanvallen, maar maakt een bestaande inbraak niet ongedaan.
2. Scan op compromittatie. Patchen is geen schoonmaak. Check op onverwachte PHP-bestanden onder pub/media, verdachte cron-entries, en processen die zich vermommen als reguliere Magento-processen. Is je shop al vóór 7 september 2026 live geweest op een kwetsbare versie, ga dan standaard uit van mogelijke compromittatie totdat je het uitgesloten hebt.
3. Roteer je encryption key en alle beschermde credentials. Admin-wachtwoorden, API-tokens, betaalcredentials en databasewachtwoorden die via Magento's encryption key zijn versleuteld. Een aanvaller met code-executie kan die key hebben uitgelezen, ook als je inmiddels gepatcht hebt.

Twijfel je of je shop al gecompromitteerd is of wil je dit traject niet alleen doorlopen? Via onze Magento support-dienst nemen we patch, scan en rotatie voor je uit handen.

Ben je al gehackt? Signalen om op te checken

Herken je een van deze signalen, behandel je shop dan als gecompromitteerd totdat bewezen is dat dat niet zo is:

• Onverklaarbare PHP-bestanden in map-structuren waar normaal alleen afbeeldingen staan, zoals pub/media.
• Cron-jobs die je zelf niet hebt ingesteld, of die op ongebruikelijke tijden draaien.
• Processen op de server die qua naam op een Magento-proces lijken, maar een afwijkend geheugengebruik of netwerkverkeer hebben.
• Onverwachte uitgaande verbindingen vanaf je server, passend bij een backdoor die "thuis belt".
• Klanten die melden dat betaalgegevens zijn misbruikt na een aankoop in jouw shop.

Een volledig stappenplan voor wat je doet zodra je zeker weet dat je shop is binnengedrongen, staat in Magento 2 gehackt — wat nu?. Hoe je structureel voorkomt dat de volgende kritieke kwetsbaarheid je weer verrast, staat in security patches installeren zonder downtime.

Kun je het risico tijdelijk afdekken terwijl je patcht?

Patchen heeft voorrang, maar niet elke shop kan dat binnen het uur regelen — denk aan extensies die eerst getest moeten worden tegen de hotfix. Voor die tussenperiode zijn er verzachtende maatregelen, geen vervanging van de patch zelf:

• WAF-regels. Volgens Sansec hebben zowel Cloudflare als Imperva regels uitgebracht die de bekende aanvalspatronen van StyleSmuggler blokkeren.
• Virtual patching. Gespecialiseerde Magento-beveiligingsdiensten zoals Sansec Shield bieden realtime blocking als extra laag.
• Tijdelijk uitschakelen van de getroffen e-mailtrigger is in theorie mogelijk, maar vraagt precies te weten welke code-paden je daarmee wel en niet afdekt. Zonder die zekerheid is dit geen vervanging voor de officiële hotfix.

Geen van deze maatregelen is een reden om de daadwerkelijke patch uit te stellen. Het zijn pleisters voor de uren of dagen die een zorgvuldige test van de hotfix nog kost, niet een alternatief ervoor.

De eerlijke versie: patchen is niet het eindpunt

Wat niemand je vertelt bij dit soort bulletins: een hotfix lost de kwetsbaarheid van dit moment op, niet de volgende. Sansec meldt al een vervolgkwestie in dezelfde categorie, Blockstrap (CVE-2026-103849), die niet wordt opgelost door de StyleSmuggler-hotfix alleen. Wie na deze patch weer achteroverleunt tot de volgende noodmelding, loopt dezelfde route opnieuw.

Een shop die structureel op een ondersteunde, actuele 2.4.x-versie draait met een vast patchritme, loopt dit soort noodtrajecten minder vaak en met minder schade. Daarover gaat Magento 2.4.x upgrade als dienst.

Samengevat

• StyleSmuggler (CVE-2026-75650) is een unauthenticated RCE in Magento Open Source en Adobe Commerce, CVSS 10.0, actief misbruikt sinds 4 september 2026.
• Geraakt: Adobe Commerce 2.4.4-2.4.9, Magento Open Source 2.4.6-2.4.9 (Sansec: breder, 2.4.4-2.4.9), B2B 1.3.3-1.5.3. Bij twijfel: patchen.
• Adobe's hotfix (bulletin APSB26-146) dicht het lek, maar maakt een bestaande inbraak niet ongedaan.
• Doe altijd drie dingen: patchen, scannen op compromittatie, en je encryption key plus beschermde credentials roteren.
• Er is al een vervolgkwestie (Blockstrap) bekend — structureel bijhouden van patches blijft nodig.

Veelgestelde vragen

Wat is StyleSmuggler (CVE-2026-75650)?

Een kritieke, unauthenticated remote code execution-kwetsbaarheid in Magento Open Source en Adobe Commerce. Een aanvaller kan zonder in te loggen code op je server uitvoeren via Magento's e-mailtemplate-systeem. CVSS-score: 10.0, het maximum.

Is mijn Magento-shop kwetsbaar voor StyleSmuggler?

Volgens Adobe's bulletin APSB26-146 geldt dit voor Adobe Commerce 2.4.4-2.4.9 en Magento Open Source 2.4.6-2.4.9. Sansec meldt een breder bereik tot 2.4.4 voor beide. Draai je een niet-gepatchte 2.4.x-versie, ga dan uit van kwetsbaar.

Is patchen genoeg, of moet ik meer doen?

Patchen alleen is niet genoeg als je al vóór 7 september 2026 live was op een kwetsbare versie. Scan dan ook op tekenen van compromittatie en roteer je encryption key en alle credentials die daarmee versleuteld zijn. Patchen sluit de deur, het maakt een eerdere inbraak niet ongedaan.

Waar vind ik de officiële patch voor CVE-2026-75650?

De hotfix (VULN-39341) staat als composer-patch op repo.magento.com en wordt beschreven in Adobe's bulletin APSB26-146. Bevestig na installatie de patchstatus met Magento's eigen patch-statustool.

Kan ik dit zelf oplossen, of heb ik hulp nodig?

Patchen kan een developer met Magento-ervaring in principe zelf. Scannen op compromittatie en het veilig roteren van een encryption key zonder de shop te breken, vraagt meer ervaring. Twijfel je, dan is het veiliger om dat door iemand te laten doen die dit al eerder deed. Neem contact op als je dit niet alleen wilt uitzoeken.