E-commerce, Magento

19 okt 2026

Bang dat een update je Magento shop kapot maakt? Zo update je Magento-extensies veilig

Door

Jesper van den Bogaard

Er ligt weer een bericht van je bureau dat er beveiligingsupdates klaarstaan voor je Magento-webshop. Het vorige bericht van die strekking ligt er ook nog, van zes weken geleden. Niemand plant ze in want de vorige keer was de checkout een halve dag uit de lucht en kon achteraf niemand precies aanwijzen waardoor.

Dat gevoel is terecht, en het heeft zelden met de update zelf te maken. Een Magento-update werkt als een rekening. Je betaalt hem voor alle keuzes die in de jaren daarvoor in je webshop zijn gemaakt: waar het maatwerk is neergezet, hoe de extensies binnenkwamen, of er een plek is om iets te proberen voordat het live gaat. Wie die keuzes goed heeft gemaakt, draait een patch door in een ochtend. Wie ze heeft laten lopen, staat voor een project.

Hieronder staat wat die rekening bepaalt, en wat je eraan kunt doen voordat de volgende update klaarstaat.

Waarom gaat een Magento-update eigenlijk stuk?

Een Magento-update gaat zelden stuk op Magento. Hij gaat stuk op wat er omheen is gebouwd. In de praktijk komen drie oorzaken steeds terug.

De eerste is een extensie die de nieuwe Magento versie nog niet ondersteunt. De leverancier van de extensie loopt achter of de extensie wordt helemaal niet meer onderhouden. Die ene module houdt dan je hele installatie tegen.

De tweede is maatwerk dat in de core is geschreven in plaats van in een eigen module. Bij een update wordt de core vervangen en verdwijnt die aanpassing. Soms met een foutmelding, wat vervelend is. Soms stilletjes wat nog veel vervelender is, omdat je het pas merkt als een klant belt.

De derde is dat twee modules hetzelfde stukje gedrag overschrijven. Zolang er niets verandert, werkt dat prima. Na een update verandert de volgorde waarin ze geladen worden.

Een voorbeeld uit een B2B-project: de webshop had eigen voorraadlogica die rechtstreeks in de orderafhandeling was ingebouwd. Bij elke upgrade moest die logica opnieuw worden nagelopen en bijgewerkt. De oplossing lag in terugbrengen naar standaard. De eigen logica is vervangen door multi-source inventory, de voorraadfunctionaliteit die Magento zelf meelevert, zodat dat deel voortaan vanzelf meekomt met elke update.

Hoe vaak komen er beveiligingsupdates voor Magento?

Vaker dan een paar jaar geleden, en in 2026 is het tempo omhoog gegaan. Adobe publiceerde in 2025 zes beveiligingsbulletins voor Magento, met gemiddeld zo’n zeven weken ertussen. In 2026 verschenen ze op 10 maart, 12 mei, 14 juli, 11 augustus, 7 september en 8 september. De tweede helft van dat jaar zit dus op een ritme van ongeveer vier weken, en in september stonden er twee in dezelfde week.

Die bulletins leveren twee soorten updates, en dat verschil bepaalt hoe makkelijk je ze kunt toepassen. De grote patchreleases zijn cumulatief: daarin zit alles wat eerder is gerepareerd. Daarnaast verschijnen er losse fixes voor een of enkele kwetsbaarheden, en die zijn juist niet cumulatief. Zo’n losse fix gaat ervan uit dat je al op de laatste patchversie van je releaselijn zit. Wie een paar rondes heeft overgeslagen, kan hem dus niet zomaar installeren en moet eerst bijwerken.

Daarbovenop heeft je eigen webshop een tweede stroom updates. Elke extensie volgt zijn eigen releaseritme, en bij een actief onderhouden Magento-shop zijn er vrijwel wekelijks kleine updates en maandelijks grotere onderhoudswerkzaamheden. Opgeteld hoort updaten thuis in je maandplanning. Hoe hoger de stapel openstaande updates wordt, hoe lastiger het bovendien is om bij een storing te achterhalen welke update hem veroorzaakte.

Welke Magento Open Source-versie krijgt nog beveiligingsupdates?

Momenteel krijgen alleen 2.4.7, 2.4.8 en 2.4.9 nog beveiligingsupdates voor Magento Open Source. De ondersteuningsdata van Adobe:

2.4.9, uitgebracht op 12 mei 2026, wordt ondersteund tot 31 mei 2029
2.4.8 wordt ondersteund tot 31 mei 2028
2.4.7 wordt ondersteund tot 31 mei 2027
2.4.6 viel op 11 augustus 2026 uit de ondersteuning
2.4.5 en ouder krijgen al langer niets meer

Op Open Source is zo’n einddatum harder dan hij op het eerste gezicht lijkt. De verlengde ondersteuning waar je in de documentatie over leest, die na de reguliere einddatum nog patches levert, geldt voor de betaalde variant. Voor de Open Source-codebase worden die verlengde patches niet uitgebracht. Er is dus geen overgangsperiode waarin je nog een jaar rustig doordraait.

