RCE do Agente de IA do Zammad: uma tag de template aninhada, uma correção de uma letra

O Zammad, o helpdesk de código aberto, lançou a versão 7.1.2 em 4 de agosto de 2026 com dezoito correções de segurança; a primeira da lista fecha uma falha de execução remota de código nos campos de configuração do seu recurso AI Agent. A vulnerabilidade é a CVE-2026-84462, divulgada no aviso do GitHub GHSA-gp3x-9xm8-rcj6 no mesmo dia, e seu intervalo afetado abrange toda instalação auto-hospedada em uma versão até 7.1.1 inclusive. Um administrador que possa criar ou editar um AI Agent poderia inserir texto especialmente elaborado em um dos campos do agente, contornar o filtro destinado a neutralizá-lo e executar comandos arbitrários no servidor que hospeda o Zammad — com o potencial, nas palavras do aviso, de "ler, modificar ou destruir todos os dados armazenados naquele servidor." Nenhum outro usuário precisa agir: o aviso afirma que "o código malicioso é executado automaticamente na próxima vez que o AI Agent afetado processar um ticket." O GitHub classifica a falha como Alta, com 8,6 no CVSS 4.0. O registro, suas etiquetas de severidade e de dano, e as entradas arquivadas em torno dele são mantidos em the Orca AI Incident Archive, que lista este incidente junto com o restante da série.

O que o aviso estabelece

O aviso do GitHub, publicado em 4 de agosto de 2026, é curto e excepcionalmente específico quanto ao mecanismo e às precondições. Ele descreve um “filtro de segurança que protege a configuração do Agente de IA do Zammad” que “pode ser contornado inserindo texto especialmente elaborado em um dos campos de um Agente de IA”, e nomeia o ator com precisão: “Um administrador com permissão para criar ou editar Agentes de IA poderia explorar isso para executar comandos arbitrários no servidor que hospeda o Zammad.” O intervalo afetado está registrado como até e incluindo 7.1.1, e a versão corrigida como 7.1.2. O responsável pelo relato creditado é colinthebomb1; a conta publicadora é fliebe92. O aviso não publica nenhuma prova de conceito nem detalhes de exploração.

O GitHub classifica a falha como Alta, 8,6 no CVSS 4.0, com o vetor AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H e sem alteração de escopo. Interpretando, isso significa que a falha é alcançável pela rede com baixa complexidade, sem requisitos de ataque e sem interação do usuário, por um atacante que já possui altos privilégios dentro da aplicação, com alto impacto na confidencialidade, integridade e disponibilidade da própria instância do Zammad. O aviso lista três fraquezas: CWE-20, validação de entrada inadequada; CWE-94, injeção de código; e CWE-1336, a classe de mecanismo de template que a MITRE define como falha em neutralizar sintaxe especial "que pode ser interpretada como expressões de template ou outras diretivas de código quando processada pelo mecanismo."

A correção mudou uma letra.

A correção pública é o commit e3b0c8df91ad2108c8305be23e8fe6f73fb9718d, enviado com a mensagem "Maintenance: Improve ERB sanitizer." O GitHub registra uma data de autor de 7 de julho de 2026 e uma data de commit de 3 de agosto de 2026, um dia antes do comunicado de segurança e da versão. Ele altera dois arquivos: uma linha de lib/erb_sanitizer.rb e catorze linhas de especificação adicionadas.

A única linha é toda a correção. O método escape_tag usava o sub do Ruby, que substitui a primeira ocorrência de um padrão em uma string; agora ele usa o gsub, que substitui todas as ocorrências. Em ambas as versões, a substituição é a mesma: um delimitador de abertura escrito como <% se torna <%%, a forma duplicada que o ERB, o mecanismo de templates do Ruby, renderiza como texto literal em vez de avaliar. O aviso não nomeia qual campo do AI Agent carrega o template; o commit identifica o filtro que deveria tornar esse template inerte.

Com sub, apenas a primeira abertura na string foi desarmada. Um payload que coloca uma segunda abertura imediatamente após a primeira sobrevive ao filtro: <%<%= 1 + 1 %> torna-se <%%<%= 1 + 1 %>, onde o ERB emite a abertura inicial como texto e então avalia a tag interna. A especificação de regressão adicionada no mesmo commit nomeia a artimanha sem rodeios — "com uma abertura aninhada contrabandeada dentro de uma única tag (escape-all-openers bypass)" — e afirma que tanto <%<%= 1 + 1 %> quanto um <%<%<%= 1 + 1 %> duplamente aninhado devem ser renderizados como texto literal. Essa especificação é o relato público mais claro de como o filtro foi contornado, porque o próprio advisory não fornece nenhum.

A forma do bug é genérica, e não uma peculiaridade do Zammad: uma rotina de escape que para após a primeira correspondência é derrotada por qualquer entrada que traga uma segunda cópia aninhada da sequência que ela remove. A mensagem de commit chama a mudança de manutenção, que é como um patch de endurecimento de um único caractere costuma circular — e é por isso que o comunicado de segurança, e não o diff, teve de trazer o alerta.

Sete semanas do aviso ao NVD

