Descripción de la vulnerabilidad

Se ha identificado una vulnerabilidad en n8n mediante la cual los valores de cabeceras HTTP personalizadas, configuradas en las credenciales de determinados sub-nodos LLM, quedan expuestos en texto plano dentro de los datos de ejecución de los flujos de trabajo. Aunque estas cabeceras aparecen enmascaradas en la interfaz de usuario de n8n, durante la ejecución real del flujo de trabajo se escriben sin cifrado ni ofuscación en los datos de ejecución almacenados.

Los sub-nodos afectados incluyen, entre otros, OpenAI, Anthropic y Lemonade.

Impacto

Cualquier usuario autenticado que tenga acceso a los datos de ejecución de un flujo de trabajo afectado puede leer en texto plano tanto los nombres como los valores de las cabeceras personalizadas. Estos valores típicamente contienen claves API u otros secretos de autenticación sensibles.

Dado que los datos de ejecución pueden persistirse en la base de datos y exportarse, los valores filtrados pueden permanecer accesibles más allá del ciclo de vida de una ejecución individual. Esto amplía significativamente la ventana de exposición y el riesgo asociado, ya que los secretos comprometidos podrían ser recuperados de registros históricos incluso después de que la ejecución haya concluido.

Esta vulnerabilidad afecta exclusivamente a las instancias en las que los flujos de trabajo utilizan sub-nodos LLM con cabeceras personalizadas definidas en sus credenciales. Las instancias que no hagan uso de esta configuración específica no se ven afectadas.

Parches disponibles

El problema ha sido corregido en las siguientes versiones de n8n:

  • 1.123.64
  • 2.29.8
  • 2.30.1

Se recomienda a todos los usuarios actualizar a una de estas versiones, o a cualquier versión posterior, para remediar la vulnerabilidad de forma definitiva.

Mitigaciones temporales

En los casos en que la actualización inmediata no sea posible, los administradores deben considerar las siguientes medidas de mitigación temporal:

  • Restringir el acceso a los datos de ejecución exclusivamente a usuarios de plena confianza.
  • Evitar la configuración de cabeceras personalizadas en las credenciales de los nodos LLM y utilizar mecanismos de autenticación alternativos cuando sea posible.
  • Rotar todas las claves API y secretos que puedan haber sido almacenados como valores de cabeceras personalizadas en las credenciales afectadas.

Estas medidas de mitigación no remedian completamente el riesgo y deben emplearse únicamente como soluciones a corto plazo mientras se planifica la actualización a una versión parcheada.