RCE del Agente de IA de Zammad: una etiqueta de plantilla anidada, una corrección de una sola letra

Zammad, el helpdesk de código abierto, publicó la versión 7.1.2 el 4 de agosto de 2026 con dieciocho correcciones de seguridad; la primera de la lista cierra una vulnerabilidad de ejecución remota de código en los campos de configuración de su función AI Agent. La vulnerabilidad es CVE-2026-84462, divulgada en el aviso de GitHub GHSA-gp3x-9xm8-rcj6 ese mismo día, y su rango afectado abarca todas las instalaciones autoalojadas en una versión hasta la 7.1.1 inclusive. Un administrador que pueda crear o editar un AI Agent podría introducir texto especialmente manipulado en uno de los campos del agente, eludir el filtro destinado a neutralizarlo y ejecutar comandos arbitrarios en el servidor que aloja Zammad — con la posibilidad, en palabras del aviso, de «leer, modificar o destruir todos los datos almacenados en ese servidor». Ningún otro usuario tiene que intervenir: el aviso afirma que «el código malicioso se ejecuta automáticamente la próxima vez que el AI Agent afectado procese un ticket». GitHub le asigna la calificación Alta, con 8,6 en CVSS 4.0. El registro, sus etiquetas de gravedad y de daño, y las entradas registradas en torno a él se conservan en el Orca AI Incident Archive, que recoge este incidente junto al resto de la serie.

Lo que establece el aviso

El aviso de GitHub, publicado el 4 de agosto de 2026, es breve y excepcionalmente específico sobre el mecanismo y las condiciones previas. Describe un "filtro de seguridad que protege la configuración del Agente de IA de Zammad" que "puede eludirse introduciendo texto especialmente manipulado en uno de los campos de un Agente de IA", e identifica con precisión al actor: "Un administrador con permiso para crear o editar Agentes de IA podría aprovechar esto para ejecutar comandos arbitrarios en el servidor que aloja Zammad". El rango afectado se registra como hasta 7.1.1 inclusive, y la versión corregida como 7.1.2. La persona que informó, acreditada, es colinthebomb1; la cuenta que publicó es fliebe92. El aviso no publica ninguna prueba de concepto ni detalles de explotación.

GitHub califica el fallo como Alto, 8,6 en CVSS 4.0, con el vector AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H y sin cambio de alcance. Interpretado, eso significa que el fallo es alcanzable a través de la red con baja complejidad, sin requisitos de ataque ni interacción del usuario, por parte de un atacante que ya posee privilegios elevados dentro de la aplicación, con alto impacto sobre la confidencialidad, integridad y disponibilidad de la propia instancia de Zammad. El aviso enumera tres debilidades: CWE-20, validación de entrada incorrecta; CWE-94, inyección de código; y CWE-1336, la clase de motor de plantillas que MITRE define como la falta de neutralización de sintaxis especial "que puede interpretarse como expresiones de plantilla u otras directivas de código cuando el motor las procesa".

La corrección cambió una letra

La corrección pública es el commit e3b0c8df91ad2108c8305be23e8fe6f73fb9718d, enviado con el mensaje «Maintenance: Improve ERB sanitizer». GitHub registra una fecha de autor del 7 de julio de 2026 y una fecha del commit del 3 de agosto de 2026, un día antes del aviso y del lanzamiento. Modifica dos archivos: una línea de lib/erb_sanitizer.rb y catorce líneas añadidas de especificación.

Una sola línea es todo el arreglo. El método escape_tag usaba sub de Ruby, que reemplaza la primera coincidencia de un patrón en una cadena; ahora usa gsub, que reemplaza todas las coincidencias. En ambas versiones el reemplazo es el mismo: una etiqueta de apertura escrita como <% se convierte en <%%, la forma duplicada que ERB, el motor de plantillas de Ruby, renderiza como texto literal en lugar de evaluarla. El aviso no indica cuál campo de AI Agent contiene la plantilla; el commit identifica el filtro que se suponía debía dejar inerte esa plantilla.

Con sub, solo se neutralizó el primer delimitador de apertura de la cadena. Una carga útil que coloca un segundo delimitador de apertura inmediatamente después del primero sobrevive al filtro: <%<%= 1 + 1 %> se convierte en <%%<%= 1 + 1 %>, donde ERB emite el delimitador de apertura inicial como texto y después evalúa la etiqueta interna. La especificación de regresión añadida en el mismo commit describe el truco sin rodeos —«con un delimitador de apertura anidado introducido de contrabando dentro de una sola etiqueta (bypass de escape de todos los delimitadores de apertura)»— y afirma que tanto <%<%= 1 + 1 %> como un <%<%<%= 1 + 1 %> con doble anidamiento deben renderizarse como texto literal. Esa especificación es la explicación pública más clara de cómo se eludió el filtro, porque el propio aviso no ofrece ninguna.

La forma del error es genérica, no una curiosidad de Zammad: un escapador que se detiene tras la primera coincidencia queda vencido por cualquier entrada que contenga una segunda copia anidada de la secuencia que elimina. El mensaje de commit califica el cambio como mantenimiento, que es como suele presentarse un parche de endurecimiento de un solo carácter — y es por eso que el aviso, y no el diff, tuvo que ser el que incluyera la advertencia.

Siete semanas desde el aviso hasta el NVD

