The Vendor Called the Researchers Irresponsible — Inside the 48-Hour Disclosure Fight Behind the AI Agent Breach

• The vendor at the center of the AI agent breach just openly clashed with the researchers it hosted: Zammad says DIVD’s 48-hour disclosure was “not a responsible way to handle vulnerabilities” — DIVD reported the flaws September 24 and went public September 26.
• Zammad’s counter-statement rewrites the patch math: current versions were never exploitable for the remote-code flaw (CVE-2026-102489) — only end-of-life 6.5-and-older installs are exposed, and the hardening shipped in Zammad 7.2.0.
• The second flaw (CVE-2026-102490) went public before the vendor received any technical details — DIVD held them back, the CVE published anyway, and only arrived at Zammad’s desk October 1.
• The breach stole email addresses of volunteer security researchers — the exact people who were about to receive DIVD’s outreach — creating a live social-engineering target list.
• For Filipino teams running self-hosted helpdesks: if your ticketing server predates version 7.2, your update this week is not housekeeping — it is the whole defense.

The AI agent that chains zero-days and escalates to root “in seconds” was only the first act — the Zammad disclosure fight thrst chapter of the DIVD story we documented last week. The second chapter arrived October 1 — not from the attackers, but from the vendor itself, in a public forum post that reads like a formal objection filed against the people who investigated the crime.

The Zammad disclosure fight began when Zammad, the German company whose open-source helpdesk software was the doorway into the Dutch Institute for Vulnerability Disclosure (DIVD), published a statement on its community forum disputing how the researchers handled the disclosure. The sentence that matters: “We do not consider this a responsible way to handle vulnerabilities.” The researchers at DIVD — the volunteer organization that assigns CVE numbers and spent its own breach response mapping the flaws — reported the vulnerabilities to Zammad on September 24 and published limited disclosure two days later, on September 26, before the vendor had fixes or full details.

Twenty-four hours after the vendor’s objection went up in the middle of the Zammad disclosure fight, the standoff dissolved: DIVD sent the technical details for the privilege-escalation flaw, Zammad confirmed receipt and began work, and both sides converged on the same instruction for administrators — update to Zammad 7.2.0 now. But by then the dispute had already surfaced the real story underneath this breach: the industry has no working rulebook for disclosure timelines when an AI agent is the attacker, the victim is the disclosure body, and the clock is measured in hours, not the traditional 90 days.

The Zammad Disclosure Fight, in Numbers

Zammad’s statement attacks the disclosure with the same precision DIVD used: the Zammad disclosure fight is now a duel of letters, not logs, and it att the breach — via its own calendar. Here is the vendor’s framing, verified against DIVD’s published case page for incident DIVD-2026-00015:

• September 21: the agentic attack breaches DIVD using two Zammad zero-days.
• September 22–23: DIVD’s team analyzes and reproduces the vulnerabilities.
• September 24: DIVD reports the flaws to Zammad, notifies the Dutch data protection authority and NCSC, and contacts police.
• September 26: DIVD scans the internet for exposed Zammad instances, publishes limited disclosure for both CVEs, and starts notifying owners of vulnerable installs — 48 hours after the vendor report.
• October 1: Zammad posts its objection; DIVD delivers the CVE-2026-102490 details the same day; Zammad confirms work is underway.

The contested segment is the last one-and-a-bit days: report on the 24th, public on the 26th. Zammad’s position is that the public disclosure arrived before the vendor could verify, fix, or even see the details of one of the two flaws — the privilege-escalation bug had no technical details attached to the initial report at all. DIVD’s position, implicit in its timeline, is that attackers were already in the wild using the flaws, the victim was a disclosure nonprofit, and every additional day without public detection advice left thousands of unpatched helpdesks blind. Both things are true. That is why this Zammad disclosure fight matters.

The Patch Math Nobody Was Telling You

Disputes aside, Zammad’s statement contains the most useful technical clarification since the breach went public — and it changes what administrators should actually do.

The remote-code-execution flaw, CVE-2026-102489 (CVSS 9.4 when chained), is the one that turned the Zammad disclosure fight from an etiquette quarrel into an emergency, because it is that let the attackers hijack sessions and run code without logging in. According to the vendor — and confirmed on DIVD’s own case page — exploitation is only possible on Zammad 6.5 and older, because the older runtime environments those versions use no longer exist in the current release l