O NVD publicou seu registro para a CVE-2026-84462 em 25 de setembro de 2026, sete semanas após o aviso, e o modificou pela última vez em 28 de setembro. O registro está marcado como "Adiado", o que significa que a agência não publicou sua própria análise, e seu bloco de métricas atribui a pontuação 8,6 a security-advisories@github.com como métrica secundária — a pontuação do GitHub como autoridade de numeração de CVE, e não uma avaliação independente do NVD. O mesmo registro não contém qualquer configuração CPE, portanto não mapeia a vulnerabilidade para um identificador de produto versionado.

Ambos os detalhes são importantes para quem acompanha software auto-hospedado por feeds em vez de notas de versão. A correção foi pública e acionável em 4 de agosto; o registro legível por máquina chegou em 25 de setembro; e, mesmo assim, chegou sem o identificador de produto com o qual scanners baseados em CPE fazem correspondência. Durante sete semanas, a descrição oficial da vulnerabilidade foi o aviso do fornecedor e a nota de versão do fornecedor.

O que está estabelecido e o que não está

Confirmado: o advisory, a versão corrigida, a pontuação CVSS e a alteração de código vêm todos do Zammad e da base de dados de advisories do GitHub, e estão de acordo entre si. O registro do NVD reproduz a descrição da autoridade de numeração sem acrescentar análise própria. Com base nisso, o arquivo atribui à entrada a confiança A, com o incidente incontroverso.

Não estabelecido, ou não registrado: não há prova de conceito no aviso e nenhum relato de exploração em ambiente real. O EPSS do FIRST atribui ao CVE-2026-84462 uma probabilidade de 0,28% de exploração nos próximos trinta dias, o 20º percentil, na pontuação publicada em 29 de outubro de 2026. O arquivo não registra nenhum dano real e classifica o registro como de severidade média — abaixo da própria faixa Alta do aviso. Esses são instrumentos separados que respondem a perguntas diferentes — o que a falha permitiria contra o que se sabe ter acontecido —, e este artigo relata ambos em vez de conciliá-los.

A corroboração independente é escassa. Uma busca por cobertura desta CVE retorna bancos de dados de vulnerabilidades que republicam o texto da autoridade de numeração, além da própria nota de versão do Zammad; nenhum veículo de imprensa parece ter noticiado a falha de forma independente. Trata-se de uma constatação sobre o registro, não de uma crítica a ele: uma execução remota de código em um helpdesk que exige uma conta de administrador não é o tipo de evento que gera repercussão na imprensa, e a ausência de um relato independente é, por si só, parte daquilo que o registro documenta.

Quem poderia disparar isso, e o que mudou?

A nota de versão do Zammad para a 7.1.2, datada de 4 de agosto de 2026, enumera as dezoito vulnerabilidades corrigidas nessa versão e coloca em primeiro lugar o bypass de template do AI Agent. Para os clientes com alojamento (hosted), refere: «Não é necessária qualquer ação. As suas instâncias já foram corrigidas e protegidas pela nossa equipa.» Para as instalações auto-alojadas (self-hosted), é mais direto: «Recomendamos vivamente que atualize imediatamente para a versão mais recente do Zammad para garantir que o seu sistema está protegido.» O comunicado de segurança não oferece qualquer solução alternativa, e o registo não contempla qualquer mitigação além da atualização.

O requisito de privilégio merece um olhar mais atento do que o vetor indica. PR:H significa que o atacante precisa de acesso significativo para que a falha seja útil, e aqui esse acesso é a permissão admin.ai_agent que a documentação do Zammad afirma ser necessária para trabalhar com AI Agents. Em uma central de atendimento, isso costuma ser o líder da equipe de atendimento que ajusta categorizadores, etiquetadores e extratores de texto — não necessariamente a pessoa que administra o servidor. A própria redação do aviso, “um administrador com permissão para criar ou editar AI Agents”, é mais restrita do que “qualquer pessoa” e mais ampla do que “root”. Se não for possível fazer uma atualização imediatamente, restringir quem detém essa permissão reduz o conjunto de pessoas que conseguem alcançar o caminho do código; isso é uma inferência a partir do vetor e da documentação, não um remédio publicado pelo fornecedor.

Nenhum dos documentos primários coloca um modelo de linguagem no caminho do exploit. O comando é executado dentro do processo Ruby do Zammad quando a configuração do agente é renderizada; nada no comunicado de segurança, no commit ou na nota de versão descreve o modelo produzindo o payload. A funcionalidade AI Agent fornece o campo gravável pelo administrador e processado por template, e a IA é a superfície, não o mecanismo. Esse é o padrão que o registro aponta: a definição do agente — suas instruções, templates e filtros — é configuração executável, editada por pessoas cujo trabalho é suporte, não revisão de segurança.

A correção do Zammad é proporcional e monótona: uma mudança de método, dois testes de regressão e um incremento de versão que fecha outras dezessete falhas junto com esta. A parte que vale a pena levar adiante é o modelo de exposição. Um helpdesk que permite a um líder de suporte definir um agente também permite que esse líder de suporte escreva algo que o servidor executará, e a única coisa entre os dois é um filtro que precisa acertar em cada cópia aninhada da sintaxe que remove.