NVD publicó su registro para CVE-2026-84462 el 25 de septiembre de 2026, siete semanas después del aviso, y lo modificó por última vez el 28 de septiembre. El registro está marcado como "Deferred", lo que significa que la agencia no ha publicado su propio análisis, y su bloque de métricas atribuye la puntuación de 8.6 a security-advisories@github.com como métrica secundaria: la puntuación de GitHub en calidad de autoridad de numeración de CVE, no una evaluación independiente de NVD. Ese mismo registro no incluye ninguna configuración CPE, por lo que no vincula la vulnerabilidad a un identificador de producto versionado.

Ambos detalles importan a cualquiera que siga software autoalojado mediante feeds en lugar de notas de versión. La corrección fue pública y aplicable el 4 de agosto; el registro legible por máquina llegó el 25 de septiembre; e incluso entonces llegó sin el identificador de producto con el que coinciden los escáneres basados en CPE. Durante siete semanas, la descripción autoritativa de la vulnerabilidad fueron el aviso del proveedor y la nota de versión del proveedor.

Qué está establecido y qué no

Establecido: el aviso, la versión parcheada, la puntuación CVSS y el cambio de código proceden todos de Zammad y de la base de datos de avisos de GitHub, y concuerdan entre sí. El registro de NVD reproduce la descripción de la autoridad de numeración sin añadir análisis propio. Sobre esa base, el archivo califica la entrada con confianza A, y el incidente no está en disputa.

No confirmado, o no registrado: no hay prueba de concepto en el aviso ni reporte de explotación en el mundo real. El EPSS de FIRST atribuye a CVE-2026-84462 una probabilidad de explotación del 0,28 por ciento en los próximos treinta días, el percentil 20, en la puntuación publicada el 29 de octubre de 2026. El archivo no registra daños reales y clasifica la entrada como de gravedad media —por debajo de la banda Alta del propio aviso. Son instrumentos distintos que responden a preguntas diferentes —qué permitiría la vulnerabilidad frente a lo que se sabe que ha ocurrido—, y este artículo informa sobre ambos en lugar de conciliarlos.

La corroboración independiente es escasa. Una búsqueda de cobertura de este CVE devuelve bases de datos de vulnerabilidades que republican el texto de la autoridad de numeración, además de la propia nota de versión de Zammad; ningún medio de noticias parece haber informado de la vulnerabilidad de forma independiente. Es una observación sobre el registro, no una crítica a él: una ejecución remota de código en un sistema de helpdesk que requiere una cuenta de administrador no es el tipo de evento que genera prensa, y la ausencia de un relato independiente es, en sí misma, parte de lo que documenta el registro.

¿Quién podría desencadenarlo y qué cambió?

La nota de versión de Zammad para la 7.1.2, con fecha del 4 de agosto de 2026, enumera las dieciocho vulnerabilidades corregidas en esa versión y sitúa en primer lugar la elusión de la plantilla del Agente de IA. Para los clientes con alojamiento gestionado dice: «No se requiere ninguna acción. Nuestro equipo ya ha aplicado los parches y protegido sus instancias». Para las instalaciones autoalojadas es más directo: «Recomendamos encarecidamente actualizar de inmediato a la última versión de Zammad para garantizar la protección de su sistema». El aviso no ofrece ninguna solución alternativa, y el registro no recoge ninguna mitigación más allá de la actualización.

El requisito de privilegios merece un análisis más detenido de lo que ofrece el vector. PR:H significa que el atacante necesita un acceso importante antes de que la vulnerabilidad resulte útil, y aquí ese acceso es el permiso admin.ai_agent que, según la documentación de Zammad, se requiere para trabajar con AI Agents en general. En un helpdesk, a menudo se trata del responsable de un equipo de servicio que ajusta clasificadores, etiquetadores y extractores de texto, no necesariamente la persona que administra el servidor. La propia formulación del aviso, «un administrador con permiso para crear o editar AI Agents», es más estrecha que «cualquiera» y más amplia que «root». Si no se puede actualizar de inmediato, restringir quién posee ese permiso reduce el grupo de personas que pueden llegar a esa ruta de código; se trata de una inferencia a partir del vector y la documentación, no de una solución publicada por el proveedor.

Ninguno de los documentos primarios sitúa un modelo de lenguaje en la ruta del exploit. El comando se ejecuta dentro del proceso Ruby de Zammad cuando se renderiza la configuración del agente; nada en el advisory, el commit o la nota de lanzamiento describe que el modelo produzca el payload. La función AI Agent proporciona el campo editable por el administrador y procesado mediante plantillas, y la IA es la superficie en lugar del mecanismo. Ese es el patrón al que apunta el registro: la definición del agente —sus instrucciones, plantillas y filtros— es configuración ejecutable, editada por personas cuyo trabajo son labores de soporte, no revisión de seguridad.

El remedio de Zammad es proporcionado y poco llamativo: un cambio de método, dos pruebas de regresión y un incremento de versión que cierra otros diecisiete agujeros junto con este. La parte que merece la pena conservar es el modelo de exposición. Una mesa de ayuda que permite que un responsable de soporte defina un agente también permite que ese responsable de soporte escriba algo que el servidor ejecutará, y lo único que se interpone entre ambas cosas es un filtro que tiene que acertar en cada copia anidada de la sintaxis que elimina.