Auditing Zammad After an Autonomous Agent Chained Zero-Days Against DIVD

The DIVD Zammad Incident: What the Reports Actually Say

On 2026-10-01, SecurityWeek, Security Affairs, and TechTimes each ran a version of the same story: an autonomous AI agent chained zero-days in Zammad, the open-source helpdesk, and took over DIVD's systems in seconds. This post covers what that reporting actually establishes, then turns it into an audit plan you can run against your own self-hosted Zammad instance — the exposed API surface, the long-lived tokens, the integrations that fetch attacker-controlled URLs, and the unpatched root flaw that the agent-speed framing keeps burying. DIVD is the Dutch Institute for Vulnerability Disclosure, a volunteer nonprofit whose whole job is finding other people's bugs and coordinating their disclosure. Getting owned this way is a specific kind of bad day.

That's the claim. What I have in hand is the reporting: no CVE record, no vendor advisory, no exploit chain, no telemetry, no access to either party's systems. Everything below about the attack itself is secondhand, and I'm marking it that way rather than dressing it up.

My position up front: the agent isn't the headline. The unpatched root flaw is. Speed multiplies an unpatched bug, it doesn't substitute for one — an autonomous agent that builds a working chain in seconds is only interesting if the chain was still there to build. If you self-host Zammad, or any ticket system with an API, treat the rest of this as an audit plan for the class of problems the reporting describes. It is not a reconstruction of what happened at DIVD, and I won't pretend otherwise.

What the Reporting Establishes — and What It Leaves Out

What's missing from the material, and what I refuse to invent:

• CVE identifiers for any of the chained issues
• affected Zammad versions
• which components the chain touched
• the initial access vector
• whether Zammad or DIVD has published a disclosure since
• how "seconds" was measured — first request to first shell, or first login to full control

If you find a post that fills all of those in confidently, ask where the numbers came from. Mine don't exist, so the slots stay empty.

Why This Is an Exploitation-Tempo Problem, Not a Model Problem

The change worth internalizing is exploitation tempo, not machine autonomy. The attacker-side loop — spot a candidate flaw, validate it, chain it, pivot — has shed most of its human latency. That loop used to be gated by an operator's attention. Now it runs unattended, and the output that matters isn't cleverness, it's throughput.

The defender-side loop hasn't compressed at all. It still runs through human review, vendor triage, and a maintenance window someone has to schedule on a Tuesday night. That asymmetry is the whole story, and it doesn't care whether the thing that found the bug was a language model or a fuzzer with a cron job.

Caveat, plainly: I tested none of this, and "seconds" comes from the reporting, not from my own timing. I can't verify the clock or when it started.

The numbers you can actually move are mean-time-to-exploit against mean-time-to-patch, plus the gap between an exploit attempt and anyone noticing it. Model speed is out of your hands. Patch latency and detection latency are not. Work on those.

Auditing a Self-Hosted Zammad Deployment

Scope contract first: this is the class of bugs worth checking on any self-hosted ticket system. It is not a claim about which bug was used against DIVD, because I don't know which bug was used against DIVD. Think of it as triage hygiene you should already have done.

Map the Exposed Attack Surface Before You Read Code

Inventory first, code second. Which Zammad instances answer on the public internet? What else lives on that host — Postgres, Redis, Elasticsearch, a reverse proxy with its own admin panel? Once the app process is running, which internal networks can it reach?

## Does the API answer strangers? Run from outside your network.
curl -sS -o /dev/null -w 'status=%{http_code}\n' \
  https://tickets.example.org/api/v1/users

The response you want to see:

status=401

A 401 is correct — Zammad rejects the unauthenticated request. A 200 with a JSON array of users is the finding, and it means something in front of the app or in the API config is wrong. Repeat it against /api/v1/tickets and the setup/installer path. One caveat: I didn't run this against a live public instance while writing, so treat that output as the expected shape, not a captured transcript. Scan only hosts you own.