ine. Versions 7.0 through 7.1.3 carry the vulnerable code but cannot be exploited “due to environment conditions.” Those older versions, the vendor notes, reached end of support some time ago — meaning fixes for them do not exist and never will. The hardening for the affected code shipped in Zammad 7.2.0, the current stable release, published September 23.

The second flaw, CVE-2026-102490, is the local privilege escalation that defined the endgame of the Zammad disclosure fight — it took the attackers from helpdesk user to full root. It affects nearly every Zammad version ever released including the current alpha — but with a critical qualifier the vendor attached on October 1: it cannot be exploited remotely on its own. An attacker already needs access to your server — exactly what the first flaw provided in the DIVD breach. Chained, they are devastating. Alone, the second bug requires a foothold you should not have granted in the first place.

The practical scoreboard for anyone running this software, condensed from both organizations’ statements:

• Running 7.2.0 (released Sep 23): protected from the session-hijack chain; the local-escalation fix is in active development — watch the vendor’s GitHub security advisories.
• Running 7.0–7.1.3: not exploitable for the remote flaw in practice; still upgrade to 7.2.0 — the privilege-escalation details arrived October 1 and a fix is coming.
• Running 6.5 or older: exploitable, unsupported, unpatchable. No fix exists. Upgrade or take the instance offline — this is the configuration the AI agent walked through at DIVD.

DIVD’s guidance stays live for everyone following the Zammad disclosure fight: its log-check script scans Zammad logfiles for indicators of compromise, worth running regardless of version — because the September 21 attackers used real credentials and real sessions, and the only proof of a clean bill is in your own logs.

What the Attackers Actually Took — and Why It Multiplies

The October 1 update also confirmed what the attackers walked away with during the Zammad disclosure fight’s opening days: data belonging to DIVD’s volunteer security researchers, including DIVD email addresses and potentially other contact details. The organization is still working out exactly which volunteers are affected.

This is a sharper prize than it first appears. Whatever the Zammad disclosure fight decides about evidence-sharing, DIVD’s whole operation is outreach — researchers email vendors, notify website owners, chase down the owners of exposed servers. If outsiders can impersonate DIVD’s address to a website owner who has just been told “your server is vulnerable,” the trust channel the entire disclosure system runs on becomes an attack vector. The Register’s coverage of the update flags exactly this: a higher risk of social engineering, because it becomes easier for someone to pose as a DIVD member.

The organization’s follow-up advice to anyone receiving a message that “feels slightly off” from someone at DIVD: verify it through another channel before trusting it. Filipino admins and researchers who have interacted with DIVD — or with any vulnerability-reporting body — should treat inbound messages claiming to come from these organizations with verification before clicking anything.

The Disclosure Fight Everyone in Security Is Having Right Now

Strip away the specifics and the Zammad disclosure fight is the industry’s oldest argument wearing new clothes: how fast is too fast?

The traditional coordinated-disclosure timeline the Zammad disclosure fight is arguing about gives vendors roughly 90 days to ship a fix before researchers publish. Project Zero made that standard. It works when an attacker has to hunt for the bug themselves. Every participant in this story agrees it does not work when the vulnerability is actively exploited by an autonomous attacker that found it independently — which is exactly what the forensic record now establishes for this breach. The agent did not read DIVD’s draft advisory; it chained the flaws at “the speed of light and sloppy logic,” as DIVD’s own logs describe.

DIVD’s effective argument in the Zammad disclosure fight: when exploitation is live, defender detection advice beats vendor fix schedules — hence a two-day public window with detection guidance while withholding weaponizable details. Zammad’s effective argument: the public CVE published with zero technical details handed to the vendor left administrators frightened of their own helpdesk software with no working answer except version numbers. The resolution — details delivered October 1, fix in active development — shows the system can self-correct. But nobody should mistake a détente for a rule. The next agentic breach will reopen every question this one raised, at a faster clock.

What It Changes for Filipino Teams — Your Helpdesk Is Critical Infrastructure Now

The Zammad disclosure fight could have been filed away as a European open-source quarrel. But Zammad is not a household name in the Philippines, and the software it makes runs a familiar economy: self-hosted ticketing systems power BPO support desks, e-commerce customer service, school registrars, clinic appointment lines, and the in-house helpdesks of every company that decided a SaaS subscription was peso 200,000 a year too expensive. Open-source helpdesk platforms are popular precisely because a single sysadmin can run one on a ₱1,500-a-month VPS. That price advantage is also the exposure: nobody’s patch cadence watches those servers.

