An AI Agent Went From Helpdesk to Root in Seconds: What the Zammad Breach Means for MSPs

Most of the vulnerability news I read is “patch this appliance you probably don’t own.” This one is different. The box that got popped was a helpdesk, and the organization that got popped was the Dutch Institute for Vulnerability Disclosure (DIVD), a group whose entire job is finding and reporting this kind of thing. And according to DIVD, the attacker was an autonomous AI agent.

If you run an MSP, your ticketing system is one of the most trusted and most connected systems you have. So even if you’ve never touched Zammad, this is worth ten minutes of your time.

What happened

Here’s the timeline from DIVD’s own case write-ups:

1. September 21, 2026 — First access. Attackers got into DIVD through their Zammad helpdesk.
2. September 22 — DIVD detected the intrusion.
3. September 22–23 — DIVD analyzed and reproduced the vulnerabilities.
4. September 24 — DIVD reported the flaws to Zammad and publicly acknowledged the breach.
5. September 26 — DIVD began scanning for exposed instances and notifying owners.
6. September 29 — The two CVEs were published.
7. October 2 — CISA added both to the Known Exploited Vulnerabilities (KEV) catalog, with a federal remediation due date of October 5.

The two bugs:

• CVE-2026-102489 — a session hijack leading to remote code execution as the zammad user. DIVD lists versions 6.3.0 through 6.5.4 as exploitable. Versions 7.0.0 through 7.1.3 contain the flaw, but DIVD says it isn’t practically exploitable there because of environmental factors.
• CVE-2026-102490 — a local privilege escalation from the zammad user to root. DIVD’s advisory says it affects versions 1.5.0 through 7.1.0-alpha on Linux and Docker. runZero notes the vendor disputes that scope.

On their own, DIVD scores them at CVSS 8.7 and 8.5. Chained together, the combination scores 9.4. In DIVD’s words, used together “they allowed the attackers to hijack sessions, run code remotely and escalate privileges from the Zammad user to root, in seconds.”

DIVD says volunteer data got out, including DIVD email addresses and possibly contact details, and that the investigation is ongoing.

Why “AI agent” is the part to pay attention to

Let’s be clear about what’s new and what isn’t. Session hijacking, RCE and local privilege escalation are not new bug classes. What DIVD is describing is speed and autonomy. From their write-up, the attack was “loud and very messy, with the agent working automated and deciding each next step itself at speed.” Help Net Security quotes DIVD noting the agent made mistakes, like polluting its own man-in-the-middle attack with password spraying, and left plenty of comments in its scripts. In one case, DIVD says, “the agent justifies its own actions, explaining why what it’s doing is okay and really not phishing.”

So it wasn’t elegant. It didn’t need to be. It went from a web app to root faster than any human on call could have reacted.

That changes the math for small shops. A lot of us quietly rely on “we’ll notice and respond” as a control. When the attacker goes from initial access to root in seconds, the only controls that matter in that window are the ones already in place: patch level, what the compromised box can reach, and what it holds.

Why MSPs should care even if you don’t run Zammad

Think about what lives in a ticketing system at a typical MSP:

• Client network notes, IP plans and VLAN layouts
• Credentials pasted into tickets “just this once”
• Email integration that can send as your support address
• Integrations into RMM, documentation and billing tools
• For integrators like us at Emerald Security, notes on camera systems, NVRs, door controllers and gate operators

That makes the helpdesk a map of every client you have. Self-hosted helpdesks are also common in smaller shops because they’re cheap and flexible. I’m not knocking that. I self-host plenty. But self-hosting means you own the patching, the backups and the blast radius.

📝 Note: Swap “Zammad” for whatever you run (a PSA, osTicket, a Jira Service Management instance, a documentation platform) and the rest of this post still applies.

What saved DIVD: segmentation

The most useful line in DIVD’s write-up isn’t about AI at all:

“Thanks to proper network segmentation and the actions of our IT and Incident Response Team after detection, we were able to stop the attackers from going deeper into our systems and network.”

The agent got root on the helpdesk and pivoted to other services, but segmentation limited how far it got. That is the boring control that works whether the attacker is a person, a script or an agent.

For a small MSP, segmentation for a helpdesk host looks like this:

1. Put it in its own VLAN or DMZ. It should not sit on the same flat network as your management workstations, RMM server or backup target.
2. Allow inbound only what it needs. Usually HTTPS from a reverse proxy, and SSH from a management subnet.
3. Restrict outbound too. This is the one people skip. A helpdesk needs DNS, NTP, mail and maybe a package mirror. It does not need to reach your hypervisor management, your NAS or your client VPNs.
4. Keep credentials out of it. Use your password manager or documentation platform for secrets, and link to them instead of pasting them into tickets.

Here’s an nftables example for a Linux helpdesk host that only allows the outbound traffic it needs. Adjust the addresses for your environment, and test from the console, not over SSH you might lock yourself out of. Use at your own risk.

#!/usr/sbin/nft -f
# /etc/nftables.d/helpdesk-egress.nft
# Outbound allow-list for a helpdesk server. Everything else is logged and dropped.

