RCE w Agencie AI Zammad: zagnieżdżony tag szablonu, jednoliterowa poprawka

Zammad, helpdesk open source, wydał 4 sierpnia 2026 r. wersję 7.1.2 zawierającą osiemnaście poprawek bezpieczeństwa; pierwsza wymieniona zamyka lukę umożliwiającą zdalne wykonanie kodu w polach konfiguracyjnych funkcji AI Agent. Luka ma identyfikator CVE-2026-84462, ujawniono ją w poradniku GitHub GHSA-gp3x-9xm8-rcj6 tego samego dnia, a jej zakres obejmuje każdą samodzielnie hostowaną instalację w wersji do 7.1.1 włącznie. Administrator, który może utworzyć lub edytować AI Agent, mógł wprowadzić specjalnie spreparowany tekst do jednego z pól agenta, obejść filtr mający go zneutralizować i uruchomić dowolne polecenia na serwerze hostującym Zammad — co, według poradnika, stwarza możliwość „odczytania, zmodyfikowania lub zniszczenia wszystkich danych przechowywanych na tym serwerze”. Żaden inny użytkownik nie musi podejmować działań: poradnik stwierdza, że „złośliwy kod uruchomi się automatycznie przy następnym przetwarzaniu zgłoszenia przez zagrożoną funkcję AI Agent”. GitHub ocenia ją jako High — wysoki — na poziomie 8,6 w CVSS 4.0. Rekord, jego znaczniki ważności i szkodliwości oraz powiązane wpisy są przechowywane w Orca AI Incident Archive, które wymienia ten incydent obok pozostałych z serii.

Co ustanawia opinia doradcza

Opublikowany 4 sierpnia 2026 r. advisory GitHub jest krótki i wyjątkowo konkretny co do mechanizmu oraz warunków wstępnych. Opisuje „filtr bezpieczeństwa chroniący konfigurację AI Agent w Zammad”, który „można obejść, wprowadzając specjalnie spreparowany tekst do jednego z pól AI Agent”, oraz dokładnie wskazuje podmiot: „Administrator z uprawnieniami do tworzenia lub edycji AI Agents mógłby to wykorzystać do uruchomienia dowolnych poleceń na serwerze hostującym Zammad”. Zakres podatności zapisano jako obejmujący wersje do 7.1.1 włącznie, a wersję poprawioną jako 7.1.2. Zgłaszającym, którego wskazano, jest colinthebomb1; konto publikujące to fliebe92. Advisory nie publikuje żadnego proof of concept ani szczegółów exploita.

GitHub ocenia tę lukę jako High, 8,6 w CVSS 4.0, z wektorem AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H i bez zmiany zakresu. Innymi słowy oznacza to, że luka jest osiągalna przez sieć przy niskiej złożoności, bez wymagań dotyczących ataku i bez interakcji użytkownika, przez atakującego, który ma już wysokie uprawnienia wewnątrz aplikacji, przy dużym wpływie na poufność, integralność i dostępność samej instancji Zammad. Dokument doradczy wymienia trzy słabości: CWE-20, nieprawidłowa walidacja danych wejściowych; CWE-94, wstrzyknięcie kodu; oraz CWE-1336, klasa podatności silnika szablonów, którą MITRE definiuje jako niezneutralizowanie specjalnej składni „która może być interpretowana jako wyrażenia szablonowe lub inne dyrektywy kodu, gdy jest przetwarzana przez silnik”.

Poprawka zmieniła jedną literę.

Publiczna poprawka to commit e3b0c8df91ad2108c8305be23e8fe6f73fb9718d, przesłany z komunikatem „Konserwacja: ulepszenie sanitizera ERB”. GitHub odnotowuje datę autora 7 lipca 2026 r. i datę commita 3 sierpnia 2026 r., dzień przed biuletynem bezpieczeństwa i wydaniem. Dotyczy dwóch plików: jednej linii lib/erb_sanitizer.rb oraz czternastu dodanych linii specyfikacji.

