TrojanOrders, CosmicSting, SessionReaper: wat Magento-lekken ons leren

Drie kritieke Magento-lekken in drie jaar tijd. Bij alle drie lag de patch er al toen de massale aanvallen begonnen.

TrojanOrders (2022), CosmicSting (2024) en SessionReaper (2025) zijn technisch verschillend. Het patroon eromheen is opvallend gelijk. In dit artikel zetten we de drie naast elkaar, leggen we op hoofdlijnen uit hoe ze werkten en trekken we de lessen die voor elke Magento-shop gelden, ook voor die van jou.

Overzicht

We beschrijven alleen wat publiek bekend is en laten exploitdetails bewust achterwege. Het gaat hier om het patroon, niet om een handleiding.

TrojanOrders (CVE-2022-24086)

TrojanOrders was een template injection-kwetsbaarheid die via de checkout kon worden bereikt. Magento verwerkt e-mailtemplates met een eigen templatetaal. Als een aanvaller invoer kon laten verwerken als template in plaats van als gewone tekst, kon hij code laten uitvoeren op de server.

Wat dit gevaarlijk maakte:

• De aanval vroeg geen account of beheerrechten. Een bezoeker die iets kon invullen in de checkout was genoeg.
• De uitkomst was code-uitvoering op de server, dus volledige overname van de shop.
• Het werd massaal en geautomatiseerd misbruikt.

De les: invoer van een anonieme bezoeker mag nooit door een template engine of een interpreter lopen. Dit geldt voor je eigen maatwerk net zo goed als voor de core. Bij code reviews letten we op elk pad waar gebruikersinvoer in een template, een query of een shell-commando terechtkomt. Zie ook ons artikel over XSS voorkomen met de escaper.

CosmicSting (CVE-2024-34102)

CosmicSting was een XXE-kwetsbaarheid (XML External Entity) in Magento en Adobe Commerce, bekend geworden in juni 2024. Een XML-parser die externe entiteiten toestaat, kan worden gebruikt om bestanden van de server te lezen. In het geval van Magento is het meest waardevolle bestand app/etc/env.php, omdat daar de encryptiesleutel en databasegegevens staan.

Met die sleutel kon een aanvaller tokens vervalsen en zo toegang krijgen tot de API. Duizenden shops zijn geraakt. In combinatie met andere zwakke plekken kon de aanval verder escaleren.

Wat dit zo vervelend maakte: een patch installeren was niet genoeg. Als je shop al was uitgelezen vóór de patch, was de encryptiesleutel buiten. Dan moet je de sleutel vervangen, tokens ongeldig maken en controleren op achtergelaten toegang. Dat is een heel ander traject dan een composer-update. Meer over de voorzichtigheid die daarbij hoort, lees je in ons artikel over het beheren en roteren van de encryptiesleutel.

De les: een patch dicht het gat, maar repareert geen eerdere inbreuk. Wie te laat patcht, moet ervan uitgaan dat er is meegelezen.

SessionReaper (CVE-2025-54236)

SessionReaper kreeg een CVSS-score van 9.1. Het gaat om onjuiste inputvalidatie in de REST API van Magento. Gevolg: overname van klantaccounts, en code-uitvoering op de server, vooral bij shops die sessies als bestanden opslaan.

Adobe publiceerde de fix in september 2025 (bulletin APSB25-88). Het actieve misbruik begon eind oktober 2025, dus er zat weken tussen de patch en de massale aanvallen. Wie in die weken heeft gepatcht, had geen probleem. Wie wachtte op een rustig moment, kreeg er alsnog mee te maken.

De les: zodra een exploit in omloop komt, loopt het tempo van aanvallers veel sneller dan je release-cyclus. Een API-endpoint dat voor iedereen bereikbaar is, is een directe route naar binnen. Lees meer over het beveiligen van je API's.

Het patroon: waarom zoveel shops geraakt worden

Zet de drie lekken naast elkaar en je ziet dezelfde oorzaken:

