Witold Kepinski - 22 september 2026

Datalek bij DA laat zien waarom patchen alleen niet genoeg is

Het datalek bij drogisterijketen DA, waarbij gegevens van ongeveer 236.000 webshopklanten betrokken zijn, laat zien hoe snel een kwetsbaarheid in een internet-facing systeem kan uitgroeien tot een serieus beveiligingsincident. Er zijn aanwijzingen dat de aanvallers toegang hebben verkregen via de Magento-omgeving waarop de webshop draait. Welke specifieke kwetsbaarheid daarbij is gebruikt, is vooralsnog niet publiek bevestigd, zo meldt cybersecurity specialist Erik Westhovens (foto) van Ransomwared.

Datalek bij DA laat zien waarom patchen alleen niet genoeg is image

Op 4 september kregen onbevoegden toegang tot een database van de webshop van DA. In die database stonden onder meer namen, e-mailadressen, woonadressen, telefoonnummers, geboortedata en IP-adressen. Ook informatie over bestelde producten en de gebruikte betaalmethode kon worden ingezien.

De webshop van DA maakt gebruik van Magento, een veelgebruikt e-commerceplatform. Rond dezelfde periode werd bovendien een zeer ernstige kwetsbaarheid in Magento Open Source en Adobe Commerce actief misbruikt.

Die kwetsbaarheid, CVE-2026-75650, beter bekend als StyleSmuggler, kreeg een CVSS-score van 10.0. Daarmee valt deze in de zwaarste categorie. De kwetsbaarheid kon zonder geldig gebruikersaccount op afstand worden misbruikt en kon een aanvaller in bepaalde omstandigheden de mogelijkheid geven om code op de webserver uit te voeren.

Of juist deze kwetsbaarheid bij DA is gebruikt, is op dit moment niet vastgesteld. De timing maakt de zaak echter wel relevant voor de bredere discussie over patchmanagement, detectie, monitoring en incident response.

Soms bestaat de patch nog niet

Volgens Erik Westhovens, CEO van cybersecuritybedrijven Ransomwared en Amuneth, is het belangrijk om onderscheid te maken tussen een organisatie die een beschikbare beveiligingsupdate niet installeert en een aanval waarbij op het moment van misbruik nog helemaal geen patch beschikbaar is.

“Bij kritieke kwetsbaarheden wordt al snel gezegd dat een organisatie sneller had moeten patchen. Maar soms kan dat simpelweg nog niet. Bij StyleSmuggler werden op 4 september al actieve aanvallen waargenomen, terwijl Adobe pas op 7 september een officiële fix beschikbaar stelde.”

Dat betekent volgens Westhovens niet dat patchmanagement minder belangrijk is.
“Integendeel. Zodra er een fix beschikbaar is voor een kritieke kwetsbaarheid die vanaf het internet kan worden misbruikt, moet je daar zo snel mogelijk op handelen. Maar die eerste periode laat precies zien waarom je niet uitsluitend op patches kunt vertrouwen.”

Bij een zogenoemde zero-day kunnen aanvallers een kwetsbaarheid misbruiken voordat de leverancier een oplossing heeft uitgebracht. Op dat moment moeten andere beveiligingsmaatregelen het overnemen.

Nieuwe Europese regels leggen ook verantwoordelijkheid bij leveranciers

Sinds 11 september 2026 geldt daarnaast een belangrijk nieuw onderdeel van de Europese Cyber Resilience Act, de CRA.

De wet richt zich niet primair op organisaties die software gebruiken, maar op fabrikanten van digitale producten en software. Voor leveranciers van commerciële software betekent dit dat ook zij nadrukkelijker verantwoordelijk worden voor het omgaan met kwetsbaarheden en beveiligingsincidenten in hun producten.
Fabrikanten moeten sinds 11 september actief misbruikte kwetsbaarheden en ernstige beveiligingsincidenten melden via het Europes Single Reporting Platform. 

Daarbij gelden korte termijnen. Wanneer een fabrikant kennis krijgt van een actief misbruikte kwetsbaarheid moet in beginsel binnen 24 uur een eerste melding worden gedaan. Binnen 72 uur moet uitgebreidere informatie volgen. Nadat een corrigerende maatregel beschikbaar is, kan daarnaast een eindrapportage nodig zijn.