Hoe dat in de praktijk uitpakt, stond in het beveiligingsbulletin van september 2026. Daarin staan de Magento Open Source-versies 2.4.6 tot en met 2.4.9 in de lijst met getroffen versies, terwijl er alleen voor 2.4.7, 2.4.8 en 2.4.9 een gerepareerde Open Source-versie is uitgebracht. Wie op dat moment op 2.4.6 draaide, stond dus in de lijst met kwetsbare versies zonder dat er een patch tegenover stond. Daarmee is de vraag op welke versie je draait de eerste van dit hele verhaal, nog voor de vraag welke extensies je hebt.

Waarom duurt een update bij de ene webshop drie uur en bij de andere drie weken?

Het verschil zit bijna nooit in de omvang van de webshop. Het zit in de manier waarop het maatwerk erin is gezet. Vier vragen voorspellen het grootste deel van die doorlooptijd.

Staat het maatwerk in een eigen module of in de core? Code in een eigen module overleeft een update. Code in de core moet elke keer opnieuw worden aangebracht en opnieuw worden getest.

Komen extensies binnen via Composer of zijn ze als map gekopieerd? Via Composer weet je precies welke versie waar draait en kun je gericht bijwerken. Gekopieerde extensies moet iemand handmatig vergelijken met de nieuwe versie.

Hoeveel extensies staan er aan, en worden ze allemaal gebruikt? Elke extensie is een afhankelijkheid die bij elke update meegetest wordt. Een module die niemand meer gebruikt maar die nog wel geïnstalleerd staat, kost je bij elke upgrade opnieuw tijd.

Is er een acceptatieomgeving die lijkt op de productieomgeving? Zonder zo’n omgeving gaan wijzigingen in de praktijk ongetest live, hoe zorgvuldig je verder ook werkt.

Je hoeft geen developer te zijn om hier zicht op te krijgen. Vraag om een lijst van alle actieve extensies met versienummer en leverancier, om de datum van de laatste core-upgrade, en om een overzicht van wat er rechtstreeks in de core is aangepast. Komt die lijst er niet binnen een dag, dan heb je daarmee ook een antwoord.

Hoe test je een Magento-update voordat hij live gaat?

Met een acceptatieomgeving die lijkt op de productieomgeving, en met een test die de kritieke flows doorloopt voordat de update naar productie gaat. Kritiek betekent hier: van productpagina tot afrekenproces, inclusief betaling, inloggen en zoeken. Dat is precies het deel dat bij een handmatige controle als eerste wordt overgeslagen, omdat het saai is en veel klikken kost.

Het inrichten van een geautomatiseerde testsuite duurt in onze praktijk één tot twee weken. Daarna loopt die suite meerdere keren per dag door de volledige kritieke flows en komt er dagelijks een rapport uit van wat er getest is en hoe het ging.

Voor een kleine webshop met weinig maatwerk en twee betaalmethodes is zo’n suite overdreven. Een vaste checklist van tien handmatige stappen plus een acceptatieomgeving vangt daar het meeste af, en die kost niets aan inrichting. De suite begint zichzelf terug te verdienen zodra het aantal flows, klantgroepen en koppelingen groeit, want dan wordt handmatig testen juist de zwakste schakel.

Wat doe je als er na een update toch iets stukgaat?

Terugdraaien hoort een handeling van minuten te zijn. Drie dingen maken dat mogelijk: één wijziging per uitrol zodat je weet wat het was, een deployment die zonder downtime teruggezet kan worden, en een databaseback-up van vlak voor de update.

Die eerste is de goedkoopste en wordt het vaakst overgeslagen. Wie vier extensie-updates, een beveiligingspatch en een stuk maatwerk in één keer live zet, weet bij een storing niet waar hij moet kijken en draait alles terug inclusief de dingen die wel werkten.

Het moment van uitrollen telt ook mee. Een patch die op dinsdagochtend live gaat heeft een hele werkdag aan mensen die hem kunnen opvangen. Vrijdagmiddag en de week voor je drukste periode zijn de twee momenten waarop een kleine storing een dure storing wordt.

Wanneer kun je een Magento-update beter uitstellen?

Soms is uitstellen het verstandigste wat je kunt doen.

Wordt je webshop binnen een jaar vervangen, dan is een volledige versie-upgrade weggegooid geld. Een gerichte beveiligingspatch volstaat mits je huidige Magento versie die nog krijgt.

Is de installatie zo vervuild dat de upgrade meer kost dan opnieuw shop bouwen dan ligt er een andere beslissing voor. Een technische beoordeling van de code geeft daar antwoord op voordat je aan een traject begint, inclusief een inschatting van welk maatwerk en welke extensies in de weg zitten.

Uitstel houdt op een optie te zijn zodra je op een versie zit die geen beveiligingspatches meer krijgt. Op 19 oktober 2026 geldt dat voor iedere Magento Open Source-webshop op 2.4.6 of ouder, want voor de Open Source-codebase bestaat er geen verlengde ondersteuning die je nog een jaar lucht geeft.