Audit API Tokens, Sessions, and Role Creep

Zammad's API tokens are the classic long-lived credential problem: created for a script, never scoped, never expired, still valid three admins later.

-- Check your schema first: d tokens
SELECT t.id, t.name, t.action, u.login, t.expires_at, t.persistent
FROM tokens t
JOIN users u ON u.id = t.user_id
ORDER BY t.created_at DESC;

The shape to hunt for is a persistent = true row with expires_at NULL. That's a permanent key to your ticket data, sitting in every leaked backup and pasted config.

SELECT u.login, r.name, u.active, u.last_login
FROM users u
JOIN roles_users ru ON ru.user_id = u.id
JOIN roles r ON r.id = ru.role_id
WHERE r.name IN ('Admin','Agent')
ORDER BY r.name, u.last_login DESC NULLS FIRST;

Nulls at the top are accounts holding an admin or agent role that have never logged in. Someone widened a role "temporarily" and the temp is still there. I didn't execute these against a live instance for this post — verify column names against your own Zammad version before trusting them.

Integrations and Outbound Trust: Where Server-Side Fetch Bugs Live

This is where I'd spend most of an audit. Webhooks, IMAP and mail ingestion, Elasticsearch connectors, and any integration that fetches a URL are all places where attacker-controlled input — a ticket subject, an email body, a link in a signature — reaches a server-side fetch. That's SSRF, template injection, and blind internal recon in one spot.

For each configured integration, ask two things: can an outsider influence the URL, headers, or body? And if the fetch succeeds, how far can it reach? Egress restrictions answer the second question even when you get the first one wrong.

Why the Zammad Root Flaw Is Still Unpatched

The reporting says the root flaw remains unfixed. If you've ever run infrastructure for a volunteer nonprofit, that won't surprise you, and it isn't laziness.

There's no vendor patch to apply. The remaining option is an upgrade, and on a self-hosted Zammad install that means Ruby, Rails, Postgres, and Elasticsearch moving together. You find out after the fact that ticket history renders differently, search needs a full reindex, and the window you scheduled means incoming vulnerability reports sit unread while you work. Nobody on staff owns security full time, and the person who built the stack may have moved on.

So my ranking is deliberate: network isolation, egress restriction, and log retention come before the upgrade. They cut impact while the patch is pending, they're reversible, and they survive the upgrade. The upgrade stays on the list. It just isn't first when you currently have no compensating control at all.

A Zammad Defensive Checklist You Can Run This Week

Limits of This Analysis: What I Did Not Verify

No CVE, no vendor advisory, no reproduction of the chain, no access to DIVD or Zammad systems. Everything above about the attack comes from secondary reporting dated 2026-10-01; the audit guidance is general practice for self-hosted ticket systems, not a reconstruction. The queries and the curl check were not run against a live instance while writing this. Whether Zammad or DIVD has published anything since, I don't know.

My Take: Patch Latency Beats Agent Speed

The failure to patch is worse than the speed of the agent. A chain that takes seconds against a system patched last month is a non-event. The same chain against a system nobody owns is a full compromise. Framing this as an AI story instead of a patch-latency story is exactly how the next version of it happens, because it points attention at the tool rather than the unpatched thing the tool walked through.

If you run Zammad today, do one thing first: take the admin and API paths off the public internet before you read another word about autonomous agents. Then rotate tokens. The upgrade can wait a week. The exposed endpoint cannot.

Further Reading

The incident coverage I relied on — SecurityWeek, Security Affairs, and TechTimes, all published 2026-10-01 — reached me through news aggregation links without stable canonical URLs, so I'm not listing them as sources here. No CVE record or Zammad vendor advisory appeared in the source material, and I haven't fabricated CVE IDs, version ranges, or advisory titles to fill the gap. For anything official, start with the Zammad source repository and its release notes. I'd rather this section stay thin than imply verification I didn't do.