Magento 2 security patches installeren zonder downtime

Magento 2 security patches installeren zonder downtime

In april 2022 maakten aanvallers actief misbruik van CVE-2022-24086. Een kritieke kwetsbaarheid in Magento die remote code execution mogelijk maakte — zonder authenticatie. De patch was al twee weken beschikbaar. Webshops die de patch niet hadden geïnstalleerd, werden gecompromitteerd terwijl de oplossing klaar lag.

Dat is geen hypothetisch scenario. Dat is wat er werkelijk is gebeurd.

Uitstellen heeft een prijs. Dit artikel legt je uit hoe je patches installeert zonder downtime — en waarom het proces geen optie is, maar een operationele standaard.

Waarom patches uitstellen gevaarlijk is: concrete CVEs

CVE-2022-24086 — CVSS 9.8 (Kritiek)

Remote code execution zonder authenticatie. Een aanvaller kon via het checkout-formulier willekeurige code uitvoeren op de server. Geen admin-account nodig, geen credentials. Puur een HTTP-request.

Adobe publiceerde de patch op 13 februari 2022. Op 15 februari werden al actieve exploits waargenomen in het wild. Webshops die twee weken later nog ongepatcht draaiden, hadden twee weken een open deur gehad.

CVE-2024-34102 — CVSS 9.8 (Kritiek)

Dubbed "CosmicSting" door beveiligingsonderzoekers. Een XXE-kwetsbaarheid die aanvallers toegang gaf tot gevoelige bestanden op de server — inclusief env.php met de databasecredentials. In combinatie met een andere kwetsbaarheid leidde dit tot volledige serveroname.

Sansec rapporteerde dat binnen 24 uur na publicatie meer dan 4.000 Magento-shops gecompromitteerd waren. De patch was beschikbaar. De webshops die getroffen werden, hadden die niet geïnstalleerd.

CVE-2023-38208 — CVSS 7.8 (Hoog)

Een path traversal-kwetsbaarheid die lokale bestanden leesbaar maakte voor ingelogde admingebruikers. Minder kritiek dan de vorige twee, maar gevaarlijk in combinatie met een gecompromitteerd adminaccount.

Het patchproces: stap voor stap

Een Magento security patch installeer je nooit direct op productie. Dat is het kortste pad naar downtime of een gebroken webshop.

Het juiste proces is lineair: staging eerst, dan testen, dan deployen op productie.

Stap 1: Patch identificeren en beoordelen

Adobe publiceert security patches via magento.com/security/patches en via Composer als package-update.

Controleer de CVSS-score:

• CVSS 9.0 - 10.0 — Kritiek. Target: gepatcht binnen 24-48 uur
• CVSS 7.0 - 8.9 — Hoog. Target: gepatcht binnen 7 dagen
• CVSS 4.0 - 6.9 — Medium. Target: gepatcht bij de eerstvolgende patchcyclus
• CVSS < 4.0 — Laag. Mee te nemen in de eerstvolgende reguliere update

Stap 2: Patch uitvoeren op staging

# Controleer huidige versie
php bin/magento --version

# Update via Composer
composer update magento/product-community-edition --with-dependencies

# Database-migraties uitvoeren
php bin/magento setup:upgrade

# Static content opnieuw genereren
php bin/magento setup:static-content:deploy -f

# Cache leegmaken
php bin/magento cache:flush

Voer dit uit op een staging-omgeving die identiek is aan productie — zelfde PHP-versie, zelfde extensies, zelfde database-dump van maximaal 24 uur oud.

Stap 3: Testen op staging

Handmatig testen kost tijd. Automatiseer zoveel mogelijk.

• Homepage laadt correct
• Categorieoverzicht met filters
• Productpagina (eenvoudig + configureerbaar product)
• Toevoegen aan winkelwagen
• Volledige checkout (inclusief betaling in sandbox)
• Admin panel inloggen en navigeren
• Extensies die frontend-functionaliteit toevoegen

