La superficie RCE recurrente de n8n: un hub de automatización que guarda todas tus claves

En resumen Durante el primer semestre de 2026, n8n —una plataforma de workflows de código abierto muy usada para construir agentes y automatizaciones impulsados por LLM— ha corregido una serie continua de fallos críticos de ejecución remota de código: una cadena de lectura de archivos sin autenticación divulgada en enero de 2026, una familia de evaluación de expresiones rehecha durante la primavera y un lote de junio de 2026 que añadió un escape del sandbox del nodo de Python y una vía de prototype pollution hacia la RCE. Ninguno es exótico por sí solo. En conjunto, ilustran un problema estructural: un hub de automatización que guarda todos tus secretos es un objetivo de primer valor, y cada fallo detona contra el mismo almacén de secretos compartido. Este es un análisis de clase de vulnerabilidades, no un manual de explotación.

¿Qué es esto?

n8n es un motor de automatización de workflows autoalojable: un pegamento que conecta tu Google Drive, tus claves de API de OpenAI o Anthropic, Salesforce, bases de datos, procesadores de pago, CI/CD y, cada vez más, nodos de agentes LLM que invocan herramientas y modelos en tu nombre. Alrededor de cien mil instancias son alcanzables en la Internet pública, y los investigadores de eSecurity Planet contabilizaron más de 103.000 expuestas a al menos un fallo reciente.

La razón por la que n8n aparece tanto en los boletines no es que esté especialmente mal escrito. Es que un motor de workflows es, por diseño, una máquina para convertir la entrada suministrada por el atacante en lógica evaluada y llamadas de API salientes, mientras se asienta sobre el almacén de secretos más sensible de la organización. En el primer semestre de 2026 el proyecto publicó correcciones para varias causas raíz distintas: una confusión de content-type que llevaba a lecturas de archivos arbitrarias (divulgada en enero de 2026 por Cyera Research Labs como «Ni8mare»), una tanda de escapes de la evaluación de expresiones corregidos y vueltos a corregir en primavera, un fallo global de prototype pollution alcanzable mediante un parámetro de paginación no validado y un escape del sandbox del nodo de código Python publicado en junio. Bugs distintos, un mismo radio de impacto.

Cómo funciona

No hay aquí un único payload; hay una forma que se repite. A lo largo de los fallos, el patrón es este:

El patrón RCE de n8n (conceptual, expurgado)
--------------------------------------------
1. Un punto de entrada acepta una entrada no confiable
   (webhook de formulario, parámetro de petición HTTP, campo de workflow)
2. Esa entrada alcanza una superficie de evaluación
   - valores prefijados para tratarse como expresión -> doble evaluación
   - un nodo de código cuyo sandbox no restringe del todo el runtime
   - una vía de fusión de objetos que contamina un prototipo compartido
3. La evaluación produce lecturas de archivos, fuga de config/secretos o ejecución de código
4. Lo que el atacante alcanza, alcanza el almacén de secretos
   -> tokens de API, concesiones OAuth, conexiones a BD, clave secreta de la instancia

La cadena de enero fue la más ruidosa porque no requería inicio de sesión: una petición con el content-type equivocado era procesada por la rutina equivocada, lo que permitía a un llamante no autenticado leer archivos locales —incluidas la clave secreta de la instancia y la base de datos de usuarios— y, desde ahí, falsificar una sesión de administrador y añadir un nodo de ejecución de comandos. Los problemas de junio son más acotados: en general exigen una cuenta autenticada con permiso para editar workflows, lo que los circunscribe al abuso interno o a una sesión de editor robada. Pero «más acotado» es relativo cuando un solo editor comprometido puede sacar un nodo de Python de su sandbox hacia el contenedor del task runner, o contaminar un prototipo hasta la ejecución de código en el host. La familia de la evaluación de expresiones es la más instructiva: n8n trata como una expresión a evaluar un valor de campo que empieza por un prefijo concreto, y en cuanto el dato del usuario se evalúa en lugar de leerse, solo el sandbox se interpone entre eso y la RCE, un sandbox ya franqueado en más de una ocasión.

