Das Dutch Institute for Vulnerability Disclosure (DIVD) verbringt seine Tage damit, das Internet zu scannen, Lücken in der Software anderer Leute zu finden und ihnen freundlich zu sagen, wie sie diese schließen. Am 21. September 2026 drehte ein autonomer KI-Agent den Spieß um und fand die Lücken in deren eigener Software.
Nicht mit einer raffinierten Supply-Chain-Kompromittierung. Nicht mit einem Zero-Day-Arsenal eines Nationalstaats. Mit zwei Schwachstellen, die in einem Open-Source-Helpdesk-System verkettet wurden — und der Maschinengeschwindigkeit eines Agenten, der nicht darauf wartet, dass ein Mensch Enter drückt.
Als die Teams von DIVD dem Angreifer aufholten, hatte dieser Root auf der Maschine, hatte interne Dienste erreicht und Daten gelesen und exfiltriert. Die gesamte Privilegienleiter, vom unauthentifizierten Fremden bis zu Root, dauerte Sekunden.
Wenn die Schwachstellenjäger zur Schwachstelle werden
DIVD ist eine Non-Profit-Organisation aus Freiwilligen, die Systembetreber über Schwachstellen informieren, bevor Kriminelle sie ausnutzen. Angegriffen zu werden ist für sie keine Überraschung — das gehört zum Geschäft. Was diesen Fall anders macht, ist die Art, wie der Angriff ablief.
DIVD entdeckte die Intrusion, während es einen früheren Fall bearbeitete, in dem festgestellt wurde, dass die Organisation durch die Aktivität eines KI-Agenten kompromittiert worden war. Bei der Rekonstruktion, wie die Angreifer wirklich hineinkamen, identifizierten DIVD und sein Research-Partner Merlon Security zwei bis dahin unbekannte Schwachstellen in Zammad, der Open-Source-Ticketing- und Helpdesk-Plattform, die DIVD intern nutzte.
Ihre Ausarbeitung zu dem Vorfall, geführt als DIVD-2026-00015, ist ungeschönt über das, was danach geschah. Wie die Organisation schrieb: "Wenn Hacker gehackt werden, reagieren wir im Hacker-Stil."
Die beiden Zero-Days
Die Kette besteht aus zwei Zammad-Schwachstellen, beide inzwischen mit CVE versehen:
- CVE-2026-102489 — eine Session-Hijacking-Schwachstelle, ausnutzbar in Zammad 6.3.0 bis 6.5.4. Ein Angreifer kann legitime Sessions übernehmen und den Defekt zu Remote Code Execution als Service-User
zammadeskalieren. (Der Defekt existiert auch in 7.0.0 bis 7.1.3, aber Umgebungsbedingungen verhindern dort die Ausnutzung.) - CVE-2026-102490 — eine lokale Privilege-Escalation-Schwachstelle, die seit Version 1.5.0 bis 7.1.0-alpha existiert. Sobald Code auf dem Host als Service-User läuft, führt diese Schwachstelle den Angreifer den Rest des Weges zu Root.
Jede Schwachstelle ist für sich genommen kritisch. Verkettet bilden sie eine gerade Linie: unauthentifizierter Zugriff auf einen öffentlichen Web-Endpunkt, zu RCE, zu voller Root-Kontrolle über den Server.
Root in Sekunden — die agentische Signatur
Das ist der Teil, der für jedes Team mit internetexponierter Software zählt: Die Geschwindigkeit war die Signatur des KI-Agenten.
Die Offenlegung von DIVD sagt es unmissverständlich. Von einem Zammad-User zu Root, in Sekunden — "aufgrund des agentischen Anteils an diesem Hack". Der Agent analysierte die Umgebung, verketete die beiden Schwachstellen, eskalierte Privilegien und bewegte sich zu anderen Diensten, ohne dass ein Mensch jeden Schritt anleitete. Er traf Entscheidungen und führte den nächsten Schritt eigenständig aus — und komprimierte eine Angriffssequenz, die historisch Stunden manueller Arbeit braucht, auf Momente.
Nach dem Root-Zugriff erreichte der Angreifer andere Dienste, las Daten und exfilierte einen Teil davon. Netzwerksegmentierung und die schnelle Reaktion der IT- und Incident-Response-Teams von DIVD stoppten die Intrusion, bevor sie sich weiter ausbreitete — aber nicht, bevor ein Teil des Schadens bereits passiert war.
DIVD erkannte den Angriff auch, weil der Agent laut war: Er hinterließ sichtbare Spuren, die den Ermittlern halfen, alles zu rekonstruieren. Das ist beruhigend, aber auch unbequem. Ein disziplinierterer Angreifer mit denselben agentischen Tools könnte viel leiser bleiben.
Warum ein Helpdesk ein Tier-0-Ziel ist
Die Wahl des Vektors verdient Aufmerksamkeit. Zammad ist beliebte Open-Source-Software — über 2.000 Kunden und 55.000 Nutzer — und Helpdesks gehören zu den am stärksten exponierten Systemen, die eine Organisation betreibt.
Denk daran, was in einem Support-Desk lebt: vollständige Namen, E-Mails, Telefonnummern, Korrespondenz mit externen Partnern, Zugangsdaten in Ticket-Threads, Links zu internen Systemen und die Angewohnheit, Screenshots anzuhängen, die nie für fremde Augen bestimmt waren. Ein Helpdesk ist eine vorindexierte Karte deiner Organisation, zugänglich für jeden, der die Login-Seite erreicht.
Deshalb ist eine RCE-Kette in ein Ticketing-System nie nur ein Ticketing-Problem. Es ist ein Identitätsproblem, ein Zugriffsproblem und ein Lateral-Movement-Problem — alles gleichzeitig.
Was diese Woche zu tun ist
Wenn deine Organisation Zammad in irgendeiner Version betreibt, ist die Empfehlung von DIVD und Zammad eindeutig:
- Auf Zammad Version 7 aktualisieren oder das System vom Netz nehmen. Version 7 gilt als sicher; jede ältere Version gilt als ausnutzbar. Warte nicht auf ein Patch-Fenster — die Kette steht im Known Exploited Vulnerabilities-Katalog (KEV) der CISA.
- Von einer bereits erfolgten Kompromittierung ausgehen. Die DIVD-Kette ist still, bis ein Angreifer etwas laut macht. Suche die bereitgestellten Indikatoren in deinen Logs und prüfe auf unerwartete Sessions, ungewöhnliche Aktivität im Helpdesk und nicht erkannte lokale Accounts.
- Alles rotieren, was der Helpdesk erreichen kann. Tickets enthalten routinemäßig Zugangsdaten, Tokens und API-Schlüssel. Behandle alles, was im System gespeichert oder darüber gesendet wurde, als potenziell offengelegt.
- Den Helpdesk aus der Trust-Zone nehmen. Der einzige Grund, warum dieser Vorfall eingedämmt wurde, war Segmentierung. Dein Ticketing-System sollte nie ein Sprungbrett von einem Web-Formular zur internen Infrastruktur sein.
- Die Bedrohung mit Maschinengeschwindigkeit modellieren. Spiele die Szenarien durch, die dein Response-Plan überstehen muss, wenn der Angreifer in Sekunden statt Stunden agiert: Eindämmungsentscheidungen, Credential-Rotation und Management-Kommunikation, alle in diesem Tempo geübt.
Das größere Bild: Agentische Angriffe sind da
Jahrelang lebte KI in Sicherheitsdiskussionen in zwei Schachteln: KI, die Verteidigern hilft, schneller zu finden und zu patchen, und KI-generiertes Phishing, das überzeugender wird. Der DIVD-Vorfall bricht beide Schachteln auf. Ein KI-Agent führte die gesamte Intrusions-Kette aus — Reconnaissance, Exploitation, Privilege Escalation, Lateral Movement — gegen eine echte Organisation, mit echten Konsequenzen.
Und das Ziel war bitterironisch. Das Institut, dessen zentrale Mission es ist, Schwachstellen zu finden, bevor sie ausgenutzt werden, wurde durch Schwachstellen kompromittiert, die niemand kannte. Niemand bei DIVD war fahrlässig; die Schwachstellen existierten in Code, den Tausende von Organisationen betreiben.
Das ist die strategische Erkenntnis für unsere Kunden in den GCC und darüber hinaus: Deine Sicherheitslage ist nur so stark wie das am wenigsten beobachtete Open-Source-System, das du dem Internet ausgesetzt hast — und deine Gegner operieren nun mit Maschinengeschwindigkeit. Die Verteidigung gewinnt noch — Segmentierung, schnelle Reaktion und aggressives Patchen haben dies in Stunden eingedämmt — aber das Zeitfenster für manuelle, ticketgetriebene Remediation schrumpft jeden Monat.
Ein KI-Agent hat in Sekunden die Infrastruktur einer Security-Non-Profit übernommen. Der nächste ist vielleicht leiser. Stelle sicher, dass dein Stack vorher bereit ist, nicht danach.
Bei aratech helfen Organisationen, genau die Systeme zu härten, die Angreifer ins Visier nehmen — Helpdesks, Identitätsebenen und die KI-Infrastruktur, die nun auf beiden Seiten in die Kill Chain eintritt. Wenn dein internetexponierter Stack nicht gegen agentische Angriffe modelliert wurde, ist das das erste Gespräch, das du führen solltest.