Alerta Sysadmin: Vulnerabilidad Crítica en Orkes Conductor bajo Explotación Activa

septiembre 19, 2026 Alfonso Moreno | Sysadmin Senior 35 Visitas 8 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Por qué esta alerta importa aunque no uses Orkes

El 15 de septiembre de 2026 Fortinet publicó un outbreak alert por CVE-2026-58138, una falla de ejecución remota de código sin autenticación en Orkes Conductor, el orquestador de workflows derivado del proyecto open source Netflix Conductor. La vulnerabilidad tiene CVSS 9.8 (v3.1) y 9.3 (v4.0), está siendo explotada activamente en producción, y existe exploit público desde agosto de 2026 en Exploit-DB (EDB-52633).

¿Por qué te importa si no corres Orkes? Porque el patrón es educativo: una API HTTP que evalúa expresiones en un sandbox (en este caso GraalVM) que se configuró con permisos demasiado amplios (HostAccess.ALL o allowAllAccess(true)). El mismo patrón se repite en otros productos: n8n con Code nodes mal configurados, Apache NiFi con ExecuteScript, Airflow con PythonOperator sin sandboxing, y Rundeck con job scripts. Si tu stack tiene un motor de ejecución de código expuesto a Internet, este CVE es la señal para revisar la configuración.

Además, el volumen de intentos de explotación está creciendo: Fortinet registró 1.290 intentos bloqueados en 24 horas el 9 de septiembre de 2026, un aumento del 132% respecto al día anterior, y casi 7.000 intentos entre el 2 y el 9 de septiembre. Los principales orígenes reportados son Alemania, Hong Kong, Indonesia, Emiratos Árabes Unidos e India.

Qué es Orkes Conductor y por qué la falla es tan seria

Orkes Conductor es una plataforma de orquestación de workflows usada para coordinar microservicios, tareas distribuidas y procesos largos en arquitecturas cloud-native. Su modelo es declarativo: defines un workflow como JSON con tareas (INLINE, LAMBDA, DO_WHILE, SWITCH, etc.) y el motor las ejecuta en orden, llamando a workers externos o evaluando código inline.

Para soportar lógica custom, Orkes Conductor integra GraalVM como motor de ejecución de JavaScript y Python. Esa es la puerta que abre CVE-2026-58138: si el evaluador GraalVM está configurado con permisos amplios, una definición de workflow maliciosa puede escapar del sandbox y ejecutar comandos del sistema operativo.

La descripción oficial del NVD lo dice textualmente: Orkes Conductor 3.21.21 antes de 3.30.2 contiene una vulnerabilidad de ejecución remota de código sin autenticación que permite a atacantes remotos ejecutar comandos arbitrarios del sistema operativo enviando definiciones de workflow inline con expresiones JavaScript o Python maliciosas al endpoint de la API de workflows antes de la autenticación.

El vector técnico: cómo se explota

El ataque no requiere credenciales. El atacante envía una definición de workflow al endpoint HTTP de la API de Conductor con código JavaScript o Python embebido en campos que el evaluador GraalVM procesa. Si los evaluadores están configurados con HostAccess.ALL o allowAllAccess(true) (la configuración por defecto en muchos deployments), el código puede invocar APIs Java reflection o lanzar subprocess directamente.

Tipos de tareas afectadas según la descripción del NVD y el commit de fix en conductor-oss/conductor#87a7d96:

INLINE: tareas que ejecutan una expresión inline en el motor.
LAMBDA: tareas que llaman a una función lambda definida en el workflow.
DO_WHILE: bucles que pueden llevar expresiones maliciosas en la condición o el cuerpo.
SWITCH: branching que evalúa casos con expresiones.

Una vez que el atacante tiene ejecución de OS commands, corre con los privilegios del proceso Conductor, que en muchos deployments es root o un usuario con acceso a bases de datos, secretos y otros servicios internos.

Cómo verificar si tu server está expuesto

El primer chequeo es directo: ¿la API de Conductor responde en una IP pública? Si es así, se puede asumir que el servidor está en riesgo hasta que se demuestre lo contrario con evidencia.

# Comprobar si el endpoint /api/workflow responde sin autenticación
curl -sS -o /dev/null -w "%{http_code}n" 
  -X POST https://conductor.example.com/api/workflow/ 
  -H "Content-Type: application/json" 
  -d '{"name":"probe","version":1,"tasks":[{"name":"t1","taskReferenceName":"t1","type":"INLINE","inputParameters":{"expression":"1+1"}}]}'
# 200 = endpoint responde (potencialmente vulnerable si versión < 3.30.2)
# 401 = requiere autenticación (mejor, pero no es garantía)
# connection refused / timeout = no expuesto (bien)

Si el endpoint responde, el siguiente paso es identificar la versión. La API de Conductor expone la versión en el endpoint /health o /actuator/info en deployments Spring Boot.

# Extraer la versión del manifest de la release
curl -sS https://conductor.example.com/actuator/info | python3 -m json.tool | grep -i version
# Alternativa: leer el jar/war si tienes acceso al filesystem del server
unzip -p /opt/conductor/conductor-server.jar META-INF/MANIFEST.MF | grep -i version

Versiones vulnerables: cualquier build entre 3.21.21 y 3.30.1 inclusive. La versión parcheada es 3.30.2, publicada el 3 de junio de 2026, dos meses antes de que Fortinet detectara explotación masiva.