Por qué importa

La lección no es «n8n es inseguro», sino «las plataformas de orquestación son estructurales, y seguimos asegurándolas como simples aplicaciones web». Un hub de automatización con IA concentra la autoridad como un controlador de dominio concentra la identidad: cada workflow que construyes le confía otro secreto de larga duración, de modo que el valor de una sola RCE crece con cada integración que añades. Como resume Cyera, una instancia comprometida no significa perder un sistema, sino entregar las llaves de todo lo que hay conectado a ella.

Esto importa más, no menos, a medida que estas plataformas incorporan nodos de agentes. Un nodo LLM convierte documentos recuperados, salidas de herramientas y mensajes de chat en otro canal de entrada no confiable que alimenta las mismas superficies de evaluación y de secretos. La inyección de prompt indirecta y la inyección de expresiones clásica acaban rimando: en ambos casos, «un dato controlado por el atacante llega a un lugar donde se interpreta». Cuando el intérprete se apoya en tu almacén de secretos, el techo de severidad es todo el entorno.

Defensas

1. Parchea de forma agresiva y sigue la rama, no una versión. n8n retroporta sus correcciones a varias líneas de versión (por ejemplo, el parche del escape de sandbox de junio llegó a las ramas 1.123.x, 2.21.x y 2.22.x). Fija el último parche de tu rama y vigila directamente los boletines de seguridad del proyecto, ya que las notas de versión se retrasan a propósito.
2. Sácalo de la Internet pública. El número de instancias expuestas es el verdadero problema. Coloca n8n tras un ingress autenticado o una VPN; un hub de automatización no tiene por qué ser accesible para todo el mundo.
3. Aplica el mínimo privilegio a los editores. La mayoría de los fallos de junio requieren permiso de edición de workflows. Restringe quién puede crear o modificar workflows, audita el historial de cambios y trata el permiso de edición como una concesión sensible, no como un ajuste por defecto.
4. Restringe y aísla los nodos de código/expresión. Desactiva los nodos de Python y Form/Code cuando no sean necesarios (mediante la configuración de exclusión de nodos), ejecuta los task runners en un segmento de red aislado y aplica filtrado de salida para que un escape de sandbox no pueda comunicarse hacia fuera ni alcanzar servicios internos.
5. Rota y compartimenta los secretos. Asume que un compromiso del hub equivale a una pérdida total de secretos: acota los tokens, prefiere credenciales de vida corta, alerta sobre conexiones salientes inesperadas del runner y rota todo lo que n8n pudiera leer si sospechas de abuso.

Estado

Elemento	Referencia	Fecha	Notas
Lectura de archivos sin autenticación → RCE («Ni8mare»)	CVE-2026-21858 (Cyera)	2026-01-07	CVSS 10.0; confusión de content-type, corregido en 1.121.0 (nov. 2025)
Escape de la evaluación de expresiones → RCE	CVE-2025-68613 y sucesivos	2026 (re-parcheado)	Editor de workflow autenticado; expresión tratada como código
Prototype pollution → RCE	CVE-2026-44789	2026-06	CVSS 9.4; parámetro de paginación no validado en el nodo HTTP Request
Escape del sandbox del nodo Python	CVE-2026-49444	2026-06-23	CWE-20; editor autenticado escapa al contenedor task runner; corregido 1.123.48 / 2.21.8 / 2.22.4
Exposición	eSecurity Planet	2026	~103.000 instancias alcanzables y afectadas por un fallo reciente

El encuadre honesto es que ninguno de estos bugs es un ataque inédito. Son los modos de fallo más antiguos del software web —confusión de parser, entrada evaluada, sandboxes débiles, prototype pollution— aterrizando sobre una infraestructura cuya única función es guardar tus secretos y actuar en tu nombre. Es precisamente por eso que aparecen una y otra vez en las noticias, y precisamente por eso el hub de automatización merece la misma desconfianza que darías a un controlador de dominio.