“Dat is een belangrijke ontwikkeling”, zegt Westhovens. “Security stopt niet bij de organisatie die de software installeert. Ook de fabrikant moet kwetsbaarheden actief volgen, snel handelen en zijn klanten zo snel mogelijk in staat stellen om maatregelen te nemen.”

Volgens Westhovens is vooral snelheid daarbij van belang. “Als een softwareleverancier weet dat een kritieke kwetsbaarheid actief wordt misbruikt, wil je dat die informatie zo snel mogelijk bij klanten, beveiligingsteams en andere relevante partijen terechtkomt. Hoe eerder je weet wat er speelt, hoe eerder je kunt mitigeren, detectieregels kunt aanpassen, onderzoek kunt uitvoeren en uiteindelijk kunt patchen.”

Detecteren wat er daadwerkelijk gebeurt

Daar komt detectie om de hoek kijken.
Een organisatie moet niet alleen proberen te voorkomen dat een aanvaller binnenkomt, maar ook kunnen zien wanneer er afwijkend gedrag op een systeem plaatsvindt.

Dat kan bijvoorbeeld gaan om onverwachte processen op een webserver, onbekende bestanden, afwijkende databasebenadering, nieuwe gebruikersaccounts, verdachte authenticatiepogingen of verbindingen met onbekende externe systemen.

“Je kunt niet iedere aanval voorkomen”, zegt Westhovens. “Maar je moet wel proberen zo snel mogelijk te ontdekken dat iemand binnen is.”
Daarvoor zijn goede logging, endpoint- en servermonitoring, netwerkdetectie en voldoende bewaartermijnen van logs noodzakelijk. Zeker bij een webserver die direct vanaf het internet bereikbaar is en toegang heeft tot klantgegevens, is die zichtbaarheid belangrijk.

Binnen het Amuneth SOC ligt daarom niet alleen de nadruk op het genereren van meldingen, maar op het volledige traject van detectie tot containment en remediation.

Signalen vanuit endpoints, servers, identities, cloudomgevingen en netwerkverkeer worden continu beoordeeld en met elkaar in verband gebracht. Een enkele afwijking hoeft op zichzelf niet direct een aanval te betekenen, maar meerdere signalen samen kunnen een duidelijk beeld geven van wat er werkelijk gebeurt.

“Alleen een alert genereren is niet voldoende”, aldus Westhovens. “Het gaat erom dat je zo snel mogelijk van detectie naar containment en herstel gaat. Hoe korter de tijd tussen de eerste aanval en het daadwerkelijke ingrijpen, hoe kleiner de kans dat een aanvaller zich verder door de omgeving kan bewegen of gegevens kan buitmaken.”

Juist bij zero-days kan dat verschil groot zijn.
Wanneer nog geen patch beschikbaar is, kan een organisatie de kwetsbaarheid mogelijk tijdelijk mitigeren, bepaalde functionaliteit uitschakelen of extra filtering toepassen. Maar tegelijkertijd moet actief worden gezocht naar signalen dat iemand de kwetsbaarheid al heeft geprobeerd te misbruiken.
Een patch verwijdert geen aanvaller

Ook wanneer uiteindelijk een beveiligingsupdate beschikbaar komt, is installeren daarvan niet automatisch het einde van het incident.
Wanneer een aanvaller vóór het patchen al toegang heeft verkregen, kan deze bijvoorbeeld een webshell, extra gebruikersaccount of andere vorm van permanente toegang hebben achtergelaten.
Ook kunnen wachtwoorden, sessietokens, API-sleutels of andere credentials zijn buitgemaakt waarmee later opnieuw toegang kan worden verkregen.

“Een patch sluit de kwetsbaarheid waardoor iemand naar binnen kon”, aldus Westhovens. “Maar daarmee weet je nog niet of iemand daarvoor al binnen is geweest.”

Wanneer bekend wordt dat een kwetsbaarheid actief wordt misbruikt, moeten organisaties daarom niet alleen patchen. Ze moeten ook terugkijken.
Zijn er verdachte requests geweest? Zijn processen gestart die daar niet thuishoren? Zijn bestanden aangepast? Zijn nieuwe accounts aangemaakt? Is er onverwacht databaseverkeer geweest? En zijn gegevens naar externe systemen verstuurd?
Die laatste vraag is bij een mogelijk datalek bijzonder belangrijk.

