Magento extensies veiligheid: het supply chain risico

In april 2025 meldde Sansec dat 21 Magento extensies van drie vendors dezelfde backdoor bevatten. De code zat in pakketten uit 2019 tot 2022. Hij werd pas in 2025 actief. Volgens Sansec ging het om 500 tot 1000 webshops.

De les is simpel. Je Magento core kan perfect gepatcht zijn en je shop is toch open. Elke extensie draait met dezelfde rechten als de rest van je code.

Dit artikel gaat over magento extensies veiligheid: hoe een extensie een aanvalsroute wordt, hoe je een extensie beoordeelt en hoe je je Composer-keten onder controle houdt.

Wat er in 2025 gebeurde

Sansec vond identieke kwaadaardige code in 21 extensies van Tigren, Meetanshi en Magesolution (MGS). De pakketten werden verspreid via de officiële downloadservers van die vendors. Volgens de publieke berichtgeving waren die servers op enig moment gecompromitteerd.

De backdoor zat in een licentiebestand (License.php of LicenseApi.php). De functie adminLoadLicense() voerde door een aanvaller aangeleverde PHP-code uit, vermomd als licentiecontrole. Daarmee kan een aanvaller admin-accounts aanmaken, data stelen of een skimmer plaatsen. Sansec zag actief misbruik vanaf 20 april 2025.

Let op de details:

• De code lag jaren slapend.
• Het ging om betaalde extensies van de officiële vendor, niet om een dubieuze download.
• De vendors reageerden verschillend. Meetanshi erkende een serverinbraak, maar ontkende dat de extensies geraakt waren. Tigren ontkende compromittering. MGS reageerde volgens de berichtgeving niet.

Dit is een publiek gedocumenteerd voorbeeld. De actuele stand per vendor kan veranderd zijn, dus controleer die bij Sansec zelf.

Hoe een onveilige Magento extensie je shop raakt

Een extensie is geen plug-in in een afgeschermde ruimte. Het is PHP die in je codebase draait. Er zijn vier routes.

1. Kwaadaardige code van de vendor. Zoals hierboven: een gehackte buildserver of downloadserver levert besmette code.
2. Kwetsbaarheid in goede code. Een admin controller zonder ACL-check, een SQL-query zonder binding, een upload zonder validatie. Geen opzet, wel RCE of data-lek.
3. Verlaten pakketten. De vendor stopt, een kwetsbaarheid wordt nooit gefixt en jij draait nog versie 1.2 uit 2020.
4. Dependencies van de extensie. Een extensie trekt via Composer andere pakketten binnen. Daar zit je composer dependencies security ook in.

Een supply chain aanval op Magento werkt dus op twee niveaus: de extensie zelf en alles wat die meebrengt.

Een extensie beoordelen voor je hem installeert

Een demo en vijf sterren zeggen niets over veiligheid. Dit toets je wel.

Vendor en patchhistorie

• Hoe lang bestaat de vendor en hoeveel Magento-versies heeft hij bijgehouden?
• Publiceert de vendor security-fixes in een changelog, of verdwijnen ze stil in een "bugfix"-release?
• Zoek de extensienaam op in publieke advisories en bij Sansec. Zoek ook op de vendornaam.
• Is er een contactpersoon voor security-meldingen?

Een vendor zonder patchhistorie is geen veilige vendor. Het kan ook betekenen dat niemand heeft gekeken.

Code review van de risicoplekken

Je hoeft niet alles te lezen. Begin bij de plekken waar het misgaat.

• Admin controllers: hebben ze ADMIN_RESOURCE en een echte ACL-regel?
• Frontend controllers en REST/GraphQL endpoints: wat kan een anonieme bezoeker aanroepen?
• Bestanden met licentie-, update- of "phone home"-logica: precies waar de backdoor uit 2025 zat.
• eval, base64_decode, unserialize, exec, shell_exec: elk gebruik vraagt om uitleg.
• Uitgaande requests: met welke externe domeinen praat de extensie en waarom?
• Database-toegang: $connection->query() met string-concatenatie is een rode vlag.

Laat dit door een developer doen die Magento kent. Een generieke malwarescan vindt dit niet.

Rechten en bereik

• Welke ACL-rechten registreert de extensie?
• Schrijft hij bestanden buiten var/ en pub/media?
• Heeft hij cron jobs of CLI-commando's die je niet nodig hebt?

Update cadence en licentie

• Verschijnt er minstens bij elke Magento-minor een compatibele release?
• Kun je de code inzien (open source, of leverancier geeft broncode)?
• Mag je de code laten reviewen en patchen? Sommige licenties verbieden dat.
• Wat gebeurt er met je licentie als de vendor stopt?

Checklist: extensie vetting in een tabel

Een extensie met drie rode vlagen installeer je niet. Zo simpel is de regel.

Composer onder controle houden

De meeste extensies komen via Composer binnen. Dat is een voordeel. Je kunt het beheersen.

Houd composer.lock reproduceerbaar

• Commit composer.lock altijd naar Git.
• Installeer in CI en op productie met composer install, niet met composer update.
• Gebruik vaste versies of strakke constraints voor extensies. Vermijd * en dev-master.
• Update bewust, per pakket, in een aparte branch met een diff van composer.lock.
• Bouw artifacts één keer en deploy dezelfde build naar elke omgeving.