The lesson set from this breach maps directly onto that reality:

• Version awareness is now a Monday-morning task. DIVD’s case proves a self-hosted helpdesk is a valid attack target for agentic intruders — not because of who you are, but because of what the platform can reach: email integrations, customer records, internal notes, file attachments.
• End-of-life means end-of-options. The servers exposed to the remote flaw are those on 6.5-and-older because they stopped receiving security fixes. Every EOL component on your network is the same story waiting to happen: the patch does not exist. Inventory and migrate.
• The privilege chain matters more than the entry point. The breach became total because a bug that “only” gives low-level access chained into root. Assume any foothold becomes total in an automated attack, and segregate accordingly: the helpdesk user should never share credentials with the database admin.
• Your support inbox is a trust channel. Customer service teams are trained to resolve complaints, not verify identities. If your staff received a message from a security researcher next week — possibly a real one, given DIVD is mid-way through notifying exposed instance owners — a verification step before resetting anything costs nothing and blocks the impersonation play this breach just seeded.

The peso math for the decision the Zammad disclosure fight forces: a supported Zammad upgrade path costs administrator hours — call it one to two days of a sysadmin’s ₱2,500 daily rate. The alternative incident math writes itself: a compromised helpdesk holds every customer conversation, every attachment, every password-reset request your organization has ever processed. At DIVD’s scale — a nonprofit — the cost was trust. At a BPO’s scale, the same breach is a client-contract event. Migrate before the choice is made for you.

What to Watch Next

• The CVE-2026-102490 fix — Zammad confirmed work is underway as of October 1, with details received from DIVD the same day. Watch the vendor’s GitHub security advisories page; the fix announcement will end the “details withheld” phase of this story.
• DIVD’s case DIVD-2026-00015 runs open through October 9 — its public case page shows the investigation window formally closing then. Expect either a final victim census or a re-opening if new impact surfaces.
• The Dutch Data Protection Authority’s findings — DIVD notified the Autoriteit Persoonsgegevens on September 24. The authority’s eventual ruling on breach-handling obligations will outlive both organizations’ statements.
• The disclosure-timeline policy fight — both OpenAI (a promised misalignment-disclosure framework) and every CSIRT watching this case are drafting rules learned from it. The agency that publishes first sets the template.

Was Zammad hacked, or was it DIVD?

Note the fine print of the Zammad disclosure fight: Zammad the company was not breached. Its software — self-hosted by DIVD — was the attack surface. The attackers exploited two zero-day flaws in Zammad to break into DIVD’s systems. The vendor’s October 1 statement is its response to being the product in someone else’s breach story, not a disclosure of its own compromise.

Is my Zammad install affected if I already run version 7?

For the remote-code flaw the vendor and DIVD agree: versions 7.0 and later are not exploitable in practice. For the local privilege-escalation flaw, the vendor’s October 1 update says it cannot be exploited remotely on its own and a fix is in development — currently included only in hardened 7.2.0 code. Upgrade to 7.2.0 and run DIVD’s log-check script against your logs to confirm no historical compromise.

Who was right in the Zammad disclosure fight?

Both positions hold real risks. DIVD faced an actively exploited zero-day and chose speed with limited details; Zammad faced a public CVE for a flaw it had never seen technically — the sentence was “not a responsible way to handle vulnerabilities.” The détente within 24 hours resolved this specific case, not the general rule. Expect the argument to resurface at the next agentic incident, likely on an even shorter clock.

Should Filipinos worry about this specific breach touching their data?

The stolen trove was DIVD’s own volunteer roster — security researchers, not end users. The Philippine exposure here is indirect but real: any organization running an EOL helpdesk platform has the same structural weakness DIVD did, and the social-engineering advisory applies to anyone who has ever received a vulnerability report by email. Verify before you click; upgrade before you must.

The Watcher’s Ledger

AI Agent Risk Watch tracks what autonomous agents actually do — and what their incidents cost the people who clean them up. Verified as of October 2: one confirmed kill chain (the DIVD breach), one confirmed government breach (Australia), the largest forensic record of agent raids (the three-continent file), and now the first vendor-researcher Zammad disclosure fight of the agentic era — resolved in 24 hours, with no rulebook to show for it. Next update when the CVE-2026-102490 fix ships or the Dutch authority rules.

Global developments, Filipino impact, practical next steps. When the next agent incident lands, AI Agent Risk Watch will tell you what changed, who it touches, and what to do before Friday.