Zammad în KEV: sesiune deturnată, root fără patch
Pe 2 octombrie 2026, CISA a adăugat în KEV două vulnerabilități din Zammad, platforma open-source de helpdesk: CVE-2026-102489, o deturnare de sesiune care duce la executare de cod ca utilizator zammad, și CVE-2026-102490, o escaladare locală de privilegii la root. Termenul pentru agențiile federale americane este 5 octombrie. Descoperirea aparține institutului olandez DIVD, care a fost el însuși victima lanțului pe 21 septembrie.
Situația are o particularitate: producătorul și cercetătorii nu sunt de acord asupra întinderii celui de-al doilea defect, iar la momentul verificării noastre nu exista un patch pentru el. Un sistem de helpdesk conține conversații cu clienți, adrese de e-mail, atașamente și adesea credențiale, deci riscul se judecă după ce poate citi serverul, nu după scorul CVSS.
Ce este confirmat
Potrivit cazului DIVD-2026-00015, DIVD a fost atacat pe 21 septembrie, a analizat incidentul în zilele următoare, a notificat Zammad pe 24 septembrie și a început scanarea instanțelor expuse pe 26 septembrie. Înregistrările CVE au fost publicate la sfârșitul lui septembrie. DIVD afirmă că lanțul a permis deturnarea sesiunilor, executare de cod și escaladare până la root „în câteva secunde”, apoi accesul la alte servicii și citirea datelor.
CVE-2026-102489 este exploatabil în Zammad 6.3.0–6.5.4. Pentru 7.0.0–7.1.3, NVD și DIVD spun că defectul este prezent, dar neexploatabil din cauza condițiilor de mediu; Zammad scrie că versiunile 7.0 și mai noi nu sunt vulnerabile. Producătorul spune că defectul este corectat în 7.2.0, lansată pe 23 septembrie, și că afectează doar versiuni 6.5 și mai vechi, care nu mai primesc corecții de securitate.
CISA le-a inclus pe amândouă în KEV pe 2 octombrie, cu termen 5 octombrie și cerință de triaj forensic. Utilizarea în campanii ransomware este marcată ca necunoscută.
Escaladarea la root: disputată și fără patch
CVE-2026-102490 permite utilizatorului local zammad să obțină privilegii root. NVD descrie defectul ca prezent în toate versiunile, inclusiv în cea mai recentă versiune alpha, iar DIVD indică intervalul 1.5.0–7.1.0-alpha și spune că nu este corectat. Zammad răspunde că defectul este neconfirmat, că nu a primit detalii tehnice, că nu are patch și nu a indicat un termen, și a cerut informații de la DIVD.
Nu avem un document tehnic al producătorului care să infirme sau să confirme scopul real al defectului. Încadrarea corectă: există o escaladare la root raportată și folosită într-un atac, fără corecție disponibilă. Actualizarea la 7.2.0 închide intrarea prin sesiune, dar nu oferă, în aceste surse, o garanție împotriva escaladării dacă un atacator ajunge pe server prin altă cale.
Scorurile CVSS diferă între surse (de la 8,5 la 9,4), așa că nu vă bazați pe un scor pentru prioritizare: ambele sunt în KEV.
Ce spune DIVD despre „atacul agentic”
DIVD descrie atacul ca fiind condus de un agent AI care a acționat autonom, „zgomotos și dezordonat”, iar BleepingComputer și Sysdig preiau evaluarea. Este o evaluare a victimei, bazată pe viteza și pe forma acțiunilor, nu un fapt verificabil din exterior. Sysdig notează și o estimare, nu o dovadă, a peste 2.000 de clienți Zammad potențial expuși.
Pentru apărare, diferența contează puțin: lanțul este documentat și public, iar rapiditatea lui scurtează timpul în care o alertă mai poate fi urmărită. Segmentarea rețelei și acțiunile de răspuns la incident au limitat, potrivit DIVD, extinderea atacului.
Inventariază și decide instanță cu instanță
- ▸Găsește toate instanțele Zammad: producție, test, ale departamentelor, ale filialelor și cele găzduite de un furnizor. Notează versiunea exactă și cine le administrează.
- ▸Zammad 6.5 sau mai vechi: nu mai primește corecții de securitate. Trebuie migrat la 7.2.0 sau, până atunci, scos din Internet. DIVD recomandă actualizarea la versiunea 7 sau deconectarea instanței.
- ▸Zammad 7.x: actualizează la 7.2.0, versiunea stabilă curentă, conform producătorului.
- ▸Pentru fiecare instanță expusă, decide dacă are nevoie de acces public. Poți pune portalul clienților în față și panoul de administrare doar în spatele VPN-ului sau al unei liste de adrese permise.
- ▸Dacă folosești Zammad găzduit de furnizor, cere în scris starea CVE-2026-102489 și CVE-2026-102490; declarația producătorului nu spune nimic despre clienții găzduiți.
Limitează ce poate face un atacator ajuns pe server
Deoarece escaladarea la root nu are patch, restul măsurilor sunt cele care contează. Sysdig sugerează izolarea helpdesk-ului într-un segment dedicat, cu egress interzis implicit, păstrarea dovezilor din directoarele de loguri Zammad și nginx și rotirea credențialelor accesibile de pe un server compromis.
- ▸Pune helpdesk-ul într-un segment separat, cu trafic de ieșire permis doar către destinațiile necesare (e-mail, directorul de utilizatori, stocare).
- ▸Revizuiește ce secrete se află pe server: conectori de e-mail, LDAP, chei API, tokenuri de integrare. Fiecare este ceva ce un atacator cu acces root ar citi.
- ▸Verifică dacă serviciul rulează cu drepturi minime și dacă există mecanisme de limitare a escaladării în sistemul de operare; documentează ce există, fără să afirmi că acestea blochează un defect pe care producătorul nu l-a confirmat.
Caută urme de compromitere
DIVD oferă un script de verificare a indicatorilor, în pagina cazului. Sysdig listează semnale comportamentale, nu indicatori statici: servicii care pornesc shell-uri interactive, apeluri de sistem din familia setuid venite de la conturi de aplicație, citiri în masă ale fișierelor de credențiale, serii de autentificări eșuate pe mai multe conturi și conexiuni de ieșire neobișnuite din segmentul helpdesk.
- ▸Rulează scriptul DIVD sau echivalentul lui pe fiecare instanță expusă, de preferință pe o copie, după ce ai păstrat dovezile.
- ▸Analizează logurile Zammad și nginx cel puțin de la 21 septembrie, data intruziunii DIVD, și mai devreme dacă logurile permit: nu se cunoaște când a început exploatarea în afara cazului DIVD.
- ▸Dacă găsești indicii, tratează toate credențialele și cheile de pe server ca expuse, rotește-le după izolare și revizuiește accesul la serviciile conectate.
Închide alerta cu dovezi
Awarely Monitor urmărește CVE-urile din KEV, prioritatea și dovezile remedierii pentru fiecare activ, inclusiv riscul rămas atunci când nu există patch. Actualizarea, izolarea și analiza logurilor se fac în mediul Zammad și în sistemele voastre de loguri.
- ▸Lista instanțelor Zammad, cu versiunea înainte și după și starea de expunere.
- ▸Decizia pentru fiecare instanță: actualizată, migrată, izolată sau scoasă din Internet, cu responsabil.
- ▸Rezultatul verificării de indicatori și perioada de loguri analizată.
- ▸Secretele rotite și excepțiile temporare, cu termen, pentru escaladarea fără patch.
Documentează riscul rămas, nu doar actualizarea
Urmărește în Awarely Monitor instanțele Zammad, decizia pentru fiecare și riscul rămas fără patch, cu responsabil și termen. Actualizarea, izolarea și logurile rămân în mediul vostru.