DIVD — nizozemský nezisk, který se sedm let staral o to, aby firmy po celém světě včas zalátaly díry ve svých systémech — oznámil, že se sám stal obětí útoku. Dvě nové chyby v open-source helpdesku Zammad, který DIVD používal pro vlastní podporu, útočníkům otevřely dveře. Co se dělo za nimi, už nebyl člověk u klávesnice: samostatně jednající AI agent během pár vteřin eskaloval oprávnění až na root a začal odnášet data. Instituce, která hlídá zranitelnosti u jiných, nestihla zareagovat na vlastní.
Co se stalo
- Kdo je DIVD. Dutch Institute for Vulnerability Disclosure je nizozemská nezisková organizace dobrovolných bezpečnostních výzkumníků — skenuje internet, hledá zranitelné systémy a upozorňuje jejich provozovatele. Podle vlastních čísel má 189 členů a za dobu existence řešila přes 1,4 milionu notifikovaných zranitelných IP adres.
- První oznámení. DIVD ve vlastním prohlášení napsalo, že si po téměř sedmi letech bez incidentu všimlo podezřelé aktivity a potvrdilo průnik. Klíčová věta: „modus operandi nasvědčuje tomu, že jde o agenticky řízený útok s využitím AI." Organizace zablokovala přístup do vlastní infrastruktury, nahlásila incident nizozemskému Úřadu pro ochranu osobních údajů (Autoriteit Persoonsgegevens), Národnímu centru kybernetické bezpečnosti (NCSC) a probrala postup s policií.
- Co přesně útočníci našli. V navazujícím oficiálním příspěvku DIVD organizace popsala, že při zpětné analýze vlastního průniku objevila s partnerskou firmou Merlon Security dvě dosud neznámé chyby (zero-days) v ticketovacím systému Zammad — přidělena jim byla označení CVE-2026-102489 a CVE-2026-102490.
- Jak rychle to šlo. Podle DIVD obě chyby v kombinaci umožnily „unést relaci, vzdáleně spustit kód a povýšit oprávnění z uživatele Zammadu až na root — ve vteřinách, díky agentické části tohoto útoku." Odtud se útočníci dostali k dalším službám a začali číst a odnášet data. Dřívější pozorování DIVD popisovalo samotnou techniku útoku jako „hlučnou a velmi, velmi neuspořádanou" — agent po každém kroku sám rozhodoval, co udělá dál, a své úvahy si nechával zaznamenané, což paradoxně pomohlo DIVD útok později zrekonstruovat.
- Proč to nešlo dál. DIVD uvedlo, že díky správné segmentaci sítě a zásahu vlastního IT a Incident Response týmu se útočníkům nepodařilo proniknout hlouběji. Zároveň ale organizace připustila, že nějaké škody už vznikly, a dokud se neprokáže opak, postupuje v režimu „předpokládáme průnik".
- Doporučení pro uživatele Zammadu. DIVD vyzvalo všechny, kdo Zammad provozují, aby okamžitě aktualizovali na verzi 7 nebo instanci dočasně vypnuli, a začalo rozesílat upozornění provozovatelům zranitelných instalací. Podle údajů, které BleepingComputer přebírá z webu Zammadu, má nástroj přes 2 000 zákazníků a 55 000 uživatelů, mezi nimi De'Longhi, Amnesty International nebo Nextcloud.
- Co ještě nevíme. DIVD slíbilo další veřejnou aktualizaci na 1. října — v době psaní tohoto článku ještě nebyla zveřejněna. Kdo útok provedl, s jakým cílem a jak přesně AI agent fungoval, organizace zatím nezveřejnila — vyšetřování podle jejích slov pokračuje.
Proč se to týká i vás
Zammad je obyčejný helpdesk — nástroj na zákaznickou podporu a interní tiketing, typ softwaru, který má nasazený kdejaká střední firma, nejen bezpečnostní nezisky. Na téhle historii jsou tři věci, které stojí za zapamatování i mimo svět vulnerability disclosure.
- Obětí byl ten, kdo se bezpečností živí. DIVD není nezkušený provozovatel — je to organizace složená z profesionálních bezpečnostních výzkumníků, která sama po léta upozorňovala jiné na jejich chyby. Přesto ji dostal běžný provozní nástroj, na kterém většina firem netuší, že by měl být prioritou k záplatování.
- Rychlost útoku změnila to, co „stihnete" zachytit. Eskalace z běžného uživatele na root prý trvala vteřiny. Lidský tým incident response v takovém čase nezasáhne — jediné, co útok omezilo, byla už dříve hotová segmentace sítě. To znamená: opatření, která máte nastavená předem, teď váží víc než schopnost rychle reagovat, až se něco stane.
- AI agent nebyl cíl útoku, byl jeho nástroj. Nejde o to, že by někdo napadl model nebo ho obelstil promptem — AI tu posloužila útočníkovi k automatizaci kroků po průniku, které by jinak dělal člověk, jen mnohem pomaleji. To je jiná kategorie rizika než „zaměstnanec si pustil citlivá data do chatbota", a firmy na ni podle všeho nejsou připravené o nic víc než DIVD.
Co s tím
- 1. Zjistěte, jestli u vás běží Zammad, a pokud ano, v jaké verzi. DIVD doporučuje verzi 7 nebo instanci vypnout. Tohle je nejkonkrétnější a nejlevnější krok z celého článku — stačí ho dnes zkontrolovat u kolegy, který má support nástroje na starosti.
- 2. Zeptejte se dodavatelů ticketovacích a helpdeskových nástrojů, jak rychle u nich záplatují kritické chyby. Nejde jen o Zammad — jde o kategorii nástrojů, které obvykle nejsou na seznamu „kritická infrastruktura", a přitom mají přístup k citlivým datům a interním systémům.
- 3. Ověřte si segmentaci sítě tam, kde ji máte, a tam, kde ji nemáte, ji doplňte. V tomhle případě byla jediná věc, která útočníka zastavila dřív, než se dostal hlouběji. Je to opatření, které funguje i proti útoku, o kterém dnes ještě nevíte.
- 4. Počítejte s tím, že incident response musí fungovat bez prodlevy na schvalování. Když eskalace trvá vteřiny, postup „nahlásit, počkat na pokyny, pak izolovat" už nestíhá. Předem dané pravomoci k okamžité izolaci systému jsou teď praktičtější než hezky sepsaný plán.
A teď proti vlastnímu byznysu: jestli u vás firma žádný helpdesk ani podobný nástroj s vnějším přístupem neprovozuje a hlavní riziko vidíte v tom, že lidé používají ChatGPT v prohlížeči, tahle konkrétní zranitelnost se vás netýká. Nejde o chybu v AI modelu, ale v konkrétním ticketovacím softwaru — kontrola verze zabere pět minut a audit kvůli tomu neobjednávejte.
Kde to řeším s klienty
Případ DIVD ukazuje přesně to, co bývá slabinou i u firem, se kterými pracuji: bezpečnostní priority se nastavují podle toho, co je vidět — tedy modely a chatboty — a provozní nástroje jako helpdesk nebo tiketing zůstávají mimo pozornost, dokud nejsou sami terčem. Mapování toho, které vaše nástroje mají přístup k citlivým datům a jak rychle u nich reagujete na kritické záplaty, je součástí AI Act Readiness Auditu; pokud chcete jen rychlou orientaci, začněte AI Risk Scanem zdarma. Navazuje to na dřívější text o tom, jak slabě ověřený sandbox pustil agenta k navýšení oprávnění — tam šlo o kódovacího agenta na vývojářské stanici, tady o stejný princip rychlosti v provozním nástroji.