Zo krijg je een verschil te zien als een pakket onverwacht verandert. Bij een nieuwe release controleer je de diff voordat je mergt.

Gebruik composer audit

composer audit
composer audit --abandoned=report

Twee kanttekeningen:

• Het vindt alleen wat in de advisory-database staat. Een betaalde extensie van een kleine vendor staat daar vaak niet in. Een schone audit betekent dus niet dat je veilig bent.
• Ondersteuning voor verlaten pakketten (--abandoned) hangt af van je Composer-versie. Controleer de release notes van de versie die je draait.

Zet composer audit als vaste stap in je pipeline. Laat de build falen bij een advisory. Wil je uitzonderingen, leg ze dan vast in composer.json zodat ze zichtbaar zijn in review.

Wees voorzichtig met repositories

• Controleer welke private repositories (Magento Marketplace, vendor-repo's) in composer.json staan.
• Bewaar auth-gegevens in auth.json, nooit in Git.
• Een vendor-repo die ineens een andere URL of ander domein gebruikt, is een reden om te stoppen en te vragen waarom.

Verwijder wat je niet gebruikt

Een uitgeschakelde module is nog steeds code op je server. Een uitgeschakelde module met een kwetsbaarheid in een publiek bereikbaar bestand blijft een risico.

Doe dit elk kwartaal:

1. Maak een lijst van alle modules (bin/magento module:status).
2. Zet er per module bij: wie gebruikt dit, wat levert het op?
3. Verwijder wat niemand gebruikt met composer remove, niet alleen module:disable.
4. Test op staging en deploy.

Elke extensie minder is een aanvalsvlak minder. Dit kost een middag en lost meer op dan een nieuwe tool.

Monitoring: aannemen dat het toch een keer misgaat

Preventie faalt weleens. Zorg dat je het merkt.

• File integrity monitoring: meld wijzigingen in app/code, vendor/ en pub/. Op productie hoort code niet te veranderen buiten een deploy.
• Nieuwe admin-gebruikers: alarm bij elke nieuwe admin-account.
• Uitgaand verkeer: log naar welke domeinen je server verbindt.
• Checkout en CSP: let op onbekende scripts, dat is het patroon van skimmers. Een Content Security Policy en een reportingstroom helpen hierbij.
• Advisories volgen: abonneer je op meldingen van de vendors die je gebruikt en op de Magento security-bulletins.

Een backdoor die jaren slaapt, merk je alleen met monitoring op gedrag. Een scan op één moment is niet genoeg.

Kopen of bouwen: ook een veiligheidsvraag

Meer extensies betekent meer vreemde code. Een eigen module van 300 regels voor één functie heeft een kleiner aanvalsoppervlak dan een extensie met 40 functies waarvan je er twee gebruikt.

Maar zelf bouwen is geen automatische veiligheid. Je moet het ook onderhouden, testen en patchen. De eerlijke versie: koop wat standaard en breed gebruikt is (betalingen, vergelijkbare modules met een zichtbare community), bouw wat klein en specifiek is.

Lees de afweging in kopen of zelf bouwen van een extensie. Voor de kostenkant zie extensiekosten en budgettering. Reken het onderhoud van een extensie mee: reviews en updates zijn onderdeel van de prijs.

Waar dit in je beveiligingsaanpak past

Extensies zijn één onderdeel. Core-patches, hosting, toegangsbeheer en back-ups horen er ook bij. De Magento 2 security checklist loopt het geheel langs. Meer over onze aanpak vind je op de securitypagina. Een overzicht van wat we rond extensies doen staat op Magento extensies.

Veelgestelde vragen

Zijn betaalde Magento extensies veiliger dan gratis?

Nee. Betaald zegt niets over veiligheid. De backdoors uit 2025 zaten in betaalde extensies van commerciële vendors. Beoordeel op patchhistorie, codekwaliteit en update cadence, niet op prijs.

Vindt composer audit onveilige extensies?

Alleen als er een advisory voor bestaat in de database waar Composer tegen controleert. Veel commerciële extensies zijn daar niet in opgenomen. Gebruik composer audit als ondergrens en vul aan met code review, Sansec-meldingen en monitoring.

Hoe merk ik dat een extensie besmet is?

Vaak niet aan het gedrag van de shop. Let op onverwachte wijzigingen in vendor/ of app/code, nieuwe admin-accounts, onbekende uitgaande verbindingen en vreemde scripts in de checkout. Bij verdenking: isoleer de omgeving, scan en herstel vanuit een schone back-up.

Moet ik elke extensie zelf laten reviewen?

Niet alles, wel alles wat risico draagt. Focus op extensies met admin-toegang, betaal- of klantdata, licentiechecks en externe verbindingen. Een review van die onderdelen kost een fractie van een incident.

Hoe vaak moet ik extensies updaten?

Bij security-releases direct, de rest in een vast ritme, bijvoorbeeld maandelijks. Update altijd via een branch met een diff van composer.lock en test op staging. Nooit blind op productie.

Wil je dat iemand je extensies doorlicht?

We bekijken je composer.lock, je actieve modules en de risicoplekken in de code, en geven een concrete lijst: wat blijft, wat gaat eruit, wat moet gepatcht. Neem contact op en we plannen een korte intake.