Bug de nodos fijados en n8n: qué pasó y cómo arreglarlo

Un usuario de n8n Cloud reportó en la comunidad oficial que su webhook de producción mostraba ejecuciones con datos falsos, congelados en una prueba anterior. No era un error de caché ni un “glitch visual”: era un bug de nodos fijados en n8n que persistía incluso después de desfijar los nodos manualmente. El equipo de n8n investigó el problema y lanzó un parche en la versión 1.60.0, publicada en mayo de 2026.

n8n es una herramienta de automatización de flujos de trabajo de código abierto, desarrollada por n8n GmbH (creada por Jan Oberhauser), que permite conectar aplicaciones y servicios para automatizar tareas.

El bug de nodos fijados en n8n es una regresión que provoca que la metadata “Pinned” de una ejecución de prueba se filtre a ejecuciones de producción posteriores, forzando al workflow a usar datos simulados aunque el nodo ya no esté configurado como fijado. Afecta tanto a n8n Cloud como a instancias self-hosted, y su impacto no es cosmético: corrompe la salida real del flujo sin disparar alertas.

¿En qué consiste el bug de nodos fijados en n8n?

Cuando trabajás con n8n, podés “fijar” (pin) un nodo para que devuelva siempre los mismos datos de prueba, ideal para iterar sin depender de APIs externas. El problema aparece cuando desfijás el nodo, lo pasás a producción, y las ejecuciones siguen mostrando el cartelito de “Fijado” con los datos de la prueba vieja.

El usuario ibrh96prog lo documentó en el foro de n8n con un caso concreto: un webhook que debía procesar datos entrantes mostraba ejecuciones en el panel, pero los datos eran los de una prueba hecha horas antes. Desfijó los nodos una y otra vez. Nada. El panel seguía marcándolos como “Pinned” en producción real.

Acá lo peligroso: n8n no tira un error, no frena el workflow, no avisa. Simplemente ejecuta con datos que no son los reales, y vos podés ver todo sin errores evidentes y asumís que funcionó. (Spoiler: no funcionó). Cubrimos ese tema en detalle en nuestra guía del nodo HTTP Request.

¿Cómo afecta este bug a los flujos de trabajo en producción?

El impacto no es menor. Si tu workflow recibe un webhook de Mercado Pago con datos de un pago real, pero el nodo fijado devuelve el JSON de prueba que armaste hace tres días con montos ficticios, la automatización sigue su curso con datos basura. Facturás mal, notificás mal, almacenás mal.

Lo peor es que perdés visibilidad. El panel de ejecuciones puede no mostrar errores, pero al inspeccionar los datos ves que corresponden a una prueba anterior. La depuración se vuelve un infierno porque no sabés si el problema es tu lógica, tu API, o este bug silencioso que está usando datos congelados mientras vos revisás logs en busca de otro culpable.

¿Y si tenés varios workflows encadenados? Exacto, el dato falso se propaga. El workflow A le pasa basura al workflow B, y para cuando te das cuenta ya generaste inconsistencias en tu base que tenés que reparar a mano.

¿Cuál es la causa raíz del bug de nodos fijados?

Esto no fue un error de diseño: fue una regresión. El equipo de n8n identificó un cambio no intencional en cómo la plataforma manejaba pinData entre ejecuciones de prueba y producción, lo que provocó que la metadata “Pinned” se filtrara a ejecuciones nuevas como si el nodo siguiera fijado. La etiqueta “Pinned” que ves en el panel de ejecuciones es histórica —queda registrada desde la primera ejecución de prueba—, pero la regresión hizo que ese estado se persistiera incorrectamente. Esto se conecta con lo que analizamos en cómo configurar notificaciones en Slack.

No era un tema de caché del navegador, ni de cookies, ni de “probá con Ctrl+Shift+R” (aunque varios lo sugirieron). Era el backend persistiendo metadata que no debía persistir.

¿Cómo solucionar el bug de nodos fijados en n8n?

La respuesta corta: actualizá a la versión 1.60.0 o superior de n8n. Esa versión incluye la corrección definitiva. Si estás en n8n Cloud, el parche ya se aplicó del lado del servidor; si tenés una instancia self-hosted, corré el update manualmente. No hay atajo mágico desde la UI.

