Two unpatched flaws in a helpdesk platform turned live sessions into root access in seconds, then handed the rest to an autonomous agent. The Dutch Institute for Vulnerability Disclosure (DIVD) was breached after attackers exploited zero-day vulnerabilities in its Zammad ticketing system, hijacked already-authenticated sessions, ran code as the zammad user, and escalated to root. According to BleepingComputer, citing DIVD, an AI agent then accessed services and exfiltrated data on a host that network segmentation kept from becoming a deeper network pivot. This was application-level session theft after authentication, not a stolen-password or one-time-code story at login.
How the Zammad zero-days seized live sessions
Public reporting puts initial access around 21 September 2026, with DIVD’s initial notice around 24 September 2026 and broader public detail on 30 September 2026. The core path was software, not social engineering of a workforce login. Attackers abused two zero-days tracked as CVE-2026-102489 and CVE-2026-102490 in the Zammad open-source helpdesk platform that DIVD ran.
According to DIVD’s account as reported by BleepingComputer, the flaws worked together. Used in combination, they let attackers hijack sessions, run code remotely, and escalate privileges from the Zammad user to root in seconds. DIVD tied that speed to “the agentic part of this hack.” Session material already represented a completed authentication. Holding that material meant the attacker did not need to present a password, complete a push, or type an OTP to act as the compromised context inside the application.
Zammad versions 6.3.0 through 6.5.4 were primarily exploitable for the session and remote code execution issue. Local privilege escalation hit a broader version range. DIVD worked the response with Merlon Security, alerted Zammad and other operators, and urged upgrades to Zammad 7 or taking vulnerable instances offline while the investigation continued.
Public reporting does not establish the precise cookie- or token-level mechanics beyond what those CVEs enabled. It also does not name a threat actor. What it does establish is the order of operations: vulnerability, live session control, code execution, root, then automated follow-on activity. Credential theft at a login form is not described as the entry path.
Zammad’s own site figures, cited in the same BleepingComputer coverage, put the product at over 2,000 customers and about 55,000 users. That installed base is why a helpdesk zero-day is not a niche lab curiosity. A ticketing platform sits on sensitive operational traffic: reporter contacts, attachment paths, internal notes, and integrations into the rest of a security team’s workflow. Session control on that class of app is already high-value access before anyone talks about root.
Root in seconds and an AI agent on the helpdesk host
Once the session path and RCE path lined up, the compromise did not wait on a human operator clicking through a manual playbook. DIVD described the attack as “loud and very, very messy.” The autonomous agent left decision logs that later helped forensics reconstruct what it tried to do. That messiness is useful after the fact. It does not change the fact that valid application and host privileges were already in attacker hands.
From the zammad user context, privilege escalation to root followed in seconds. That is host compromise on the helpdesk server, not a second workforce identity event. MFA challenges gate interactive authentication. They do not sit in the path of a local exploit chain that turns an application user into root after the app has already accepted the attacker’s session.
With that foothold, the agent accessed services and read data for exfiltration. According to DIVD’s disclosure path as covered by BleepingComputer, network segmentation and incident response stopped a deeper pivot into the wider environment. Public reporting does not establish how many records were affected or the exact volume of data taken.
The timeline compressed hard. Roughly a week sat between approximate initial access and public technical detail, with zero-day identification, vendor and peer notification, and guidance to upgrade or isolate instances landing in the middle. Investigation was still underway at disclosure, with DIVD saying further updates would follow. For defenders who run the same stack, the operational lesson is patch and isolation speed on an internet-facing or broadly reachable helpdesk tier, not a retrofit of login prompts after the session store has already been abused.
| Control surface | What happened at DIVD | Why it did not decide the outcome |
|---|---|---|
| Interactive login MFA | Not described as the entry path | Session material was taken after auth via app flaws |
| Zammad session handling | Hijacked through CVE-2026-102489 / CVE-2026-102490 | Live session equaled authenticated access inside the app |
| Host isolation on helpdesk | RCE as zammad, then root in seconds | Local exploit chain, not a new IdP login |
| Network segmentation | Limited blast radius after exfiltration began | Contained pivot; did not undo session or host loss |
Why this never became a password or MFA-code story
Security teams default to asking whether multifactor authentication would have changed the headline. For this incident the answer depends on the phase that actually failed. Attackers obtained already-authenticated session material through application vulnerabilities. No login challenge undoes possession of that material. Strengthening workforce login MFA would not have blocked remote code execution or root escalation on the helpdesk host once session control and the exploit chain existed. Data access rode privileges the attackers already held inside Zammad and on the server.
Public reporting does not establish which MFA method, if any, protected Zammad’s login at DIVD. That gap does not matter for the verdict on initial access. The documented path is zero-day session hijacking and post-auth host compromise. Treating it as a push-fatigue case, an SMS-code relay, or a helpdesk password-reset vishing case would invent a credential-phase story the sources do not support.
Workforce incidents that start with a coached login or a helpdesk recovery secret follow a different shape. Those cases live or die on whether a transferable factor exists for an attacker to steal in real time. DIVD’s Zammad event lived or died on whether unpatched application flaws could mint or seize a valid session and then run code. Different failure domain. Same blunt rule: map the control to the phase that broke.
What still matters for identity teams is blast-radius hygiene after any authenticated session exists. Short session lifetimes, aggressive revocation, continuous evaluation, and watching for impossible automation patterns are containment tools when software fails underneath you. They are not a substitute for patching a helpdesk platform that can hand an attacker root. DIVD’s own segmentation story shows containment can cap how far a messy, automated intrusion travels. Containment did not rewind the session hijack or the exfiltration that already occurred from the foothold.
The uncomfortable industry angle is who got hit. DIVD exists to find and disclose vulnerabilities for everyone else. Their helpdesk stack became the beachhead anyway, through zero-days in a widely deployed open-source product. That does not imply negligence in public reporting; it shows that vulnerability research shops run the same operational software as the enterprises they support, and that software can fail after login just as hard as any corporate ticket queue.
If you want to skip the attack details and go straight to what authentication can and cannot stop for post-auth session theft versus phishable logins, read the related article on mfa2point0.com: Why MFA would not have stopped DIVD’s Zammad session-hijack zero-days.
FAQ
How did attackers break into DIVD’s environment?
Attackers broke into DIVD by exploiting two zero-day vulnerabilities in the Zammad helpdesk platform, CVE-2026-102489 and CVE-2026-102490. According to DIVD via BleepingComputer, those flaws enabled session hijacking, remote code execution as the zammad user, and privilege escalation to root within seconds, after which an autonomous AI agent accessed services and exfiltrated data.
Was this a stolen-password or MFA-code attack on DIVD?
No. Public reporting on the DIVD Zammad breach describes initial access through application zero-days that yielded already-authenticated session material, not theft of passwords or one-time codes at a login prompt. MFA type on DIVD’s Zammad login is not detailed in public sources, and no login challenge undoes possession of live session material taken after authentication.
Did the AI agent replace the need for the Zammad exploits?
No. In the DIVD Zammad breach, the AI agent operated after the zero-days provided session control, code execution, and rapid privilege escalation. DIVD said the combined flaws allowed hijack, RCE, and root “in seconds, due to the agentic part of this hack,” and described the intrusion as loud and messy because the agent left decision logs useful to forensics.
How far did the DIVD intrusion spread beyond the helpdesk host?
According to DIVD’s account reported by BleepingComputer, network segmentation and incident response prevented a deeper network pivot after data was read and exfiltrated from the compromised Zammad position. Public reporting does not establish affected record counts or the exact exfiltrated volume.
Which Zammad versions were in the crosshairs for this attack path?
For the DIVD-related Zammad zero-day path, versions 6.3.0 through 6.5.4 were primarily exploitable for the session hijacking and remote code execution issue, with local privilege escalation affecting a broader range. DIVD and partners urged upgrades to Zammad 7 or taking vulnerable instances offline after the flaws were identified with Merlon Security.