Begin bij weten wat erin zit

Updaten wordt makkelijker naarmate er minder in de weg staat. De eerste stap is weten wat er in je installatie zit: welke extensies, hoeveel maatwerk, waar dat maatwerk staat en op welke Magento-versie je draait. Met dat overzicht wordt een update een geplande handeling waarvan je de doorlooptijd vooraf kunt inschatten.

Wil je dat in kaart hebben voordat je de volgende patch doorvoert, dan is een code review de kortste route naar een eerlijk antwoord.

Hoe vaak moet je Magento updaten?

Beveiligingspatches installeer je zodra ze beschikbaar zijn, en dat is vaker dan veel webshopeigenaren denken. Adobe bracht in 2025 zes beveiligingsbulletins voor Magento uit en in 2026 tot en met september opnieuw zes, waarbij het tempo in de tweede helft van 2026 naar ongeveer vier weken ging. Daarnaast zijn er bij een actief onderhouden Magento-shop vrijwel wekelijks kleine extensie-updates en maandelijks grotere onderhoudswerkzaamheden.

Welke Magento Open Source-versies krijgen in oktober 2026 nog beveiligingsupdates?

Alleen 2.4.7, 2.4.8 en 2.4.9. Versie 2.4.9 verscheen op 12 mei 2026 en wordt ondersteund tot 31 mei 2029, 2.4.8 tot 31 mei 2028 en 2.4.7 tot 31 mei 2027. Voor 2.4.6 eindigde de ondersteuning op 11 augustus 2026, en 2.4.5 en ouder krijgen al langer niets meer.

Wat gebeurt er als je Magento-versie geen beveiligingsupdates meer krijgt?

Dan blijven bekende kwetsbaarheden in je installatie open staan, omdat er voor die releaselijn geen gerepareerde versie meer verschijnt. In het beveiligingsbulletin van september 2026 stond Magento Open Source 2.4.6 wel in de lijst met getroffen versies, terwijl er alleen voor 2.4.7 tot en met 2.4.9 een fix werd uitgebracht. Upgraden naar een ondersteunde versie is dan de enige echte oplossing; een firewall of virtuele patching bij je hoster koopt je hooguit tijd.

Kun je Magento updaten zonder downtime?

Vaak wel, met zero-downtime deployments, al geldt dat niet voor elke update. Updates die een databasemigratie uitvoeren of een volledige herindexering vragen, hebben een kort onderhoudsmoment nodig. Plan dat buiten je piekuren en laat je klantenservice weten wanneer het gebeurt.

Waarom breken extensies bij een Magento-update?

Omdat een extensie gebouwd is tegen een specifieke Magento-versie. Verandert de core, dan kan het aanknopingspunt dat de extensie gebruikt verdwenen of veranderd zijn. Twee extensies die hetzelfde gedrag overschrijven geven daarnaast problemen zodra de laadvolgorde verandert.

Hoe lang duurt een Magento-upgrade?

Dat hangt af van je installatie en niet van de omvang van je webshop. Bepalend zijn het aantal actieve extensies, de hoeveelheid maatwerk en de vraag of dat maatwerk in eigen modules staat of in de core. Een eerlijke inschatting kan pas na een inventarisatie van extensies en maatwerk; wie vooraf zonder die inventarisatie een doorlooptijd noemt, gokt.

Moet je elke Magento-extensie updaten?

Nee. Een extensie-update die alleen functies toevoegt die je niet gebruikt, kan wachten. Beveiligingsupdates en updates die nodig zijn voor compatibiliteit met je Magento-versie kunnen dat niet. Ongebruikte extensies kun je beter verwijderen dan bijwerken, want elke geïnstalleerde module blijft meetellen bij volgende updates.

Wat is een acceptatieomgeving en heb ik er een nodig?

Een acceptatieomgeving is een kopie van je webshop waarin je wijzigingen test voordat ze naar de live omgeving gaan. Je hebt er een nodig zodra meer dan één persoon aan de shop werkt of zodra er koppelingen met andere systemen lopen. Zonder acceptatieomgeving gaan wijzigingen in de praktijk ongetest live.

Wat kost een code review van een Magento-webshop?

Een code review kost bij ons 2.500 euro, afhankelijk van de omvang van de installatie, het aantal extensies en de hoeveelheid maatwerk. Het resultaat is een gedocumenteerd rapport met de staat van de code, de beveiligingsstatus en de compatibiliteit met de Magento-standaarden.

Hoe weet je of je maatwerk een update in de weg zit?

Vraag om twee overzichten. Het eerste is een lijst van alle aanpassingen die buiten eigen modules zijn gedaan, dus rechtstreeks in de core of in een gekopieerd thema. Het tweede is een lijst van extensies die niet via Composer zijn geïnstalleerd. Die twee lijsten samen voorspellen het grootste deel van de doorlooptijd van je volgende upgrade.