The Agent Took the Help Desk: Zammad's Zero-Days and the Breach of the People Who Report Breaches

On Monday, September 21, 2026, something logged into the ticketing system of the Dutch Institute for Vulnerability Disclosure and did not behave like a person.

DIVD is a volunteer nonprofit whose whole job is finding exposed, vulnerable systems and warning their owners. On September 30 it disclosed that attackers had broken in through two previously unknown flaws in Zammad, the open-source help desk it uses to handle reports. In DIVD's own words, the chain "allowed the attackers to hijack sessions, run code remotely, and escalate privileges from the Zammad user to root, in seconds." The organization says the operator wasn't a human at a keyboard. It was an AI agent, and it left its reasoning behind in the logs.

The flaws now have numbers: CVE-2026-102489 and CVE-2026-102490, both scored CVSS 9.4. CISA added both to its Known Exploited Vulnerabilities catalog on October 2 with a remediation deadline of October 5, which is tomorrow. If you run Zammad, stop reading after the next section and go check your version. Then come back, because the more interesting lesson here isn't about Zammad at all.

What we actually know (and what nobody has published)

I'll be strict about this, because a lot of the coverage has filled gaps with guesses.

The timeline, as reported by DIVD and corroborated by SecurityWeek, BleepingComputer and SecurityOnline:

• September 21: initial access through Zammad.
• September 22: DIVD spots suspicious activity, cuts access to its data-centre infrastructure and brings in incident response firm Merlon Security.
• September 24: DIVD reports the flaws to Zammad.
• September 26: DIVD starts scanning the internet for other exposed instances and notifying owners, which is exactly what you'd expect from DIVD.
• September 30: public disclosure naming Zammad as the entry point.
• October 2: both CVEs land in CISA KEV.

The flaws. CVE-2026-102489 is a session hijack that leads to remote code execution as the zammad service user. SecurityWeek and the security research blog xhack both describe it as requiring network access and no credentials. It affects Zammad 6.3.0 through 6.5.4. Versions 7.0.0 through 7.1.3 contain the same bug, but DIVD says environmental conditions there prevent exploitation. CVE-2026-102490 is a local privilege escalation from the zammad user to root, and it reaches back a long way: SecurityOnline lists it as affecting 1.5.0 through the 7.1.0 alpha. The guidance attached to the KEV entry is to move to 7.2.0. DIVD's own advice is blunter: upgrade to version 7 or take the thing offline.

What was taken. DIVD has confirmed that volunteer email addresses were exfiltrated, possibly with other contact details. It hasn't yet said which volunteers or which fields. The attackers did pivot to additional services, but according to SecurityWeek's reporting, "network segmentation prevented them from going deeper into the environment."

What nobody has published is the mechanism. Neither DIVD nor Zammad has described how the session hijack works. The xhack team went as far as diffing Zammad's source between 7.1.3 and 7.2.0 and said they found nothing they could identify as the fix. The only public clue is DIVD's detection script, which hunts logs for session cookie values and websocket client state showing up in error output. That tells you where the traces end up. It doesn't tell you how the bug works, and I'm not going to pretend otherwise.

"Fast but messy"

The detail that made this story travel is the attacker. DIVD described the intrusion as "loud and very, very messy" and said: "We could see the agent working automated, because after every action it decided the next step itself, at the speed of light and sloppy logic or pattern."

The scripts it dropped contained notes in which the agent justified its own choices. DIVD's response to finding a step-by-step explanation of the attack inside the attack tooling was a dry "Who has time for that anyway?" Answer: something that isn't paying for its own time.

We covered the infrastructure side of this trend last week, when Google found an agent-run C2 sorting 23,800 stolen secrets by whether they still work. DIVD gives us the other half: what an agent looks like from inside the victim network. And the honest description is that it looks like a very fast, very confident intern who has been told to try everything.

I spend most of my working week on detection engineering, and I want to push back on the reflex reaction to this story, which is "AI attackers are faster than us, so we lose." Speed is real. Root in seconds means your SOC's 15-minute triage SLA is a historical document. But speed and stealth trade against each other. A careful human operator who lands on a help desk server will read config files quietly, pick one credential, and test it once from a sensible place. An agent optimizing for progress will enumerate, try, fail, retry, and move to the next thing, all inside a minute. That is the noisiest possible attacker profile, and the most catchable, provided you've put something in its path that it can't help touching.

Your help desk is a credential store with a ticket UI

Here's the part that applies to you even if you've never heard of Zammad.

Teams think of the ticketing system as a low-value app. It sits outside the "crown jewels" list on most risk registers I've reviewed. It rarely gets the EDR coverage the domain controllers get, and it often runs as a self-hosted VM somebody stood up years ago and nobody upgraded, which is exactly how a box ends up on 6.5.x in late 2026.

Now think about what's actually in it. From incident work and from purple-team exercises where we were allowed to search ticket data, this is what typically turns up:

• Pasted credentials. "Here's the service account password so you can reproduce it." Users do this constantly, and agents on the help desk side do it back when they hand over temporary passwords.
• Password reset history. Every reset ticket is a record of who gets locked out, how identity was verified, and which agent handled it. That's a social engineering script, already written.
• Attachments. VPN profiles, .env files attached to bug reports, screenshots of admin consoles with tokens visible in the address bar, exported config backups.
• Integration secrets. The ticketing app itself holds API tokens for email, chat, the CRM, LDAP or SSO connectors. On a box where the attacker has root, those are a file read away.
• The contact list. Names, emails and roles for everyone who has ever filed or handled a ticket.

