Sinds september zijn er twee kritieke Magento-lekken gefixt, beide met de hoogst mogelijke score: CVSS 10.0. Geen van beide fixes kwam met een nieuw versienummer. Wie nu zegt “we draaien 2.4.9, dus we zitten goed”, kijkt naar het verkeerde getal.
Dat komt door hoe Adobe sinds dit jaar patcht. Hieronder wat er veranderde, wat de twee lekken van dit najaar precies waren en hoe je checkt of jouw shop echt gedekt is.
Wat er veranderde: van -p-release naar maandelijkse patches
Magento-versienummers werkten lang simpel. Een -p-release (2.4.8-p1, 2.4.8-p2, enzovoort) bundelde de fixes van de afgelopen maanden. Je versienummer vertelde je ongeveer hoe up-to-date je was.
Sinds dit jaar werkt Adobe daarnaast met een Monthly Isolated Security Patching Policy. Elke Patch Tuesday, de tweede dinsdag van de maand, komt er een losse security patch uit. Die patch staat los van de volgende -pN-release en is niet cumulatief: je past patches op volgorde toe, en elke patch gaat ervan uit dat de vorige al is geïnstalleerd.
Deze isolated patches worden later alsnog opgenomen in de volgende volledige -pN-release. Maar tot die release uitkomt, is het een los bestand dat je zelf van repo.magento.com haalt en toepast. Niet via Composer. Een composer update of een nieuwe composer create-project geeft je de basisversie, zonder die tussentijdse patches. Sansec noemde het expliciet: een gewone Composer-installatie draait nog altijd de kwetsbare basisversie.
Dat maandelijkse tempo is geen overbodige luxe. Een van de twee lekken hieronder werd al misbruikt voordat er een fix bestond.
De twee kritieke lekken van dit najaar
StyleSmuggler werd al aangevallen voordat er een fix was. Sansec zag de eerste aanvallen op 4 september en maakte het lek op 5 september openbaar. Adobe bevestigde het misbruik en bracht op 7 september een hotfix uit. Drie dagen dus waarin shops niets konden installeren. Getroffen volgens Adobe: Adobe Commerce 2.4.4 tot en met 2.4.9 en Magento Open Source 2.4.6 tot en met 2.4.9. Sansec rekent ook Open Source 2.4.4 en 2.4.5 tot de kwetsbare versies. (Voor wie het nazoekt: bulletin APSB26-146, CVE-2026-75650, hotfix VULN-39341.)
BlockStrap (CVE-2026-103849, CVSS 10.0) maakte deel uit van bulletin APSB26-153 van 13 oktober, de reguliere oktoberpatch (“2026-oct”). Zonder in te loggen kon een aanvaller via de e-mailtemplate-engine code uitvoeren. Hetzelfde bulletin bevatte meerdere andere kritieke lekken, waaronder een B2B-specifiek lek (CVE-2026-92909, CVSS 9.8). Sansec zag op 15 oktober nog geen aanvallen op live winkels, maar had binnen 24 uur al vier werkende aanvalsroutes gereproduceerd.
Belangrijk: de oktoberpatch bevat de StyleSmuggler-hotfix niet. Adobe vraagt in het bulletin expliciet om die er los naast te zetten. Je hebt dus beide patches nodig, niet een van de twee.
Wat dit betekent voor jouw versie
Een momentopname per vandaag, 30 oktober 2026.
Draai je Adobe Commerce 2.4.4 tot en met 2.4.9, op de laatste -p-baseline (2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 of 2.4.4-p18)? Dan heb je zowel de september-hotfix als de oktoberpatch nodig, allebei als los patchbestand.
Draai je Magento Open Source? Dan ligt het genuanceerder. De oktoberpatch is volgens Adobe’s eigen documentatie alleen beschikbaar vanaf 2.4.7, de StyleSmuggler-fix vanaf 2.4.6. Open Source 2.4.4 en 2.4.5 zijn buiten support: Adobe’s bulletin noemt die versies niet eens meer. Veilig zijn ze daarmee niet. Sansec rekent ze gewoon tot de kwetsbare versies.
| Magento Open Source | September-hotfix (StyleSmuggler) | Oktoberpatch (BlockStrap) |
|---|---|---|
| 2.4.7 tot en met 2.4.9 (op de laatste -p) | ja | ja |
| 2.4.6 | ja | nee |
| 2.4.4 en 2.4.5 | nee | nee |
Draai je Mage-OS? Dat werkt structureel anders. Mage-OS brengt fixes uit als gewone, via Composer installeerbare release, niet als los patchbestand. Versie 3.5.0 (8 september) bevat de StyleSmuggler-fix, versie 3.6.0 (14 oktober) de fixes uit APSB26-153. Het officiële beleid van Mage-OS is kort en duidelijk: “Mage-OS provides security patches and updates for the latest release branch only. Older releases receive no fixes.”
Elke maand komt er een nieuwe patch bij. Dit is dus geen rijtje om één keer af te vinken.
Hoe check je of de patch erop zit
De Quality Patches Tool (magento/quality-patches, commando vendor/bin/magento-patches status) is voor quality patches: bugfixes, performanceverbeteringen. Niet voor deze security patches. Die twee raken makkelijk door elkaar.
Wat je wel nodig hebt, is Adobe’s Commerce Version Tool. Het commando php vendor/bin/patch-status toont per CVE of je gedekt bent. Let op: deze tool kwam zelf mee met een eerdere isolated patch uit juli. Ontbreekt die tool, dan mis je al minimaal die patch.
En zelfs “we hebben de patch gedownload” is niet hetzelfde als “we zijn gedekt”. Het oktoberpatchbestand voor 2.4.8-p5 miste bij publicatie een deel van een validatorwijziging en is kort na 13 oktober opnieuw uitgebracht, onder dezelfde bestandsnaam. Patchte je 2.4.8-p5 meteen in die eerste dagen? Kijk dan na of je niet de eerste, onvolledige versie hebt toegepast.
Wat je aan je bureau of hoster vraagt
Voor wie zelf niet in de code zit, zijn dit de vragen die ertoe doen.
Staan we op de laatste -p-baseline? Zonder die baseline past de isolated patch niet, en dan blijf je sowieso achter.
Zijn de september-hotfix en de oktoberpatch allebei toegepast? Vraag om de output van patch-status te zien, niet om een mondelinge bevestiging.
Wie zet de patch van november erop, en wanneer? De volgende Patch Tuesday komt eraan, of je er nu klaar voor bent of niet.
Een hoster beschermt de server. De applicatiepatches, in je Magento-code zelf, liggen bij wie die code beheert. Dat is niet automatisch dezelfde partij, dus vraag het na. (Een lek in PHP zelf, de laag eronder, is wel weer een zaak van je hoster: zie onze post over PHP2Shell.) Magento onderhoud is precies dit: iemand die structureel bijhoudt welke patch wanneer moet.
Een patch zet niemand buiten die al binnen is
Een patch voorkomt een nieuwe inbraak. Die zegt niets over een inbraak die al heeft plaatsgevonden via een ouder lek.
Sansec publiceerde op 24 oktober onderzoek naar een campagne die ze deepveindrilling noemen: 953 besmette winkels, actief sinds juli 2025, met een loader verstopt in CMS-blokken. Aanvallers kwamen onder meer binnen via twee oudere lekken: PolyShell (CVE-2026-48356, APSB26-73) en SessionReaper (CVE-2025-54236, APSB25-88). Sansec is er duidelijk over: “Deleting the script does not remove that access.”
Met andere woorden: je kunt vandaag netjes patchen, en toch al maanden een achterdeur open hebben staan via een lek dat destijds niet gepatcht is. Het zichtbare script weghalen lost dat niet op. Laat na het patchen dus ook checken op sporen van eerdere toegang: onbekende admin-accounts, vreemde bestanden, scripts in content die je niet herkent. Dat is een andere check dan patchen, en hoort bij een code review.
Wat wij doen
Voor shops die bij ons in onderhoud zijn, volgen we de maandelijkse bulletins van Adobe en zetten we de patches erop. Dat is saai werk, en precies daarom moet iemand het vast doen.
Veelgestelde vragen
Is composer update genoeg?
Nee. Composer kent alleen de -p-releases. De maandelijkse security patches zijn losse bestanden die iemand bewust moet downloaden en toepassen.
Ik draai Magento Open Source 2.4.6, krijg ik de BlockStrap-fix nog?
Volgens Adobe niet. De oktoberpatch voor Open Source is alleen beschikbaar vanaf versie 2.4.7. Upgraden naar 2.4.7 of hoger is de enige officiële route.
Wat doet Mage-OS anders?
Mage-OS brengt security fixes uit als gewone, via Composer installeerbare release, in plaats van een los patchbestand. Daar staat tegenover dat alleen de laatste releasebranch fixes krijgt: oudere Mage-OS-versies krijgen volgens het eigen beleid geen fixes meer.
Is mijn shop veilig als hij op 2.4.9 draait?
Niet per se. 2.4.9 is een versienummer, geen garantie. De september-hotfix en de oktoberpatch zijn losse bestanden die je apart toepast. Alleen met die patches erop, en bevestigd via patch-status, ben je voor deze twee lekken gedekt.
Weet je niet zeker of jouw shop bij is?
Dan zoeken we het voor je uit: welke patches er zijn toegepast, welke er nog missen en of er sporen zijn van eerder misbruik. Vraag een code review aan of neem contact op.