PoCForge (Cyber Security) reads the case as a test-design problem. A helpdesk is a launch point because it is internet-facing, holds other people’s secrets in tickets, and often runs with a service account on a host that can see more than the queue. An agentic operator changes the clock speed. It does not change the controls you should already have been able to show: version, exposure, segmentation, and what the service account can touch.
1. What DIVD has actually published
Case DIVD-2026-00014 is the incident. Case DIVD-2026-00015 is the vulnerability notification. The public timeline says first malicious access was 21 September 2026, DIVD blocked datacentre access on 22 September and started forensics with an external incident-response partner, and the issues were reported to Zammad on 24 September. On 30 September DIVD said the two zero-days together allowed session hijacking, remote code execution, and privilege escalation from the Zammad user to root, in seconds, “due to the agentic part of this hack”. From there the actor could reach other services and exfiltrate data. DIVD credits network segmentation and the response after detection with stopping deeper movement. The case remained an assume-breach investigation: signs of compromise were still being worked, and volunteer contact data was later confirmed exposed, which DIVD warned makes impersonation of volunteers easier.
DIVD’s vulnerability case, last modified 30 September 2026 in the copy reviewed for this note, states:
- CVE-2026-102489 — Zammad 6.3.0 to 6.5.4: a session-hijack issue that leads to code execution as the
zammaduser. The issue is also present in 7.0.0 to 7.1.3 but, DIVD says, not exploitable under those environment conditions. - CVE-2026-102490 — versions from 1.5.0 through 7.1.0-alpha: the local
zammaduser can escalate to root. DIVD’s CVE page scores a standalone scenario and a higher chained scenario; quote those pages rather than a single number in a board slide. The local issue is not, by itself, a remote attack. Zammad’s community response on 1 October 2026 said the details had been received, that remote exploitation of this issue alone is not the case, and asked operators to update to 7.2.0 and watch the project’s security advisories.
DIVD has been scanning for exposed vulnerable instances and notifying owners. That is their case, not a scanning method for this article. Confirm the fixed release on Zammad’s advisories before you freeze a version in a report: the case file was still open when this note was drafted, and “upgrade to the fixed line” matters more than a number copied from a single day.
On 29 September DIVD also said the intrusion was not Citrix NetScaler and that they saw no link yet to a named public threat actor. We are not folding this into an appliance story. The asset is the helpdesk.
2. Why a helpdesk is a launch point
Ignore the zero-day mechanics. Ask what a queue host is allowed to know. Tickets contain password resets, VPN details, identity documents, API keys pasted by customers, and the internal runbooks staff attach when they are tired. The host often has a database, an attachment store, outbound email, and an SSO client secret. Root on that host is not “a support tool was defaced”. It is a position from which other services on the same network can be asked, in the victim’s own voice.
Where is the helpdesk reachable?
Is the helpdesk on the public internet or only on a partner network? List every hostname, including old Docker hosts and temporary staging. Exposure plus an affected version is the condition DIVD was notifying owners about.
The queue is a secret store whether you intended that
The test is a sampled review with the data owner: credentials, identity documents, VPN data, API keys. Do not dump the database to make the point.
The Zammad user is the first privilege boundary
DIVD’s public description stops at code running as the Zammad user, then root. Your test records whether that user is confined, whether a local escalation is still present on your version, and whether root on this box is monitored.
The control DIVD says held
Prove the helpdesk segment cannot open sessions to identity, CI, file shares or other admin planes. Flat reachability is a finding even when the CVE is patched.
Contact data becomes an impersonation problem
DIVD said volunteer addresses were exposed and asked people to verify odd messages out of band. Write the equivalent check for your customers and staff before you need it.
What a test should record about the helpdesk host. Five questions, not a kill chain and not a reconstruction of the zero-days.
DIVD’s own outcome maps onto those boxes without any need to replay the intrusion: internet-facing Zammad, code execution as the service user, root on that host, access to other services, data leaving, and a subsequent impersonation risk for people whose contact details were in the volunteer set. Segmentation is the control they say held. Put segmentation in the test plan as something you demonstrate (routes, security groups, identity), not as a sentence in the architecture slide.
3. Detection and test objectives
These are questions for a scoped penetration test or an assume-breach review. They are not steps to reproduce CVE-2026-102489.
- Exposure. Which Zammad URLs are on the internet or on a partner VPN? Shadow IT helpdesks and old Docker Compose stacks count.
- Version. Is the build inside the ranges DIVD published? Record edition (package, Docker, helm) and the exact version, then check Zammad’s advisory for the fixed release you are required to hit.
- Service account. What can the
zammadOS user read, and is a path from that user to root an accepted local finding even after the remote issue is patched? DIVD’s local issue covers a very wide historical range. A host that blocks the remote issue can still be one local foothold away from root. - Neighbours. From the helpdesk network segment, which admin panels, file shares, CI hosts and identity providers answer? If the answer is “the same flat VLAN”, that is the finding DIVD’s segmentation control was designed to prevent.
- Ticket blast radius. Sample, with the data owner, whether live tickets contain credentials. The test is “secrets in the queue”, not “read the database via a vulnerability”.
- Identity after exposure. If the helpdesk holds staff or customer contact data, what would impersonation look like, and who checks unexpected mail? DIVD’s 1 October statement is the public example: volunteer addresses left, so messages that claim to be DIVD need an out-of-band check.
- Logs you actually have. Process creation, privilege changes, and new outbound connections from the helpdesk host. You do not need the exploit to know that a web user becoming root in seconds is the detection you lacked.
- Agent speed as a planning assumption. DIVD described automated next-step decisions and self-justifying comments in attacker notes. Detection that assumes a human pause between the queue and root will miss this pace. Tuning is still behavioural (new root, new egress), not a signature copied from a withheld exploit.
What the case files actually say
First malicious access on 21 September 2026; two Zammad issues reported on 24 September; outcome described as session hijack to code execution as the Zammad user, then root, then other services and data leaving. Segmentation and the response after detection are what DIVD credits with stopping deeper movement. Volunteer contact data was later confirmed exposed.
Mechanism stays out of the report
DIVD withheld the technical detail of the session issue and the local escalation while notification and investigation were open. A test report that re-derives that chain is the wrong artefact. Quote the case files, then stop.
Version, exposure, privilege, segment
Record edition and exact version against DIVD-2026-00015 and Zammad’s current fixed release, whether the URL is internet-facing, what the service account can touch, and whether the segment can reach unrelated admin planes. Retest after upgrade is a version check, not a second attempt.
Use DIVD’s published outcome. Do not fill the gaps they left while notification was open.
Helpdesk assume-breach objectives
0 checked
Ticks stay in this browser. They are not written back to the engagement file.
4. What a report should not do
Do not paste a reconstructed chain because a public blog sketched one. DIVD withheld technical detail while notification and investigation were open. A VAPT report that re-derives a zero-day against a customer’s helpdesk is the wrong artefact. The right artefact is version evidence, exposure, segmentation, secret-in-ticket handling, and a retest after upgrade.
Do not claim a named intrusion set beyond what DIVD said. Their 29 September statement was explicit: no link established to a known public actor, and no facts yet proving they were targeted for their most sensitive holdings — while not ruling that out. “Agentic” here is their description of pace and of self-justifying notes in logs, not a vendor malware family name.
Adjacent research, kept distinct: agents as a product surface is about tools you deploy; this case is about an agent operator against a support platform. Loom and SageMaker is a cloud control plane. GitLab’s AI Gateway is a template sandbox on a broker you host. Same month, different assets.
Sources
- DIVD-2026-00014 (statements 24 September–1 October 2026)
- DIVD-2026-00015 (Zammad vulnerability case)
- DIVD CVE page for CVE-2026-102490
- Zammad community update, 1 October 2026, pointing operators to 7.2.0 and the project’s security advisories
Frequently asked questions
Should every Zammad be taken offline?
DIVD’s notification case treats affected exposed instances as something owners must patch, and Zammad’s 1 October community post asked operators to update to 7.2.0. If you cannot upgrade an internet-facing build that sits in the vulnerable ranges, removing it from the internet is the conservative control while you confirm the current fixed release. This note is not a substitute for the vendor advisory.
Does patching the remote issue make the host safe?
No. CVE-2026-102490 is a local escalation from the Zammad user to root across a wide version range. DIVD notes a host that is not practically exposed to the remote issue can still be affected by the local one if something else can run as that user. Test local privilege and segmentation, not only the listening port.
Will this article show how the session hijack worked?
No. DIVD described the outcome — session hijack to code execution as the service user, then root — and kept the mechanism limited while notification continued. Rebuilding that chain is out of scope for a defender’s research note.
How is “agentic” being used?
As DIVD used it: the operator moved in automated steps, left notes justifying its own actions, and compressed the path from the helpdesk to root into seconds. Detection and containment have to assume that pace. It is not a claim about a specific model or a named threat group.