1. Patchen duurt te lang. Er zit een gat tussen het uitkomen van de patch en het installeren ervan. Aanvallers gebruiken dat gat.
2. Er is geen vast ritme. Patches komen op onregelmatige momenten. Zonder proces wacht de update tot iemand tijd heeft.
3. Patchen voelt riskant. Shops met veel maatwerk en extensies zijn bang dat een update iets breekt. Dus stellen ze het uit.
4. Niemand is verantwoordelijk. Bij een bureau en een hostingpartij en een interne marketeer is het onduidelijk wie moet handelen.
5. Detectie ontbreekt. Shops merken een inbreuk pas weken later, via een creditcardmaatschappij of een klant.

Het is dus geen mysterieus technisch probleem. Het is een proces- en eigenaarschapsprobleem.

Het patchritme dat het had voorkomen

Voor alle drie de lekken had dit ritme volstaan:

• Kritieke beveiligingspatches binnen enkele dagen live. Niet binnen het volgende kwartaal. Een kritiek lek met een publieke exploit vraagt om een noodprocedure, geen sprintplanning.
• Een vaste routine voor de overige patches, bijvoorbeeld maandelijks, zodat de staging-omgeving altijd dicht bij productie ligt.
• Een staging-omgeving die er echt op lijkt, zodat je snel kunt testen.
• Een geautomatiseerde deploy, zodat een patch geen avondvullend project is. Zie Magento 2 security patches zonder downtime.
• Een melding van nieuwe Adobe-bulletins bij een vast aanspreekpunt, dat de eerste dag al een beslissing neemt.

Heb je een Magento-versie die geen security-updates meer krijgt, dan is patchen niet eens mogelijk. Controleer dat in ons overzicht van Magento 2.4-versies en end of support.

Wat als je te laat was?

Bij een vermoeden dat je geraakt bent, geldt een vaste volgorde:

• Neem de shop in maintenance mode als er actief misbruik is. Met bin/magento maintenance:enable is dat een kwestie van seconden.
• Maak een kopie van bestanden en database voor onderzoek voordat je iets opruimt.
• Controleer op nieuwe admin-gebruikers, gewijzigde bestanden en verdachte code in de database.
• Vervang wachtwoorden, API-sleutels en de encryptiesleutel, in de juiste volgorde en met een plan.
• Meld een datalek bij de Autoriteit Persoonsgegevens binnen 72 uur als er risico is voor betrokkenen (AVG art. 33).

De volledige stappen staan in Magento 2 gehackt: wat nu? en op onze pagina gehackt webshop.

Is elke patch een noodgeval?

Nee. Dat is een eerlijke nuance. Niet elke Adobe-bulletin vraagt om een nachtelijke actie. Veel patches gaan over lekken die ingelogde beheerders vereisen of die in specifieke configuraties spelen. Het onderscheid maken is werk, en daar zit de waarde van iemand die dagelijks met Magento werkt.

Als vuistregel kijken wij naar drie dingen:

• Is er misbruik zonder inloggen mogelijk?
• Is er een publieke exploit of actief misbruik?
• Raakt het een onderdeel dat jouw shop gebruikt?

Drie keer ja? Dan patchen we dezelfde dag. Anders volgen we het normale ritme. Een beslissing met een reden is beter dan standaard uitstellen.

Wat jij nu kunt doen

• Controleer welke Magento-versie en welk patchniveau je draait.
• Spreek af wie verantwoordelijk is voor het volgen van security-bulletins.
• Test of je een patch binnen een dag op staging én productie kunt krijgen. Lukt dat niet, dan is dat je eerste verbeterpunt.
• Zet detectie op: bestandswijzigingen, nieuwe admin-gebruikers, afwijkende orders. Zie incident response en monitoring.
• Loop de Magento 2 security checklist langs.

Wat de drie lekken gemeen hebben in de aanvalsketen

Kijk je naar de volgorde van gebeurtenissen, dan herhaalt het scenario zich elke keer:

1. Adobe of een onderzoeker publiceert een bulletin met een patch.
2. Binnen korte tijd analyseren anderen de patch en reconstrueren wat er mis was.
3. Er verschijnt een werkende exploit, eerst bij een kleine groep, daarna publiek.
4. Geautomatiseerde scanners zoeken het hele internet af naar kwetsbare shops.
5. Shops die nog niet zijn bijgewerkt, worden binnen uren of dagen geraakt.

De tijd tussen stap 1 en stap 4 wordt korter. Je kunt er niet op rekenen dat je weken hebt. Het venster waarin je kunt patchen zonder risico is het eerste, en dat is zelden meer dan enkele dagen.

Waarom shops niet snel genoeg patchen

Achter "traag patchen" zitten meestal een paar concrete oorzaken. Het helpt om ze te benoemen, want dan kun je ze weghalen:

• Geen goede staging. Als je niet snel kunt testen, voelt elke patch als een gok.
• Verouderde of onderhouden extensies die een upgrade blokkeren. Dan stapelt de achterstand zich op.
• Geen geautomatiseerde tests op de checkout. Handmatig testen kost een middag, dus het schuift door.
• Angst voor downtime. Terwijl een goed ingerichte deploy dat juist voorkomt.
• Een contract waarin patchen niet is opgenomen. Dan moet er per patch een offerte komen en dat vertraagt alles. Zie wat een goed onderhoudscontract bevat.

Geen van deze oorzaken is technisch onoplosbaar. Het zijn keuzes over proces en prioriteit.

Wat je nog meer kunt doen naast patchen

Patchen is de basis, maar je kunt de schade van het volgende lek beperken:

• Beperk de bereikbaarheid. Zet de admin achter een IP-beperking of VPN en blokkeer endpoints die je niet gebruikt.
• Gebruik een WAF die bekende aanvalspatronen filtert, zodat je tijd wint tussen publicatie en patch. Het is een vangnet, geen vervanging.
• Houd secrets uit het bereik. Wie env.php kan lezen, kan veel. Bestandsrechten en server-hardening verkleinen de impact.
• Sla sessies slim op. Sessies in Redis in plaats van in bestanden verkleinen een deel van het risico bij een lek als SessionReaper.
• Monitor. Een alarm bij een nieuwe admin-gebruiker of een gewijzigd bestand maakt het verschil tussen een dag en een maand onopgemerkt.

Geen van deze maatregelen vervangt snel patchen. Samen geven ze je lucht.

Veelgestelde vragen

Wat was TrojanOrders?

TrojanOrders (CVE-2022-24086) was een template injection-kwetsbaarheid in Magento die via de checkout kon worden bereikt. Het kon leiden tot code-uitvoering op de server en werd in 2022 massaal misbruikt.

Wat is er mis met CosmicSting?

CosmicSting (CVE-2024-34102) is een XXE-kwetsbaarheid uit juni 2024 waarmee bestanden van de server gelezen konden worden, waaronder de encryptiesleutel in env.php. Duizenden shops werden gehackt. Na patchen moet je ook controleren of de sleutel al is buitgemaakt.

Waarom is SessionReaper zo gevaarlijk?

SessionReaper (CVE-2025-54236, CVSS 9.1) zit in de REST API en maakt overname van klantaccounts mogelijk. Bij sessies in bestanden kan het ook leiden tot code-uitvoering. De fix staat in Adobe-bulletin APSB25-88.

Hoe snel moet ik een kritieke Magento-patch installeren?

Zodra een kritiek lek zonder inloggen te misbruiken is en er een publieke exploit bestaat, binnen enkele dagen en liefst dezelfde dag. Voor overige patches volstaat een vast maandelijks ritme.

Is patchen genoeg als ik al gehackt ben?

Nee. Een patch dicht het gat, maar haalt eerder geplaatste backdoors, admin-accounts en gelekte sleutels niet weg. Dan is een onderzoek en het vervangen van geheimen nodig.

Wil je dat iemand je patchproces doorloopt en vast onderhoud overneemt? Kijk bij Magento support of neem direct contact op via /contact.