Zammad's AI Agent RCE: un tag template annidato, una correzione di una lettera

Zammad, l'helpdesk open source, ha pubblicato la versione 7.1.2 il 4 agosto 2026 con diciotto correzioni di sicurezza; la prima elencata chiude una vulnerabilità di esecuzione di codice da remoto nei campi di configurazione della funzione AI Agent. La vulnerabilità è CVE-2026-84462, divulgata nell'avviso GitHub GHSA-gp3x-9xm8-rcj6 lo stesso giorno, e l'intervallo interessato comprende tutte le installazioni self-hosted con versione fino alla 7.1.1 inclusa. Un amministratore che può creare o modificare un AI Agent potrebbe inserire testo appositamente costruito in uno dei campi dell'agente, aggirare il filtro pensato per neutralizzarlo ed eseguire comandi arbitrari sul server che ospita Zammad — con il potenziale, secondo le parole dell'avviso, di "leggere, modificare o distruggere tutti i dati memorizzati su quel server". Nessun altro utente deve intervenire: l'avviso afferma che "il codice malevolo viene eseguito automaticamente la prossima volta che l'AI Agent interessato elabora un ticket". GitHub la classifica come High, con 8,6 su CVSS 4.0. Il record, i suoi tag di gravità e danno e le voci registrate attorno ad esso sono conservati nell'Orca AI Incident Archive, che elenca questo incidente insieme al resto della serie.

Cosa stabilisce l'avviso

L'avviso di GitHub, pubblicato il 4 agosto 2026, è breve e insolitamente specifico riguardo al meccanismo e ai prerequisiti. Descrive un "filtro di sicurezza che protegge la configurazione dell'AI Agent di Zammad" che "può essere aggirato inserendo testo appositamente costruito in uno dei campi di un AI Agent", e identifica precisamente l'attore: "Un amministratore con l'autorizzazione a creare o modificare AI Agent potrebbe sfruttarlo per eseguire comandi arbitrari sul server che ospita Zammad." L'intervallo interessato è indicato come fino a 7.1.1 incluso, la versione corretta come 7.1.2. Il segnalatore accreditato è colinthebomb1; l'account che ha pubblicato è fliebe92. L'avviso non pubblica alcun proof of concept né dettagli sull'exploit.

GitHub classifica la vulnerabilità come Alta, 8,6 su CVSS 4.0, con il vettore AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H e nessuna variazione di scope. Letto così, ciò significa che la vulnerabilità è raggiungibile tramite rete a bassa complessità, senza requisiti di attacco e senza interazione dell'utente, da parte di un attaccante che detiene già privilegi elevati all'interno dell'applicazione, con un impatto elevato su riservatezza, integrità e disponibilità dell'istanza Zammad stessa. L'avviso elenca tre debolezze: CWE-20, validazione dell'input impropria; CWE-94, iniezione di codice; e CWE-1336, la classe dei motori di template che MITRE definisce come l'incapacità di neutralizzare una sintassi speciale «che può essere interpretata come espressioni di template o altre direttive di codice quando viene elaborata dal motore».

La correzione ha cambiato una lettera.

La correzione pubblica è il commit e3b0c8df91ad2108c8305be23e8fe6f73fb9718d, inviato con il messaggio "Maintenance: Improve ERB sanitizer." GitHub registra una data dell'autore del 7 luglio 2026 e una data del commit del 3 agosto 2026, un giorno prima dell'avviso e del rilascio. Tocca due file: una riga di lib/erb_sanitizer.rb e quattordici righe aggiunte della specifica.

L'unica riga è l'intera correzione. Il metodo escape_tag usava sub di Ruby, che sostituisce la prima corrispondenza di un pattern in una stringa; ora usa gsub, che sostituisce ogni corrispondenza. In entrambe le versioni la sostituzione è la stessa: un'apertura scritta come <% diventa <%%, la forma raddoppiata che ERB, il motore di template di Ruby, rende come testo letterale invece di valutarla. L'avviso non indica quale campo di AI Agent contiene il template; il commit identifica il filtro che avrebbe dovuto rendere quel template inerte.

Con sub, solo il primo opener nella stringa è stato disinnescato. Un payload che inserisce un secondo opener immediatamente dopo il primo sopravvive al filtro: <%<%= 1 + 1 %> diventa <%%<%= 1 + 1 %>, dove ERB emette l'opener iniziale come testo e poi valuta il tag interno. La specifica di regressione aggiunta nello stesso commit descrive chiaramente il trucco — "con un opener annidato contrabbandato all'interno di un singolo tag (bypass escape-all-openers)" — e afferma che sia <%<%= 1 + 1 %> sia un <%<%<%= 1 + 1 %> annidato due volte devono essere renderizzati come testo letterale. Quella specifica è il resoconto pubblico più chiaro di come il filtro sia stato aggirato, perché l'advisory stesso non ne fornisce alcuno.

La forma del bug è generica, non una stranezza di Zammad: un escaper che si ferma dopo il primo match viene aggirato da qualsiasi input che contenga una seconda copia annidata della sequenza che rimuove. Il messaggio di commit definisce la modifica manutenzione, ed è così che di solito passa una patch di hardening da un singolo carattere — ed è per questo che l'avviso, non il diff, ha dovuto contenere l'ammonimento.

Sette settimane dall'advisory all'NVD

