← Alle artikelen

Drupal Commerce-lek misbruikt: prijzen aanpasbaar (28-10-2026)

Gepubliceerd op 2 november 2026 · 7 min lezen · CyberNovaLabs.io

Door een access bypass in Commerce Core kon een klant zelf de prijs en de status van zijn order wegschrijven. Drupal geeft het 21 op 25, meldt actief misbruik en vraagt om orders na te lopen. Wat een mkb-bedrijf moet nakijken, en welke meldtermijnen kunnen gaan lopen.

Kort

Op 28 oktober 2026 publiceerde het securityteam van Drupal advies SA-CONTRIB-2026-254 en gaf het Drupal Commerce-lek de hoogste risicoklasse, 21 op 25: een access bypass in Commerce Core, de module achter Drupal-webshops^[1]. Het lek heet CVE-2026-118539 en raakt alle versies onder 2.41 plus de versies 3.0.0 tot en met 3.3.12; volgens het advies wordt het al misbruikt^[1]. In de week van 18 oktober 2026 meldden 42.002 sites dat ze Commerce gebruiken^[3]. Drupal vraagt webshops uitdrukkelijk hun orders op onregelmatigheden na te lopen^[1].

Wat het Drupal Commerce-lek precies mogelijk maakt

Commerce Core controleerde rechten op entiteitsniveau, niet op veldniveau. De module zorgde er dus wel voor dat u alleen uw eigen mandje aanraakte, maar niet welke velden van dat mandje u mocht wegschrijven. Een ingelogde klant kon daardoor via JSON:API en REST velden wijzigen die niet van hem zijn: total_price, unit_price, adjustments, state, uid en store_id op de order en de orderregels^[5].

Er stonden nog twee deuren open: het veld product_id van een variant, waarmee een variant naar het product van een andere verkoper kan wijzen, en het veld promotion_id van een kortingsbon, samen met het beheerformulier voor bonnen bij een order^[5]. Drupal vat het effect in één regel samen: een access bypass die de verkoper financieel kan raken^[1].

Commercieel gezien is het simpel. Een order kan op de status betaald komen zonder betaling, of betaald worden tegen de prijs die de koper zelf heeft ingevuld. Dit is geen datadiefstal: dit is omzet die regel voor regel wegloopt, zonder securitymelding en zonder iets wat een virusscanner ziet.

Waarom "onze Drupal is bijgewerkt" geen antwoord is

Commerce Core is geen Drupal-core, maar een contributed module. Securityreleases van de core en adviezen over contributed modules volgen twee verschillende agenda's. Een site met een volledig bijgewerkte core kan dus weken kwetsbaar blijven zonder dat iemand het merkt.

Op diezelfde 28 oktober kwam er een tweede advies over dezelfde stack: Commerce License, matig kritiek met 12 op 25, CVE-2026-118555, opgelost in 3.1.1^[2]. Dat raakt alleen sites die de rechten voor het bijwerken van je eigen licentie hebben uitgedeeld, maar het kan uitlopen op een beheerdersrol^[2]. Verkoopt u abonnementen of licenties, dan gelden beide adviezen.

Hier weegt de tijd zwaarder dan de score. Het lek wordt misbruikt, dus elke dag tussen 28 oktober en uw update is een venster waarin orders met de hand hersteld kunnen zijn. Hetzelfde patroon zagen we bij de kritieke PHP-lekken van oktober 2026: de nuttige vraag is niet "ben ik kwetsbaar", maar "wat is er gebeurd voordat ik patchte".

Twee meldklokken, per land

Orderfraude leidt niet automatisch tot een meldplicht. Twee regelingen, twee voorwaarden, twee ontvangers.

NIS2. Voor essentiële en belangrijke entiteiten in de zin van de richtlijn schrijft artikel 23 een vroegtijdige waarschuwing binnen 24 uur voor, een melding binnen 72 uur en een eindrapport binnen een maand na die melding^[6]. De ontvanger is de nationale autoriteit of het CSIRT: het CCB in België, NCSC-NL in Nederland, ANSSI in Frankrijk, ILR in Luxemburg. Of u onder de wet valt, hangt af van sector en omvang: onze analyses lopen de toets door voor Belgische webshops en voor Nederlandse webshops en marktplaatsen.

AVG. Artikel 33 vraagt een melding bij de toezichthouder binnen 72 uur nadat u op de hoogte bent van een inbreuk op persoonsgegevens^[7]: APD/GBA in België, de Autoriteit Persoonsgegevens in Nederland, de CNIL in Frankrijk, de CNPD in Luxemburg. Een nuttig onderscheid: een order die tegen de verkeerde prijs is betaald, is op zichzelf geen inbreuk op persoonsgegevens. De klok van 72 uur gaat pas lopen als klantgegevens zijn ingezien, gewijzigd of weggehaald — en dat blijkt alleen uit de logs.

In beide gevallen begint de termijn bij het op de hoogte zijn. Daarom schrijft u de tijdlijn — datum van ontdekking, geraakte orders, bedrag, genomen maatregelen — op voordat u iemand belt.

Uw blootstelling in tien minuten becijferen

De cijfers hieronder zijn werkaannames; vervang ze door uw eigen getallen.

Stel: 40 orders per dag, een gemiddelde orderwaarde van 120 euro, een venster van zes dagen tussen het advies van 28 oktober en uw fix, en 1% aangepaste orders. Dat geeft 240 blootgestelde orders en een orde van grootte van 288 euro. Bij 10% aangepaste orders wordt het 2.880 euro. Het gaat niet om de uitkomst: de rekensom zegt hoeveel orders u met de hand moet nalopen, en dus hoeveel tijd u deze week vrijhoudt.

Bij CyberNovaLabs.io

Wij bouwen en onderhouden webshops en interne tools, en wij houden bij uit welke onderdelen ze bestaan. Met dat overzicht antwoordt u binnen een uur op de vraag "raakt dit ons", niet binnen een week. Kan vandaag niemand u vertellen welke versie van Commerce Core in productie draait, dan is dat de eerste klus. Bekijk ons aanbod software op maat en applicatiebeheer, of vertel ons in dertig minuten over uw webshop.

Bronnen

1. Drupal Security Team — Commerce Core - Highly critical - Access bypass - SA-CONTRIB-2026-254 (28/10/2026)
2. Drupal Security Team — Commerce License - Moderately critical - Access bypass - SA-CONTRIB-2026-260 (28/10/2026)
3. Drupal.org — Statistiques d'usage du module Commerce (semaine du 18/10/2026)
4. BleepingComputer — Drupal warns of critical Commerce Core flaw exploited in attacks (30/10/2026)
5. Ostorlab — Drupal Commerce Access Bypass, Exploited in the Wild (CVE-2026-118539) (30/10/2026)
6. Directive (UE) 2022/2555 (NIS2), article 23 — obligations de signalement
7. Règlement (UE) 2016/679 (RGPD), article 33 — notification d'une violation de données

Lees ook