Mientras tanto, si no podés actualizar ya, tenés dos parches temporales medio artesanales:

• Eliminá y volvé a crear los nodos afectados. No alcanza con desfijarlos; el estado corrupto queda asociado al ID del nodo. Borrarlo y recrearlo fuerza un ID nuevo sin la metadata heredada.
• Limpiá pinData del JSON del workflow. Exportás el workflow, abrís el JSON, buscás "pinData" y lo vaciás ({}) o lo eliminás. Reimportás. No es elegante, pero funciona.

Ojo con subestimar esto como “error visual”: no lo es. Los datos que ves fijados en producción son los que efectivamente está usando el motor de ejecución. Si no lo corregís, tu workflow está operando con información falsa y vos ni te enteraste. Complementá con instalación de n8n con Docker.

¿Qué otras vulnerabilidades críticas afectaron a n8n en 2026?

Mientras la comunidad lidiaba con el bug de nodos fijados, apareció otra alerta bastante más grave: una vulnerabilidad en el nodo Merge cuando se usa en modo SQL. Según el reporte de WhileInt, permite ejecución remota de código (RCE) a atacantes autenticados. O sea, alguien con acceso a tu instancia de n8n podría ejecutar comandos arbitrarios en el servidor a través de una consulta SQL maliciosa en el nodo Merge.

Los parches para esta vulnerabilidad se distribuyeron en versiones específicas de n8n. Si estás en una versión anterior, el riesgo es real y no es teórico: ya circulan pruebas de concepto. La actualización a la versión 1.60.0 o superior, que corrige el bug de nodos fijados, incluye también los parches de seguridad anteriores, así que actualizar te cubre ambos frentes.

¿Qué bug afectó al workflow gratuito de contenido de lanzamiento?

El caso que ilustró la importancia de validar nodos fue un workflow gratuito alojado en Gumroad que automatiza la creación de cinco piezas de contenido de lanzamiento (blog intro, LinkedIn, X, Instagram, email) a partir de una sola descripción de producto. El desarrollador, conocido como ibrh96prog, lo construyó con un LLM node conectado a Claude Code y validó cada tipo de nodo contra el schema real de n8n usando n8n-mcp-server.

Lo probó en n8n Cloud. Dos nodos corrieron en verde, impecables, pero el flujo completo fallaba sin explicación. El problema estaba en el Code node: al tener configurado el LLM node con respuesta en formato JSON, los datos ya llegaban parseados como campos separados en lugar de un string de texto crudo. No había nada que parsear, y el error Cannot read property 'text' of undefined era inevitable. Tras varios intentos, encontró la causa real revisando plantillas reales con n8n-mcp-server. La solución fue hacer que el Code node manejara tanto el caso de texto crudo como el de datos ya estructurados.

El dato clave: este desarrollador usó validación de nodos con MCP server, así que descartó errores de tipeo en el JSON y tipos de nodos inventados —algo que, según él mismo señala, es moneda corriente en las 9.000 plantillas gratuitas que circulan por ahí, muchas generadas por LLMs que adivinan parámetros y se rompen con cualquier update de versión—, y aun así el bug le comió tiempo de depuración.

Versiones afectadas vs. corregidas

Problema	Versiones afectadas	Versión que lo corrige	Fecha aproximada
Bug de nodos fijados (regresión)	Anteriores a la versión 1.60.0	Versión 1.60.0 o superior de n8n	Mayo 2026
Vulnerabilidad en Merge SQL (RCE)	Anteriores a los parches de seguridad	Versiones con parches de seguridad	2026 (previo)

¿Qué está confirmado y qué no?

• Confirmado: El bug es una regresión real en el manejo de pinData, reconocida por el equipo de n8n. La versión 1.60.0 lo resuelve de forma definitiva.
• Confirmado: Afecta tanto a n8n Cloud como a instancias self-hosted. No es exclusivo de un entorno.
• Confirmado: Existen otras vulnerabilidades independientes que también requieren mantener la plataforma actualizada.
• No confirmado: Si el bug afectó a todas las instancias self-hosted o solo a aquellas que migraron desde versiones específicas. Los reportes en la comunidad sugieren que la mayoría de los casos venían de upgrades recientes, pero sin dato oficial.
• No confirmado: La fecha exacta de introducción de la regresión. El equipo de n8n no publicó el commit culpable ni la versión donde comenzó.