Mitigación inmediata si no se puede parchear hoy

Si el deployment de Conductor está en una versión vulnerable y el ciclo de upgrade no permite actualizar esta semana, hay tres controles que detienen la explotación sin tocar el binario.

1. Cortar acceso externo a la API de workflows. El endpoint crítico es /api/workflow/*. Si tu Conductor solo lo consume tráfico interno, un firewall o un reverse proxy con autenticación es suficiente.

# Regla nftables para bloquear /api/workflow desde Internet
nft add rule inet filter input tcp dport 8080 
  ip saddr != { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } 
  tcp dport != { 80, 443 } drop
# Verificar que la regla se aplicó
nft list ruleset | grep -A2 'tcp dport 8080'

2. Restringir el sandbox de GraalVM en la configuración del servidor. Conductor permite configurar las opciones de GraalVM por deployment. Cambiar HostAccess.ALL por un perfil más estricto rompe la explotación incluso si llega un payload malicioso.

# Editar conductor-server.properties o conductor.config.json
# Buscar las opciones de evaluación de GraalVM y ajustar:
# ANTES (vulnerable):
conductor.evaluator.graaljs.host-access=ALL
conductor.evaluator.python.allow-all-access=true
# DESPUÉS (más restrictivo):
conductor.evaluator.graaljs.host-access=NONE
conductor.evaluator.python.allow-all-access=false
# Reiniciar el servicio para aplicar
systemctl restart conductor-server

3. Activar logging detallado y alertas sobre definiciones nuevas. El exploit funciona enviando definiciones de workflow con expresiones en INLINE, LAMBDA, DO_WHILE y SWITCH. Si el SIEM está configurado para alertar cuando aparece una workflow con esos tipos desde una IP que no es la de los developers conocidos, se obtiene detección temprana.

# Query de ejemplo para Elasticsearch / Loki sobre definiciones sospechosas
jq 'select(.tasks[]?.type | INLINE, LAMBDA, DO_WHILE, SWITCH)' 
  /var/log/conductor/audit.log | tail -20
# Alertar por Slack/email cuando aparece un INLINE con 'subprocess' o 'ProcessBuilder'
grep -E 'subprocess|ProcessBuilder|Runtime.getRuntime' /var/log/conductor/audit.log 
  | awk -v date="$(date -Iseconds)" '{print date, $0}' 
  | mail -s "Conductor: posible RCE detectado" [email protected]

Upgrade definitivo a Conductor 3.30.2 o superior

La solución de fondo es actualizar. El fix está en el commit c691e35 y restringe el acceso de los evaluadores GraalVM por defecto. Si usas Docker, el upgrade es cambiar el tag de la imagen.

# Pull de la versión parcheada (verifica contra la última estable)
docker pull conductoross/conductor:latest-3.30.2
# Backup del estado antes de upgrade
docker exec conductor-db pg_dump -U postgres conductor > /backup/conductor-$(date +%F).sql
# Reiniciar el stack con la versión nueva
cd /opt/conductor && docker compose down && docker compose pull && docker compose up -d
# Verificar que la versión nueva está corriendo
docker exec conductor-server cat /app/VERSION

Si el deployment corre sobre Kubernetes con Helm, el cambio es similar: actualizar el values.yaml con la nueva tag, correr helm upgrade, y verificar que los pods arrancan con la versión correcta antes de cortar el tráfico del deployment viejo.

Lo que NO debes hacer

Confiar solo en la autenticación de la API. CVE-2026-58138 es pre-auth por diseño, pero incluso si el deployment requiere autenticación, una credencial filtrada abre el mismo vector. La defensa en profundidad aplica: autenticación + sandboxing + aislamiento de red.

Confiar en que el evaluador GraalVM está restringido por defecto. La mayoría de deployments que aparecen en incidentes similares usan la configuración permisiva por defecto. Hay que verificar siempre el archivo de configuración y no asumir nada.

Asumir que la versión del package manager (Debian, Ubuntu, RHEL) ya trae el fix. Conductor no suele estar en los repos oficiales; si se instaló desde un tarball o una imagen Docker vieja, la instancia sigue vulnerable hasta que se demuestre lo contrario.

Resumen ejecutivo

CVE-2026-58138 es una falla pre-auth de RCE en Orkes Conductor que está siendo explotada activamente desde julio de 2026. La versión vulnerable es cualquier build desde 3.21.21 hasta 3.30.1; el fix está en 3.30.2, publicado el 3 de junio de 2026. Si el deployment tiene Conductor expuesto a Internet, se puede asumir que está comprometido hasta que se demuestre lo contrario con evidencia: revisar logs por definiciones sospechosas, bloquear el acceso externo a /api/workflow/*, restringir las opciones de GraalVM en el config, y planificar el upgrade esta semana. El exploit público (EDB-52633) convierte esto en algo que cualquier script kiddie puede correr, no solo atacantes sofisticados.

Preguntas frecuentes

¿Por qué Alerta Sysadmin: Vulnerabilidad Crítica en Orkes Conductor bajo Explotación Activa es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Alerta Sysadmin: Vulnerabilidad Crítica en?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Alerta Sysadmin: Vulnerabilidad Crítica en?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Alerta Sysadmin: Vulnerabilidad Crítica en y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Alerta Sysadmin: Vulnerabilidad Crítica en?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.