La vulnerabilidad de Send-and-Wait en n8n: qué dice el aviso
Qué dice el aviso de la vulnerabilidad Send-and-Wait de n8n (GHSA-728h-pmr2-7cgh): versiones afectadas, corrección oficial y soluciones temporales.
Comprobado con las fuentes citadas el .
Qué es la vulnerabilidad de Send-and-wait en n8n
Un aviso de seguridad de GitHub publicado el 30 de septiembre de 2026 describe una vulnerabilidad de send-and-wait en n8n que afecta al endpoint de webhook en espera (waiting-webhook) del que dependen los flujos de trabajo de aprobación. Según el aviso, identificado como GHSA-728h-pmr2-7cgh, el endpoint aceptaba un segundo formato de referencia de nodo Send-and-Wait sin las comprobaciones de firma que las aprobaciones normalmente requieren, porque el sistema elegía qué validación aplicar antes de normalizar ese formato.
El aviso describe esto específicamente como un fallo en la forma en que se validan las solicitudes de reanudación de Send-and-Wait. Aquí nos referimos a ello como una omisión de aprobación en la ejecución en espera de n8n, como una forma abreviada y descriptiva propia, no una frase que use el propio aviso, y el aviso enmarca el problema de forma restringida en lugar de como una categoría más amplia de problema de autenticación.
Qué versiones de n8n están afectadas
El aviso enumera como versiones afectadas las versiones de n8n anteriores a 2.42.1 y anteriores a 2.41.4; es decir, las compilaciones 2.41.x anteriores a 2.41.4 y las compilaciones 2.42.x anteriores a 2.42.1. Si tu instancia se ejecuta en alguna de esas líneas sin el parche posterior, la descripción del aviso se aplica a ti.
| Línea de versión | Estado según el aviso |
|---|---|
| 2.41.x antes de 2.41.4 | Afectada |
| 2.42.x antes de 2.42.1 | Afectada |
| 2.41.4 o posterior | Corregida |
| 2.42.1 o posterior | Corregida |
n8n afirma que el problema se corrigió en las versiones 2.42.1 y 2.41.4, y su propia instrucción es actualizar a una de estas versiones o posterior. El aviso no indica si líneas mayores o menores anteriores comparten el mismo fallo, por lo que esa pregunta queda fuera de lo que aquí se confirma.
Gravedad y el riesgo de omisión de HMAC en n8n
El aviso trata esto como una omisión de autorización en el endpoint de webhook en espera, donde alguien distinto del aprobador previsto puede resolver un paso pendiente de Send-and-Wait. También indica que, una vez que eso ocurre, todo lo que sigue se ejecuta con las credenciales del propietario del flujo de trabajo, lo que, dependiendo del flujo, puede llegar a la ejecución de comandos. Esa combinación significa que esta vulnerabilidad de send-and-wait en n8n puede tener consecuencias que van mucho más allá del propio paso de aprobación.
Creemos que ese alcance importa para la priorización: esta omisión de HMAC en n8n es más grave en flujos de trabajo donde la puerta de aprobación protege algo costoso, como liberar un pago o conceder acceso, y menos urgente en una notificación interna de bajo riesgo.
La propia entrada del blog de n8n sobre su práctica de divulgación de vulnerabilidades ofrece contexto general sobre por qué el momento importa una vez que una corrección es pública, aunque es anterior a este aviso concreto y no está escrita sobre este caso.
La corrección de seguridad de Send-and-wait de n8n y soluciones temporales
La solución principal de n8n es la actualización de versión ya mencionada: 2.42.1, 2.41.4 o posterior. En nuestra opinión, esa actualización es el único paso que realmente cierra esta brecha de la corrección de seguridad de send-and-wait, y merece tratarse como el primer punto de la lista en lugar de incluirse en el mantenimiento rutinario.
El aviso también menciona tres medidas temporales para los equipos que no pueden actualizar de inmediato, pero es explícito en que son solo a corto plazo y no remedian por completo el riesgo subyacente, por lo que funcionan como un puente y no como un sustituto de la aplicación del parche.
Lo que el aviso no dice
El aviso no desglosa el impacto por edición de n8n ni por plan de hospedaje: solo da los cortes de versión del paquete, no declaraciones separadas sobre instancias Cloud, Enterprise o Community. Si tu equipo necesita saber si tu plan específico requería una acción separada para esta vulnerabilidad de send-and-wait en n8n, esa pregunta queda fuera de lo que indica el anuncio, y el soporte de n8n o tu gestor de cuenta es el lugar adecuado para preguntarlo.
El aviso tampoco asigna ningún identificador CVE, y lista GHSA-728h-pmr2-7cgh como su única referencia, y no describe un procedimiento de actualización, el tiempo de inactividad esperado, ni confirma si las instancias Cloud se actualizan automáticamente.
Sources: Send-and-Wait HMAC Bypass Allows Unauthenticated Approval of Waiting Executions · Advisory · n8n-io/n8n · GitHub, Overview · n8n-io/n8n · GitHub
Contexto: cómo funcionan los tokens de reanudación y las aprobaciones de Send-and-Wait
La documentación del nodo Wait de n8n explica que el nodo proporciona una variable resumeUrl, de modo que un flujo de trabajo puede entregar un enlace único que continúa la ejecución más adelante cuando alguien hace clic en él o envía una respuesta. Los nodos Send-and-Wait en canales como Slack, Telegram y Discord construyen pasos de aprobación sobre ese mecanismo, emparejando el enlace de reanudación con una firma destinada a confirmar que la respuesta provino del aprobador previsto.
Una entrada del registro de cambios de la versión 2.30 de n8n, de julio de 2026, señala que todos los nodos Send-and-Wait de estos canales incorporaron una marca de tiempo que registra cuándo llegó una respuesta de aprobación, una función no relacionada con este aviso. Se menciona aquí solo como contexto sobre cuán activamente se mantiene esta familia de nodos, no como algo que afecte a la propia omisión de HMAC.
Sources: Wait | Nodes | n8n Docs, Changelog | n8n Docs
Próximos pasos editoriales para los equipos que usan n8n
Más allá de las instrucciones del propio aviso, estos son los pasos que sugeriríamos para un equipo que ejecuta n8n en producción: un consejo editorial, no algo que el aviso en sí indique hacer.
- Hacer un inventario de todos los flujos de trabajo que colocan un nodo de aprobación Send-and-Wait después de un disparador público de Webhook, Form o Chat
- Preguntar al soporte de n8n si se necesita alguna acción para tu implementación específica
- Considerar suscribirse a las notificaciones de avisos de seguridad de n8n para no pasar por alto futuras correcciones
Nos sentimos optimistas de que los equipos que ya tratan Send-and-Wait como un mecanismo de aprobación de nivel de producción, en lugar de una comodidad para demostraciones, encontrarán sencillo priorizar esta actualización en cuanto esté en su radar.