Errores comunes al enfrentar este bug

Asumir que es un glitch de interfaz. Varios usuarios en el foro lo descartaron como “problema visual”. No lo es. Los datos fijados son los que el motor de n8n procesa efectivamente. Si el panel dice “Pinned”, el workflow está corriendo con esos datos, te guste o no. Tema relacionado: automatizar procesos con n8n.

Limpiar caché del navegador como solución. Ctrl+Shift+R no arregla nada acá. El problema está en cómo el backend persiste el estado pinned, no en cómo el frontend lo renderiza. Perder tiempo probando con otro navegador o en modo incógnito es al pedo.

Usar plantillas gratuitas sin validar los nodos. El desarrollador del workflow roto invirtió tiempo en verificar cada tipo de nodo contra el schema real con n8n-mcp-server. La mayoría de las plantillas que andan dando vueltas no pasan ese filtro: fueron generadas por un LLM que adivinó tipos y parámetros, y se rompen silenciosamente cuando n8n actualiza algo. Si vas a usar una plantilla ajena, validala. Si estás corriendo n8n en un VPS local, por ejemplo en donweb.com, tomate el tiempo de revisar el JSON antes de ponerlo en producción.

Preguntas Frecuentes

¿En qué consiste el bug de nodos fijados en n8n?

Es una regresión que provoca que nodos previamente fijados para pruebas sigan mostrando datos simulados en ejecuciones de producción, incluso después de desfijarlos manualmente. El backend persiste el estado “Pinned” de forma incorrecta y el motor de n8n usa esos datos en lugar de los reales.

¿Cómo afecta el bug de nodos fijados a los flujos de trabajo activos?

Los webhooks ignoran el payload entrante y procesan datos congelados de pruebas anteriores. El panel de ejecución no muestra errores, lo que hace que el problema pase desapercibido mientras el workflow genera resultados con información falsa que se propaga a otros flujos encadenados.

¿Cuál es la versión de n8n que corrige el bug de nodos fijados?

La versión 1.60.0 o superior de n8n incluye la corrección definitiva. Si estás en n8n Cloud, el fix ya está aplicado; en self-hosted, tenés que actualizar manualmente.

¿Qué otras vulnerabilidades críticas tiene n8n?

Se han reportado vulnerabilidades en versiones anteriores, como la del nodo Merge en modo SQL que permite ejecución remota de código. Cualquier atacante autenticado puede explotarla si la instancia no está parcheada. Mantener n8n actualizado es la medida principal de protección.

¿Cómo verificar si mi workflow de n8n está afectado por este bug?

Revisá el panel de ejecuciones en producción: si ves la etiqueta “Pinned” en nodos que desfijaste, el bug está activo. Compará los datos de entrada reales con los que muestra la ejecución; si coinciden exactamente con una prueba anterior, tu workflow está corriendo con datos falsos. Actualizá a la versión 1.60.0 o superior, o aplicá los workarounds manuales.

Conclusión

El bug de nodos fijados no fue un simple errorcito de UI que se arregla refrescando la página: fue una regresión silenciosa que corrompió ejecuciones reales sin dejar rastro de error. La complejidad del problema y las iteraciones necesarias para resolverlo hablan de lo fácil que es subestimarlo como “cosmético”.

Si mantenés workflows en n8n que tocan plata, notifican clientes o disparan procesos críticos, la lección es una sola: actualizá sin chistar. Validá las plantillas antes de usarlas. Y cuando veas un cartelito de “Pinned” en producción, no asumas que es un glitch: es un bug que ya dejó a más de uno con datos basura en su base.

Fuentes

• The n8n bug that took three tries to find (and the free workflow it broke) – dev.to
• Bug: Nodes showing as pinned in non-test workflow executes – n8n Community
• Critical n8n Flaw Can Let Attackers Reach Remote Code Execution Through Merge Node SQL Mode – WhileInt