# Magento's eigen integratietests
php vendor/bin/phpunit -c dev/tests/integration/phpunit.xml

# End-to-end testen met Cypress
npx cypress run --spec "cypress/e2e/checkout.cy.js"

Als je geen geautomatiseerde testset hebt, is dit het moment om die te bouwen. Elke patchcyclus betaalt de investering terug.

Stap 4: Deployment op productie

Dit is waar zero-downtime deployment in beeld komt.

Zero-downtime deployment strategieën

Downtime bij een productie-deployment kost je omzet. Bij een webshop van €3 miljoen per jaar is elk uur downtime gemiddeld €340 waard. Dat zijn kosten die te voorkomen zijn.

Strategie 1: Maintenance mode minimaliseren

De eenvoudigste aanpak voor kleinere webshops. De deployment zelf hoeft niet lang te duren.

# Maintenance mode aan (zo kort mogelijk)
php bin/magento maintenance:enable

# Deployment uitvoeren
composer update magento/product-community-edition --with-dependencies
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f

# Cache leegmaken
php bin/magento cache:flush

# Maintenance mode uit
php bin/magento maintenance:disable

Met een geoptimaliseerde deployment duurt dit 3-8 minuten. Plan het buiten piekuren.

Strategie 2: Blue-Green Deployment

Bij blue-green deployment draai je twee identieke omgevingen: blue (de huidige live-omgeving) en green (de nieuwe versie). Het verkeer wordt pas omgeschakeld nadat green volledig getest is.

Stap 1: Blue draait live. Green is identiek aan Blue.
Stap 2: Patch + deployment worden uitgevoerd op Green.
Stap 3: Green wordt volledig getest.
Stap 4: Load balancer schakelt verkeer om: Green wordt Live.
Stap 5: Blue blijft draaien als direct beschikbare rollback.

De load balancer-omschakeling duurt seconden. Er is vrijwel geen downtime.

• Load balancer (Nginx, HAProxy, of cloudprovider zoals AWS ALB)
• Twee identieke serveromgevingen
• Gedeelde database of database-replicatie
• Gecentraliseerde sessie-opslag (Redis)

# Nginx upstream configuratie — schakel naar blue_server voor rollback
upstream magento_backend {
    server green_server:80;
}

Blue-green deployment is standaard bij webshops met hoge beschikbaarheidseisen. De infrastructuurkosten zijn hoger — je betaalt voor twee omgevingen — maar de operational risk is lager.

Strategie 3: Rolling deployment met Kubernetes

Voor webshops die op Kubernetes draaien, is een rolling deployment mogelijk waarbij containers één voor één worden vervangen.

# Kubernetes deployment strategy
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0      # Geen pods offline tijdens update
      maxSurge: 1            # Maximaal één extra pod tegelijk

Kubernetes vervangt containers geleidelijk. Als de nieuwe versie faalt, rolt Kubernetes automatisch terug. Dit is de meest geavanceerde strategie en vereist een Kubernetes-omgeving met correct geconfigureerde health checks.

Het rollback plan

Elke deployment zonder rollback-plan is een risicovolle deployment. Definieer van tevoren:

• Checkout-fouten direct na deployment
• Error rate boven een bepaald drempelwaarde (bijv. meer dan 5% 500-errors)
• Kritieke betaalfunctionaliteit niet beschikbaar

• Target: minder dan 10 minuten

Bij een blue-green deployment:

# Nginx omschakelen terug naar blue in de load balancer-configuratie
nginx -s reload

Bij een standaard deployment:

# Via Git: terug naar de vorige versie
git checkout {vorige-commit-hash}
composer install
php bin/magento setup:upgrade
php bin/magento cache:flush

Definieer dit van tevoren. Niet iedereen met servertoegang mag dit besluit nemen.

Hoeveel tijd en geld kost een patchcyclus?

Eerlijkheid over kosten is belangrijk. Security patches kosten geld — maar minder dan een hack.