For DIVD specifically, the ticket queue is also where vulnerability reports arrive. DIVD hasn't said any report contents were stolen, and I'm not suggesting they were. But think about what a disclosure organization's queue holds by design: lists of systems that are vulnerable and not yet fixed. That's why the help desk deserves the same tier as your identity provider. If it can reset a password or hold a secret, it is part of your identity system.

The stolen emails are the real payload

DIVD flagged this itself: "For DIVD volunteers (and others) this means a higher risk of social engineering, because this makes it easier for someone to pose as a DIVD'er."

Spend a minute on how bad that is. DIVD's daily business is emailing organizations it has never spoken to, telling them a system is vulnerable, and asking them to act. Recipients have learned to trust those messages because they come from a respected nonprofit and are usually right. Now an attacker holds a list of real volunteer names and addresses. The perfect lure writes itself: "Hi, I'm a DIVD volunteer, your Zammad instance appears vulnerable to CVE-2026-102489, please run the attached check script." It references a real CVE, in a real KEV entry, from a person who really volunteers there, and DIVD really is scanning for this right now.

We've written before about a fake government request that passed every check at Revolut because it came from a trusted channel. The DIVD data enables the same move at the level of the whole security community. If you get a vulnerability notification in the next few weeks, verify the sender through a channel you looked up yourself, not one in the email.

Root on the box changes the forensic picture

One more uncomfortable point. CVE-2026-102490 ends at root. Once an attacker has root on a Linux host, every log on that host is a suggestion. We made the same argument about Cisco ISE CVE-2026-76460 and logs that can delete themselves: the evidence you'd use to scope the incident lives on the machine the attacker controls.

DIVD caught this one partly because the agent was sloppy and narrated its own work. Don't build your plan around the next one being so polite. An agent framework is one prompt tweak away from "clean up after yourself."

So detection that matters here has to be off-box: signals generated somewhere the attacker doesn't control, triggered by actions the attacker can't avoid taking.

Where deception fits an attacker like this

This is where I think the DIVD incident is actually good news for defenders, and it comes down to the attacker's habits.

An agent that "decides the next step itself" after every action does three things predictably: it reads everything it can reach, it tries every credential it finds, and it probes every service it can see. Each of those is a place to put a tripwire that fires off-box with no ambiguity.

Plant credentials in the ticket data. Create a few realistic old tickets with a pasted "temporary" service account password, a .env attachment with a cloud key, a VPN config. None of them are real. Nobody legitimate ever has a reason to use them, which means the first authentication attempt with any of them is an incident, not a maybe. A careful human might skip a suspicious-looking credential. An agent told to escalate will try it, usually within seconds of reading it.

Put decoy services next to the help desk. DIVD's attacker pivoted to additional services, and segmentation stopped it. Segmentation is the right control, but it's a wall, not an alarm. Decoy SSH, RDP, database and admin ports in the same segment, the kind of thing MineField deploys, turn that pivot into a signal. The noisier the scanner, the faster it trips one.

Seed the contact list. This one is cheap and under-used. Add one or two decoy staff addresses to your ticketing system's contacts that appear nowhere else. If phishing ever lands in those mailboxes, you know where the list came from, and you know your contact data is now in use, even if you never saw the intrusion. For an organization like DIVD, that's the earliest warning you'll get that impersonation has started.

Two caveats from experience. First, decoys in ticket data have to look like the ticket data around them: same naming conventions, believable dates, realistic attachment names. An agent may be sloppy, but it still ranks what it reads. Second, route the alerts somewhere that wakes someone up. A tripwire that posts to a dashboard nobody watches overnight is the same as no tripwire, and DIVD's attacker went from session to root in seconds.

What to do this week

1. Find every Zammad instance. Include the one the support team stood up on its own. Anything on 6.3.0 through 6.5.4 is exposed to the full chain. Anything older than 7.1.0 is exposed to the root escalation once someone has a foothold.
2. Upgrade to 7.2.0 or take it offline. CISA's deadline for federal agencies is October 5. Treat it as yours.
3. Run DIVD's check script against your logs before you upgrade, not after. You want the evidence while it's still there.
4. Assume compromise if you were exposed and internet-facing. Rotate every integration token the app holds (mail, SSO, LDAP bind accounts, API connectors), and every credential that was ever pasted into a ticket. Yes, that means searching ticket history for passwords. You'll be unpleasantly surprised.
5. Retier the help desk. Put it in the same monitoring and patching tier as your identity infrastructure. If it can reset a password, it is identity infrastructure.
6. Warn your people about vulnerability-notice phishing. Especially security and IT staff, who are the most likely to act fast on a credible CVE warning.

The irony is the lesson

The organization that spends its volunteers' evenings warning the rest of us about exposed systems got hit through a ticketing app it didn't think of as exposed. That isn't a criticism of DIVD. Its detection within a day, its segmentation, and its decision to publish the agent's own notes are a better response than most companies manage. It's a reminder that every team has a "boring" system holding more trust than it was ever designed to protect.

Agents will get quieter. This one wasn't, and DIVD was lucky to see it narrate its own attack. The defense that holds up as they improve is the one that doesn't rely on catching how the attacker gets in, and instead fires the moment it touches a credential or service that only an intruder would use. If you'd like to see what fake credentials in your help desk and decoy services beside it would look like in your own environment, book a Mine2 demo and we'll walk through it with you.