Zonder voldoende logging kan het achteraf lastig of zelfs onmogelijk zijn om vast te stellen wat een aanvaller precies heeft gedaan.

Kritieke CVE’s vragen om andere prioriteiten
Het incident rond DA laat daarnaast zien waarom organisaties actief moeten volgen welke nieuwe kwetsbaarheden worden gepubliceerd.

Niet iedere CVE heeft dezelfde urgentie. Een kwetsbaarheid op een geïsoleerd intern testsysteem vormt een ander risico dan een remote-code-execution-kwetsbaarheid op een webshop die 24 uur per dag vanaf het internet bereikbaar is en rechtstreeks toegang heeft tot persoonsgegevens.
Daarom moet naast de CVSS-score ook worden gekeken naar zaken als internet-exposure, actieve exploitatie, beschikbare aanvalscode, de complexiteit van de aanval en de systemen en gegevens die achter de kwetsbare server bereikbaar zijn.

Bij een kritieke en actief misbruikte kwetsbaarheid kan een normale maandelijkse patchcyclus simpelweg te langzaam zijn.

“Wanneer een CVSS 10.0-kwetsbaarheid actief wordt uitgebuit op een systeem dat rechtstreeks aan het internet hangt, wil je niet wachten op de volgende reguliere patchronde”, zegt Westhovens. “Zodra een oplossing beschikbaar is, moet die met prioriteit worden beoordeeld en uitgerold.”
Daarvoor moet een organisatie wel weten welke software zij gebruikt.

Een goede asset inventory en inzicht in gebruikte softwareversies zijn daarom essentieel. Wanneer een ernstige nieuwe CVE wordt gepubliceerd, moet binnen korte tijd duidelijk kunnen worden of de kwetsbaarheid de eigen organisatie raakt.
Niet alleen voorkomen, maar ook voorbereid zijn op het moment dat het misgaat

De gebeurtenissen rond DA en de gelijktijdige activiteit rond ernstige Magento-kwetsbaarheden laten vooral zien dat cybersecurity uit verschillende verdedigingslagen moet bestaan.
Patchmanagement is daar een essentieel onderdeel van, maar niet het enige.

Organisaties moeten weten welke software ze gebruiken, nieuwe kwetsbaarheden actief volgen en kritieke patches met spoed kunnen installeren.
Tegelijkertijd moeten ze ervan uitgaan dat er momenten kunnen zijn waarop nog geen patch bestaat, een patch niet onmiddellijk kan worden uitgerold of een aanvaller simpelweg sneller is geweest.

Op dat moment worden detectie, logging, monitoring, containment en incident response minstens zo belangrijk.

De CRA voegt daar bovendien een extra verantwoordelijkheid aan toe aan de kant van softwarefabrikanten. Leveranciers moeten kwetsbaarheden structureel opvolgen en krijgen steeds duidelijkere verplichtingen rond het melden van actief misbruikte kwetsbaarheden en ernstige beveiligingsincidenten.

Volgens Westhovens moeten organisaties bij een ernstige nieuwe kwetsbaarheid daarom eigenlijk direct een aantal vragen kunnen beantwoorden:

Zijn wij kwetsbaar?

Is het kwetsbare systeem vanaf het internet bereikbaar?
Wordt de kwetsbaarheid actief misbruikt?

Welke tijdelijke maatregelen kunnen we nemen totdat er een patch beschikbaar is?

En kunnen we vaststellen of iemand al heeft geprobeerd de kwetsbaarheid bij ons te misbruiken?

Dat laatste wordt volgens hem vaak onderschat.
“Patchen blijft een van de belangrijkste maatregelen om aanvallen te voorkomen. Maar wanneer er nog geen patch is, of wanneer een aanvaller je voor is geweest, moet je kunnen zien wat er gebeurt en direct kunnen ingrijpen.”

Het incident bij DA onderstreept daarmee een bredere realiteit van moderne cybersecurity.
Een organisatie kan alle bekende patches hebben geïnstalleerd en toch worden getroffen door een kwetsbaarheid waarvoor op dat moment nog geen oplossing bestaat. De vraag is dan niet alleen hoe goed een organisatie aanvallen kan voorkomen.

Minstens zo belangrijk is hoe snel zij ontdekt dat er iets misgaat – en hoe snel zij daarna in staat is om de aanval te stoppen.

ALSO BW + BN TechEx Europe BW + BN
ALSO BW + BN