Bij geautomatiseerd testen en een geoptimaliseerd deployment-proces zakt dit naar 2-3 uur.

Per jaar publiceert Adobe gemiddeld zes tot acht security patches. Dat betekent een jaarlijkse investering van €3.000 tot €5.000 voor een volwassen patchproces.

• Geautomatiseerde testpipeline: -50% testtijd
• Geautomatiseerde deployment scripts: -50% deploymenttijd
• Monitoring + alerting: detecteer problemen binnen minuten

De investering in testautomatisering betaalt zichzelf terug na drie à vier patchcycli.

Welke extensies breken na een patch?

Magento-patches kunnen core-bestanden aanpassen. Extensies die die bestanden overschrijven, kunnen breken.

1. Prefereer extensies die werken via dependency injection en geen core-bestanden overschrijven
2. Controleer de extensie-changelog na elke Magento-update
3. Test alle extensies met frontend-functionaliteit na elke patch
4. Gebruik magerun2 voor een snelle check:

# Overzicht van alle actieve extensies
vendor/bin/magerun2 sys:modules:list --status=active

# Controleer conflicten na de patch
php bin/magento setup:di:compile 2>&1 | grep -i error

Structurele aanpak: de patchcyclus professionaliseren

Een eenmalige patch is geen strategie. Een patchcyclus is dat wel.

• Controleer nieuwe security bulletins
• Voer een scan uit via Sansec eComscan of de Magento Security Scan Tool

• Directe actie binnen 24-48 uur
• Staging → Test → Productie

• Magento minor version update
• Extensie-updates
• PHP-versie-check

• Volledige security checklist
• Penetratietest door externe partij

Conclusie

CVE-2022-24086 en CVE-2024-34102 werden beiden actief misbruikt binnen 24 uur na publicatie. De shops die getroffen werden, hadden de patches niet geïnstalleerd. Niet omdat die patches er niet waren — maar omdat er geen patchproces was.

Een zero-downtime deployment is technisch goed te realiseren. Blue-green deployment is de goudstandaard. Voor kleinere installaties is een geoptimaliseerde maintenance-window van vijf minuten buiten piekuren al een grote verbetering.

De investering per patchcyclus — €500 tot €625 — is een fractie van de kosten van een incident.

Wil je een professioneel patchproces opzetten voor jouw Magento webshop? Neem contact op voor een gesprek over hoe we dat voor jou kunnen inrichten.

Veelgestelde vragen

Moet ik elke security patch direct installeren?

Dat hangt af van de CVSS-score. Patches met score 9.0 of hoger vereisen actie binnen 24-48 uur — die worden actief misbruikt. Lagere scores kun je meenemen in de eerstvolgende reguliere patchcyclus.

Kan ik een Magento patch uitstellen tot het rustig is?

Voor kritieke patches: nee. Aanvallers wachten niet tot het rustig is. Zodra een kwetsbaarheid publiek is, begint de race. Gebruik een goede testprocedure om snel en veilig te deployen.

Hoe weet ik of een extensie compatibel is na een patch?

Controleer de release notes van de extensiebouwer, test op staging, en voer php bin/magento setup:di:compile uit — compilerfouten wijzen op conflicten. Voor extensies van betrouwbare leveranciers volgen compatibiliteitsupdates snel na een Magento-release.

Wat is het verschil tussen een security patch en een minor version update?

Een security patch is gericht op één of meer kwetsbaarheden en wijzigt zo min mogelijk code. Een minor version update (bijv. 2.4.6 naar 2.4.7) bevat beveiligingspatches én bugfixes én verbeteringen. Minor updates vereisen meer testwerk.

Hoeveel kost een goede patchcyclus per jaar?

Reken op €3.000 tot €5.000 voor handmatig testen bij zes tot acht patches per jaar. Met een geautomatiseerde testpipeline zakt dit naar €1.500 tot €2.500. Een hack of datalek kost een veelvoud daarvan.