DIVD gehackt via twee Zammad-zero-days
DIVD werd via twee Zammad-zero-days gecompromitteerd en wijst op een agentic-AI-werkwijze. Wat besluitvormers nu moeten regelen in kwetsbaarheidsbeheer.
U moet patchen, netwerksegmentatie, beperking van systeemrechten en logging als één verdedigingsketen behandelen, niet als aparte projecten, omdat geautomatiseerde aanvallers kwetsbaarheden sneller combineren dan menselijke responstijden toelaten.
Een analyse van 7 oktober 2026 van agentic-AI-aanvallen op kwetsbaarheidsketens stelt dat autonome agenten het venster tussen ontdekking en volledige compromittering verkleinen. Het Dutch Institute for Vulnerability Disclosure (DIVD) werd op 21 september 2026 zelf slachtoffer van een inbraak via twee zero-days in Zammad, een helpdesksysteem dat het intern gebruikte. In onze beoordeling markeert dit incident een verschuiving in hoe organisaties kwetsbaarheidsbeheer moeten structureren: niet als reactie op individuele lekken, maar als verdediging tegen aanvallers die meerdere zwakke punten in seconden aaneenrijgen.
Hoe combineerde de aanvaller twee afzonderlijke kwetsbaarheden tot volledige toegang?
De aanvaller gebruikte CVE-2026-102489 om een bestaande sessie over te nemen en code uit te voeren onder het Zammad-serviceaccount. Vervolgens exploiteerde hij CVE-2026-102490 om van dat account naar root-rechten op te klimmen. Vanuit die positie konden de aanvallers volgens DIVD gegevens uit het systeem halen. Elk lek afzonderlijk was beheerbaar; de combinatie was dodelijk. Wat een menselijke aanvaller in minuten zou doen — wachten op feedback, volgende stappen plannen, commando's typen — voerde een autonome agent in seconden uit.
Welke risico's ontstaan wanneer aanvallers stappen automatiseren?
De aanval toont vier kritieke faalwijzen:
- Ketenrisico in plaats van patchrisico — twee opeenvolgende kwetsbaarheden vormen samen een aanvalspad dat geen van beide afzonderlijk biedt.
- Verkorte responstijd — het venster tussen ontdekking en volledige compromittering krimpt van uren naar minuten.
- Laterale beweging zonder menselijke tussenkomst — een agent voert vervolgstappen uit zonder op instructies te wachten.
- Privilege-escalatie als standaardstap — van beperkt account naar root-rechten gebeurt automatisch, niet als aparte aanvalsfase.
- Gegevensexfiltratie als eindpunt — eenmaal in het systeem, kunnen aanvallers ongehinderd data verzamelen.
Wat moet u nu concreet doen om deze keten te doorbreken?
DIVD meldt dat netwerksegmentatie verdere laterale beweging beperkte. Dit was niet theoretische best practice, maar het verschil tussen één gecompromitteerd systeem en volledige inbraak. U moet de volgende controles per internetgerichte applicatie kunnen aantonen:
- Definieer minimale rechten per serviceaccount — documenteer welke rechten elk account echt nodig heeft en verwijder de rest nu.
- Implementeer netwerksegmentatie voor kritieke systemen — zorg dat een gecompromitteerd account niet automatisch toegang tot andere systemen krijgt.
- Stel een versnelde patch- of isolatieroute in — maak offline halen een ingeoefende optie, niet een paniekbesluit; voor publiek bereikbare software is een patchvenster van weken niet langer verdedigbaar.
- Voer onafhankelijke audittrails in — leg vast wie wat deed en welke gegevens werden benaderd, zodat u na een incident kunt reconstrueren wat is gebeurd.
- Betrek juridische en incidentteams vroeg — bepaal welke gegevens mogelijk zijn benaderd en welke meld- en documentatieverplichtingen daaruit volgen.
Hoe past dit in uw huidige kwetsbaarheidsbeheer?
Kwetsbaarheidsbeheer dat alleen vaststelt of software een lek heeft, dekt dit scenario niet. U moet patchen, segmentatie, beperking van rechten en logging als één keten behandelen. Dat betekent: als u een kritieke kwetsbaarheid in een internetgerichte applicatie ontdekt, moet u niet alleen een patch plannen, maar ook controleren of het serviceaccount dat systeem gebruikt minimale rechten heeft, of het systeem van andere kritieke systemen gescheiden is, en of u audittrails hebt om later te reconstrueren wat is gebeurd.
Tooling kan u helpen deze controles uit te voeren en vast te leggen. Wat tooling niet kan doen, is bepalen welke gegevens in uw organisatie werkelijk kritiek zijn, welke systemen dus gescheiden moeten worden, en welke responstijd u zich kunt veroorloven. Die oordelen blijven uw eigen verantwoordelijkheid.
Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van DIVD CSIRT en Computable.
Geschreven door
Tobias Lindqvist
Adversarial machine learning en de beveiligingseigenschappen van retrieval-systemen.