Ta jedna linia to cała poprawka. Metoda escape_tag używała Ruby'owego sub, który zastępuje pierwsze dopasowanie wzorca w ciągu; teraz używa gsub, który zastępuje każde dopasowanie. W obu wersjach zamiana wygląda tak samo: znacznik otwierający zapisany jako <% staje się <%%, czyli podwojona forma, którą ERB, silnik szablonów Ruby'ego, renderuje jako zwykły tekst zamiast ją ewaluować. Doradztwo nie wskazuje, które pole AI Agenta zawiera szablon; commit wskazuje filtr, który miał uczynić ten szablon nieaktywnym.

W przypadku sub tylko pierwszy opener w ciągu został rozbrojony. Payload, który umieszcza drugi opener bezpośrednio po pierwszym, przechodzi przez filtr: <%<%= 1 + 1 %> staje się <%%<%= 1 + 1 %>, gdzie ERB emituje wiodący opener jako tekst, a następnie ewaluuje wewnętrzny tag. Specyfikacja regresji dodana w tym samym commicie nazywa tę sztuczkę wprost — „z zagnieżdżonym openerem przemyconym do wnętrza pojedynczego tagu (obejście escape-all-openers)” — i stwierdza, że zarówno <%<%= 1 + 1 %>, jak i podwójnie zagnieżdżony <%<%<%= 1 + 1 %> muszą zostać wyrenderowane jako dosłowny tekst. Ta specyfikacja jest najklarowniejszym publicznym opisem sposobu obejścia filtra, ponieważ sam advisory nie dostarcza żadnego.

Charakter tego błędu jest ogólny, a nie stanowi osobliwości Zammada: mechanizm escapujący, który zatrzymuje się po pierwszym dopasowaniu, jest obchodzony przez dowolne dane wejściowe zawierające drugą, zagnieżdżoną kopię sekwencji, którą usuwa. Wiadomość commita nazywa tę zmianę konserwacją, co jest typowym sposobem, w jaki jednoznakowa łatka wzmacniająca bezpieczeństwo jest przedstawiana — i dlatego to biuletyn bezpieczeństwa, a nie diff, musiał zawierać ostrzeżenie.

Siedem tygodni od komunikatu do NVD

NVD opublikowało swój wpis dla CVE-2026-84462 25 września 2026 r., siedem tygodni po publikacji advisory, i po raz ostatni zmodyfikowało go 28 września. Wpis oznaczono jako „Deferred”, co oznacza, że agencja nie opublikowała własnej analizy, a w jego bloku metryk ocenę 8,6 przypisano security-advisories@github.com jako metrykę dodatkową — ocenę GitHub jako organu numerującego CVE, a nie niezależną ocenę NVD. Ten sam wpis nie zawiera w ogóle konfiguracji CPE, więc nie przyporządkowuje luki do identyfikatora wersjonowanego produktu.

Oba te szczegóły mają znaczenie dla każdego, kto śledzi oprogramowanie self-hosted za pomocą feedów, a nie notatek wydania. Poprawka była publicznie dostępna i możliwa do wdrożenia 4 sierpnia; czytelny maszynowo rekord pojawił się 25 września; i nawet wtedy pojawił się bez identyfikatora produktu, po którym dopasowują skanery oparte na CPE. Przez siedem tygodni miarodajnym opisem podatności był komunikat doradczy producenta i nota wydania producenta.

Co jest ustalone, a co nie

Ustalono: porada, poprawiona wersja, wynik CVSS i zmiana w kodzie pochodzą z Zammad oraz z bazy porad GitHub i są ze sobą zgodne. Rekord NVD odtwarza opis organu numerującego bez dodawania własnej analizy. Archiwum ocenia wpis na poziomie pewności A na tej podstawie, przy czym incydent jest niekwestionowany.

Nie ustalono albo nie odnotowano: w komunikacie nie ma proof of concept ani doniesień o eksploatacji w środowisku rzeczywistym. EPSS FIRST przyznaje CVE-2026-84462 0,28 proc. prawdopodobieństwa eksploatacji w ciągu najbliższych trzydziestu dni, co odpowiada 20. percentylowi, w wyniku opublikowanym 29 października 2026 r. Archiwum nie odnotowuje rzeczywistych szkód i klasyfikuje wpis jako średniego stopnia ważności — poniżej własnej kategorii High w komunikacie. To odrębne instrumenty odpowiadające na różne pytania: co błąd mógłby umożliwić w zestawieniu z tym, co wiadomo, że się wydarzyło; ten tekst przedstawia oba, zamiast je uzgadniać.

