Przypadek Zammad to wyjątkowo dobry materiał dla Vulnerability Engineera. CVE-2026-102489 opisuje ścieżkę prowadzącą do wykonania kodu jako użytkownik zammad, a CVE-2026-102490 lokalną eskalację do roota. Obie trafiły do KEV i mogą tworzyć łańcuch ataku. A potem producent doprecyzował, których wersji to naprawdę dotyczy.
zammad / przejęcie sesji. Wg Zammad (5.10): praktycznie exploitable na 6.5 i starszych; w 7.0+ kod obecny, ale warunki środowiskowe uniemożliwiają wykorzystanie.Łańcuch ataku
Co zmieniło stanowisko producenta
Zammad 5 października doprecyzował zakres. Dla 7.0+ podatny fragment kodu mógł występować, ale warunki środowiskowe uniemożliwiają praktyczne wykorzystanie. CVE-2026-102490 producent traktuje jako osobny problem lokalnej eskalacji. Powstaje więc typowy dla VE rozjazd: KEV i opis CVE sugerują pilność dla wszystkich, a vendor zawęża realną populację. Podobny spór o ocenę opisywałem przy Spring SpEL i Redis.
Jak powinien zachować się VE
Nie wystarczy wpisać „CVE present” ani „vendor says not affected”. W findingu trzeba udokumentować: wersję, runtime, warunki exploitable, status EOL, ekspozycję oraz podstawę decyzji (link do stanowiska producenta z datą). Dla starszych instalacji — zwłaszcza 6.5 i niższych wystawionych do Internetu — potrzebna jest analiza możliwej kompromitacji, bo to dokładnie populacja, na którą wskazuje KEV.
Powiązane na blogu
- Spring SpEL: Medium vs Critical — vendor i baza danych podatności oceniają inaczej
- Redis: provenance CVSS — skąd pochodzi ocena
Źródła
- Zammad Security Advisory — CVE-2026-102489 / CVE-2026-102490 (5.10.2026) — zammad.com
- CISA Known Exploited Vulnerabilities Catalog — cisa.gov
Nota redakcyjna: stan informacji 6 października 2026, na podstawie draftu VMRT, advisory Zammad (5.10.2026), DIVD-2026-00015 i CISA KEV. Artykuł przedstawia zarówno wpis KEV, jak i zawężenie zakresu przez producenta.