NVD ha pubblicato il proprio record per CVE-2026-84462 il 25 settembre 2026, sette settimane dopo l'avviso, e lo ha modificato l'ultima volta il 28 settembre. Il record è contrassegnato come "Deferred", il che significa che l'agenzia non ha pubblicato una propria analisi, e il suo blocco delle metriche attribuisce il punteggio di 8,6 a security-advisories@github.com come metrica secondaria — il punteggio di GitHub in qualità di CVE numbering authority, non una valutazione indipendente di NVD. Lo stesso record non contiene alcuna configurazione CPE, quindi non associa la vulnerabilità a un identificatore di prodotto versionato.

Entrambi i dettagli contano per chi segue il software self-hosted tramite feed anziché tramite note di rilascio. La correzione era pubblica e applicabile il 4 agosto; il record leggibile da macchina è arrivato il 25 settembre; e anche allora è arrivato senza l’identificatore di prodotto su cui eseguono il matching gli scanner basati su CPE. Per sette settimane il resoconto autorevole della vulnerabilità è stato l’avviso del fornitore e la nota di rilascio del fornitore.

Che cosa è stabilito e che cosa non lo è

Accertato: l'avviso, la versione corretta, il punteggio CVSS e la modifica al codice provengono tutti da Zammad e dal database degli avvisi di GitHub, e concordano tra loro. Il record di NVD riproduce la descrizione dell'autorità di numerazione senza aggiungere analisi proprie. Su questa base l'archivio assegna alla voce un livello di confidenza A, con l'incidente non contestato.

Non stabilito, né registrato: non c'è alcuna proof of concept nell'advisory e nessuna segnalazione di sfruttamento in ambienti reali. L'EPSS di FIRST assegna a CVE-2026-84462 una probabilità di sfruttamento dello 0,28 percento nei prossimi trenta giorni, il 20º percentile, nel punteggio pubblicato il 29 ottobre 2026. L'archivio non registra alcun danno reale e classifica la voce come severità media — al di sotto della fascia Alta indicata dall'advisory stesso. Sono strumenti separati che rispondono a domande diverse, ciò che la falla permetterebbe rispetto a ciò che è noto essere accaduto, e questo articolo riporta entrambi anziché conciliarli.

La corroborazione indipendente è scarsa. Una ricerca di copertura di questa CVE restituisce database di vulnerabilità che ripubblicano il testo dell'autorità di numerazione, oltre alla nota di rilascio di Zammad stessa; nessun organo di informazione sembra aver riportato la vulnerabilità in modo indipendente. Si tratta di un rilievo sulla documentazione, non di una critica alla medesima: un'esecuzione di codice remoto in un helpdesk che richiede un account amministratore non è il tipo di evento che genera stampa, e l'assenza di un resoconto indipendente è di per sé parte di ciò che la documentazione attesta.

Chi potrebbe scatenarlo e cosa è cambiato

La nota di rilascio di Zammad per la 7.1.2, datata 4 agosto 2026, elenca le diciotto vulnerabilità corrette in quella versione e mette al primo posto il bypass del template di AI Agent. Per i clienti hosted afferma: "Non è richiesta alcuna azione. Le vostre istanze sono già state corrette e messe in sicurezza dal nostro team." Per le installazioni self-hosted è più diretto: "Consigliamo vivamente di aggiornare immediatamente Zammad all'ultima versione per garantire la protezione del sistema." L'avviso non offre alcuna soluzione alternativa e il registro non riporta alcuna mitigazione oltre all'aggiornamento.

Il requisito di privilegio merita un'analisi più attenta di quanto suggerisca il vettore. PR:H significa che l'attaccante necessita di un accesso significativo perché la vulnerabilità sia sfruttabile e, in questo caso, tale accesso è l'autorizzazione admin.ai_agent che la documentazione di Zammad indica come necessaria per lavorare con gli AI Agents. In un helpdesk, si tratta spesso del responsabile del team di servizio che configura categorizzatori, tagger ed estrattori di testo, non necessariamente della persona che amministra il server. La formulazione dell'avviso stesso, "un amministratore con l'autorizzazione a creare o modificare AI Agents", è più ristretta di "chiunque" e più ampia di "root". Se non è possibile procedere immediatamente a un aggiornamento, limitare chi detiene tale autorizzazione riduce il numero di persone che possono raggiungere il percorso di codice; si tratta di un'inferenza ricavata dal vettore e dalla documentazione, non di una soluzione pubblicata dal fornitore.

Nessuno dei documenti primari colloca un modello linguistico nel percorso di exploit. Il comando viene eseguito all’interno del processo Ruby di Zammad quando viene renderizzata la configurazione dell’agente; nulla nell’advisory, nel commit o nella release note descrive il modello che produce il payload. La funzionalità AI Agent fornisce il campo scrivibile dall’amministratore ed elaborato tramite template, e l’AI è la superficie anziché il meccanismo. Questo è il pattern a cui punta il documento: la definizione dell’agente — le sue istruzioni, i suoi template e i suoi filtri — è configurazione eseguibile, modificata da persone il cui lavoro è supporto, non revisione di sicurezza.

Il rimedio di Zammad è proporzionato e noioso: una modifica a un metodo, due test di regressione e un aggiornamento di versione che chiude altri diciassette buchi insieme a questo. La parte che vale la pena portare avanti è il modello di esposizione. Un helpdesk che consente a un responsabile del supporto di definire un agente consente anche a quel responsabile del supporto di scrivere qualcosa che il server eseguirà, e l'unica cosa che separa le due cose è un filtro che deve essere corretto riguardo a ogni copia annidata della sintassi che rimuove.