Niezależne potwierdzenie jest słabe. Wyszukiwanie informacji o tym CVE zwraca bazy podatności, które przedrukowują tekst organu numerującego, oraz własną notatkę o wydaniu Zammada; wygląda na to, że żaden serwis informacyjny nie poinformował o tej luce niezależnie. To ustalenie dotyczące rejestru, a nie jego krytyka: zdalne wykonanie kodu w helpdesku wymagające konta administratora nie jest rodzajem zdarzenia, które generuje prasę, a brak niezależnej relacji sam w sobie jest częścią tego, co dokumentuje rejestr.

Kto mógłby to wywołać i co się zmieniło

Nota wydania Zammada dla wersji 7.1.2 z 4 sierpnia 2026 r. wymienia osiemnaście podatności załatanych w tej wersji, a na pierwszym miejscu stawia obejście szablonu AI Agent. W przypadku klientów korzystających z wersji hostowanej czytamy: „Nie są wymagane żadne działania. Nasz zespół już załatał i zabezpieczył Twoje instancje”. W przypadku instalacji self-hosted brzmi to bardziej stanowczo: „Zdecydowanie zalecamy natychmiastową aktualizację do najnowszej wersji Zammad, aby zapewnić ochronę systemu”. Zalecenie nie podaje żadnego obejścia, a wpis nie zawiera żadnych środków łagodzących poza aktualizacją.

Wymóg dotyczący uprawnień zasługuje na bliższe przyjrzenie się, niż zapewnia to wektor. PR:H oznacza, że atakujący potrzebuje znaczącego dostępu, zanim luka będzie użyteczna, a w tym przypadku tym dostępem jest uprawnienie admin.ai_agent, które zgodnie z dokumentacją Zammad jest w ogóle wymagane do pracy z AI Agents. W helpdesku jest to często kierownik zespołu obsługi, który dostraja kategoryzatory, tagery i ekstraktory tekstu — niekoniecznie osoba administrująca serwerem. Samo sformułowanie w komunikacie doradczym — „administrator z uprawnieniem do tworzenia lub edytowania AI Agents” — jest węższe niż „ktokolwiek” i szersze niż „root”. Jeśli aktualizacji nie można wykonać natychmiast, zawężenie grona osób mających to uprawnienie zmniejsza liczbę osób, które mogą dotrzeć do tej ścieżki kodu; jest to wniosek wynikający z wektora i dokumentacji, a nie środek zaradczy opublikowany przez dostawcę.

Żaden z dokumentów źródłowych nie umieszcza modelu językowego na ścieżce wykorzystania podatności. Polecenie jest wykonywane w procesie Ruby Zammada, gdy konfiguracja agenta jest renderowana; nic w dokumencie doradczym, commicie ani w informacji o wydaniu nie opisuje, by model wytwarzał ładunek. Funkcja AI Agent dostarcza pole edytowalne przez administratora i przetwarzane przez szablon, a AI jest powierzchnią, a nie mechanizmem. To wzorzec, na który wskazuje zapis: definicja agenta — jej instrukcje, szablony i filtry — to konfiguracja wykonywalna, edytowana przez osoby, których pracą jest wsparcie, a nie przegląd bezpieczeństwa.

Środek zaradczy w Zammadzie jest proporcjonalny i mało efektowny: zmiana jednej metody, dwa testy regresyjne oraz podniesienie numeru wersji, które zamyka siedemnaście innych luk obok tej. Częścią wartą przeniesienia dalej jest model ekspozycji. Helpdesk, który pozwala liderowi zespołu wsparcia definiować agenta, pozwala też temu samemu liderowi napisać coś, co wykona serwer, a jedyne, co stoi między tymi dwiema rzeczami, to filtr, który musi być niezawodny w odniesieniu do każdej zagnieżdżonej kopii składni, którą usuwa.