n8n 2.45.7: quién ve los datos de ejecución

Cada vez que una automatización de n8n se ejecuta, guarda lo que pasó en cada paso: el formulario que entró, el correo del cliente, el pedido, el archivo adjunto. Ese registro es muy útil para encontrar errores. También es información de tus clientes, y no todas las personas que trabajan con tus automatizaciones necesitan verla.

El 30 de octubre de 2026 n8n publicó la versión 2.45.7, que corrige justamente eso: había tres caminos por los que alguien con permiso para ver un flujo podía llegar a esos datos sin tener permiso para ver sus ejecuciones. Aquí te contamos qué cambió, a quién le afecta de verdad y cómo comprobar que tu equipo sigue viendo lo que necesita, y nada más.

Qué cambió y desde cuándo

Primero, dos palabras de n8n. Un flujo es la automatización: los pasos que se repiten solos, como «llega un formulario, se guarda en la hoja y se avisa al equipo». Una ejecución es cada vez que ese flujo corre, con los datos reales que pasaron por él.

En los permisos de n8n son dos cosas distintas. El cambio que lo corrige lo dice así: ver un flujo y ver sus ejecuciones son permisos separados, y la parte de n8n que muestra las ejecuciones ya comprobaba el segundo. Pero había tres accesos que solo comprobaban el primero:

• La última ejecución correcta de un flujo. n8n también la ofrece a las herramientas de IA conectadas a tu instalación por MCP, el sistema que deja que un asistente de IA trabaje con tus flujos.
• Los conjuntos de datos de evaluación. Las evaluaciones sirven para probar flujos con IA con ejemplos guardados, y esos ejemplos pueden salir de ejecuciones reales.
• Los archivos que pasan por los flujos, como un PDF o una imagen adjunta.

Desde la versión 2.45.7, los tres piden el permiso de ver ejecuciones. Según el mismo cambio, quien no lo tenga recibe una respuesta vacía en el primer caso y un «no encontrado» en los otros dos, igual que si pidiera la ejecución directamente.

1. 28 oct 2026n8n integra la corrección en su código principal.
2. 29 oct 2026Se lleva a la rama 2.45, con un ajuste manual para encajarla.
3. 30 oct 2026Sale n8n 2.45.7, la primera versión publicada que la incluye.

La corrección también se trasladó a la rama 2.46, así que debería llegar a las versiones siguientes. Comprueba las notas de la versión que vayas a instalar. El cambio no lleva la marca para trasladarlo a la línea 1.x de n8n, por lo que no conviene suponer que esa línea lo incluye. Todo esto sale de las fuentes oficiales de n8n, consultadas el 31 de octubre de 2026. Ni el cambio ni las notas de la versión hablan de un ataque conocido ni de una gravedad concreta.

A quién le afecta de verdad

Aquí está lo importante para no alarmarse de más. Según la documentación de roles de n8n, los tres roles estándar de un proyecto ya pueden ver las ejecuciones: Admin y Editor las ven y las gestionan, y Viewer las ve en modo lectura. Si tu equipo solo usa esos roles, después de actualizar todo el mundo sigue viendo lo mismo.

El cambio pesa en otro caso: los roles personalizados, disponibles en el plan Enterprise desde la versión 1.122.0. Con ellos puedes crear, por ejemplo, un rol que vea los flujos de un proyecto pero no sus ejecuciones. Las pruebas del propio cambio usan justamente ese caso: un rol con permiso para ver flujos y sin permiso para ver ejecuciones, que antes recibía la última ejecución y ahora recibe una respuesta vacía.

Por qué conviene revisarlo aunque no te afecte

Esta versión es una buena excusa para hacerte una pregunta que muchos negocios nunca se hacen: ¿quién necesita ver los datos de cada automatización?

Quien diseña el flujo necesita ver las ejecuciones para encontrar errores. Quien solo comprueba que el flujo existe, o que está activo, quizá no. Y un proveedor externo que revisa una automatización concreta no tiene por qué ver los datos de tus clientes de los últimos meses. La regla de fondo es dar a cada persona el acceso que necesita para su tarea, y no más.

Si nunca lo has pensado, la respuesta suele estar en tres preguntas: qué datos personales pasan por cada flujo, quién entra a n8n y con qué rol, y si alguna herramienta externa entra con un usuario propio o con el de alguien del equipo.

Cómo comprobarlo, paso a paso

No hace falta que lo hagas tú si alguien mantiene tus automatizaciones. Pero estos son los pasos que seguiríamos, y te sirven para pedirlos:

1. Mira qué versión tienes. Si es anterior a la 2.45.7, la corrección todavía no está. Antes de actualizar, lee las notas de la versión de destino.
2. Haz la lista de accesos. Quién entra a n8n, en qué proyectos y con qué rol. Marca los roles personalizados y los usuarios que usan herramientas externas, como un asistente de IA.
3. Decide quién necesita ver ejecuciones. Flujo por flujo, sobre todo en los que mueven datos de clientes, pagos o archivos.
4. Guarda una copia antes de actualizar. De los flujos y de las credenciales.
5. Prueba con datos inventados. Crea un flujo de prueba con un contacto ficticio y un archivo de ejemplo. Entra con dos perfiles: uno que deba ver las ejecuciones y otro que no. El primero tiene que ver los datos; el segundo, no.
6. Revisa lo que dependa de esos accesos. Si un asistente de IA usaba la última ejecución de un flujo, o si alguien preparaba evaluaciones con ejecuciones reales, confirma que sigue funcionando con el permiso correcto.

Si después de actualizar algo aparece vacío, la tentación es dar a esa persona el rol más amplio para salir del paso. Antes de hacerlo, pregúntate si de verdad necesita ver los datos o solo el flujo. A veces la solución es otra: que el flujo deje un resumen sin datos personales en un sitio que esa persona sí pueda ver.

Si te interesa cómo se ordenan estas piezas cuando la IA entra en tus procesos, en integraciones con IA contamos cómo lo planteamos.

Lo que no conviene hacer

• Pensar que hubo una filtración. Ni el cambio ni las notas de la versión hablan de un ataque ni de datos expuestos. Es una corrección de permisos.
• Suponer que no te toca sin mirar. Si usas roles personalizados o herramientas externas conectadas, sí puede cambiar lo que ven.
• Ampliar permisos para que «vuelva a funcionar». Si algo sale vacío, primero confirma que esa persona o herramienta debe ver esos datos.
• Probar con datos reales de clientes. Para comprobar accesos bastan un contacto y un archivo inventados.
• Mezclar esta revisión con todo lo demás. Los reintentos, las alertas y las copias de seguridad son otro trabajo. Hazlos por separado para saber qué cambió cada cosa.

Si tu instalación de n8n arrastra versiones sin actualizar, revisa también los cambios recientes sobre nodos obsoletos y sobre pausar flujos al reiniciar el servidor. Actualizar una versión cada vez, con una prueba antes, ahorra muchos sustos.