table inet helpdesk_egress {
    chain output {
        type filter hook output priority 0; policy drop;

        ct state established,related accept
        oifname "lo" accept

        # DNS and NTP to the internal resolver/time source only
        ip daddr 10.20.0.1 udp dport { 53, 123 } accept
        ip daddr 10.20.0.1 tcp dport 53 accept

        # Mail: IMAPS and submission to your mail host
        ip daddr 203.0.113.25 tcp dport { 587, 993 } accept

        # Package updates through an internal proxy/mirror
        ip daddr 10.20.0.10 tcp dport 3128 accept

        log prefix "helpdesk-egress-drop " level warn
    }
}

Load it with sudo nft -f /etc/nftables.d/helpdesk-egress.nft, then watch journalctl -k | grep helpdesk-egress-drop for a few days to catch anything legitimate you missed. If you run UniFi gateways, you can do the same thing at the network layer with zone-based firewall rules, and I’d do both.

What I’d do this week

If you run Zammad, or host it for a client:

1. Find every instance. Including the “temporary” one somebody spun up for a project. runZero published a fingerprint query if you use their scanner.
2. Check the version. runZero recommends upgrading to 7.2.0 or later and notes that 6.5 and earlier are end-of-support and no longer get security fixes. DIVD’s guidance is to upgrade to version 7 or take the system offline.
3. Run DIVD’s IOC check. DIVD published a script that checks Zammad log files for signs of abuse. It’s linked from their DIVD-2026-00015 case page.
4. If you find indicators, assume root. Rebuild the host rather than cleaning it, and rotate every credential that system ever stored or could reach: mail accounts, API tokens, integrations, and anything pasted into a ticket.
5. Lock down egress like the example above.

Here’s a quick Bash script to check the installed version on a host, whether it’s a package install or Docker:

#!/usr/bin/env bash
# zammad-version-check.sh - report the installed Zammad version and compare it to a minimum.
set -euo pipefail

MIN_VERSION="7.2.0"
ver=""

if command -v dpkg-query >/dev/null 2>&1 && dpkg-query -W -f='${Status}' zammad 2>/dev/null | grep -q "install ok installed"; then
    ver="$(dpkg-query -W -f='${Version}' zammad)"
    source="deb package"
elif command -v rpm >/dev/null 2>&1 && rpm -q zammad >/dev/null 2>&1; then
    ver="$(rpm -q --qf '%{VERSION}' zammad)"
    source="rpm package"
elif command -v docker >/dev/null 2>&1; then
    image="$(docker ps --format '{{.Image}}' 2>/dev/null | grep -i 'zammad' | head -n1 || true)"
    if [[ -n "$image" && "$image" == *:* ]]; then
        ver="${image##*:}"
    fi
    source="docker image ${image:-<none running>}"
fi

if [[ -z "$ver" ]]; then
    echo "Zammad not found (or Docker image has no version tag). Check manually."
    exit 2
fi

ver="${ver%%-*}"   # strip package build suffixes like 7.1.3-1749123456.abc

if [[ ! "$ver" =~ ^[0-9]+\.[0-9]+ ]]; then
    echo "Found tag '$ver' from $source - not a version number (e.g. 'latest'). Check inside the container."
    exit 2
fi

lowest="$(printf '%s\n%s\n' "$MIN_VERSION" "$ver" | sort -V | head -n1)"
if [[ "$lowest" == "$MIN_VERSION" ]]; then
    echo "OK: Zammad $ver ($source) is at or above $MIN_VERSION"
else
    echo "UPGRADE NEEDED: Zammad $ver ($source) is below $MIN_VERSION"
    exit 1
fi

It exits 0 when you’re at or above the minimum, 1 when you need to upgrade, and 2 when it couldn’t tell, so you can drop it into an RMM script check and alert on non-zero.

The bigger lesson

I don’t think the takeaway here is “AI is coming for your helpdesk.” The takeaway is that the gap between “vulnerable” and “owned” is shrinking, and the gap between “owned” and “everything it can reach is owned” is entirely up to how you built the network.

What I tell clients about cameras applies here too: assume any internet-facing device will eventually have a bad day, and design so that a bad day on one box stays on that box. DIVD did that, and it’s the reason their write-up talks about volunteer contact details instead of a lot worse.

Patch the helpdesk like it’s a firewall. Segment it like it’s already compromised.

Sources

• DIVD-2026-00015 — Vulnerabilities in Zammad during investigation of case DIVD-2026-00014 — DIVD, published September 26, 2026, updated October 1, 2026
• DIVD-2026-00014 — When, not if… — DIVD, updated October 1, 2026
• CVE-2026-102489 — Undisclosed RCE in Zammad v6.3 and higher — DIVD, September 29, 2026
• CVE-2026-102490 — Undisclosed LPE in Zammad v1.5.0 to v7.1.0-alpha — DIVD, September 29, 2026
• Zammad Zero-Days Exploited in AI-Powered DIVD Hack — SecurityWeek, October 1, 2026
• AI agent used Zammad zero-days to breach Dutch vulnerability disclosure non-profit — Help Net Security, October 1, 2026
• U.S. CISA adds Zammad GmbH Zammad flaws to its Known Exploited Vulnerabilities catalog — Security Affairs, October 2, 2026
• Zammad vulnerabilities: Find impacted installations — runZero, October 2, 2026