Las API expuestas de Orkes Conductor convierten los scripts de workflow en vías de ataque con privilegios de root

Las implementaciones de Orkes Conductor están siendo objeto de ataques mediante una vulnerabilidad crítica de inyección de código que permite a atacantes no autenticados ejecutar comandos del sistema operativo al enviar definiciones de workflows maliciosas.

Registrada como CVE-2026-58138, la vulnerabilidad afecta a Conductor 3.21.21 y a las versiones posteriores anteriores a la 3.30.2. La versión 3.30.2 incluye la corrección. Las instalaciones expuestas a internet que utilizan la configuración predeterminada de código abierto afrontan el mayor riesgo, ya que la API de workflows puede estar accesible sin autenticación.

Ya no se trata de una debilidad teórica. Empirical Security detectó explotación el 21 de agosto, mientras que Fortinet bloqueó aproximadamente 1.300 intentos entre el 8 y el 9 de septiembre y emitió una alerta de brote por la continuidad de la actividad.

Versiones afectadas de Conductor y condiciones de implementación

Orkes Conductor es un framework de código abierto para coordinar microservicios, workflows de aplicaciones y agentes de IA. El componente vulnerable procesa expresiones de JavaScript y Python integradas en las definiciones de workflows.

El intervalo de versiones afectadas es el siguiente:

• Afectadas: Conductor 3.21.21 y todas las versiones anteriores a la 3.30.2
• Corregida: Conductor 3.30.2
• Debilidad: CWE-94, Improper Control of Generation of Code
• Tipo de ataque: Ejecución remota de código sin autenticación
• Privilegios necesarios: Ninguno
• Interacción del usuario: No descrita
• Superficie de ataque: La API de workflows de Conductor

Según los informes, la configuración predeterminada del servidor de código abierto no exige autenticación en la API afectada. Por tanto, un atacante que pueda alcanzar esa interfaz podría enviar un workflow malicioso sin obtener antes credenciales.

SecurityWeek informó de que la vulnerabilidad se corrigió en junio. El código de explotación de prueba de concepto apareció a principios de agosto y poco después comenzaron los ataques reales. No se conoce el número exacto de organizaciones comprometidas ni la distribución geográfica de la actividad.

No se ha identificado a ningún actor de amenazas.

El acceso al host de GraalVM rompe el aislamiento del sandbox de scripts

Conductor admite tareas con scripts que evalúan JavaScript o Python en línea. Las versiones vulnerables crean evaluadores de GraalVM con configuraciones demasiado permisivas, entre ellas:

• HostAccess.ALL
• allowAllAccess(true)

Estas opciones permiten que las expresiones evaluadas interactúen ampliamente con el entorno host de Java. En lugar de permanecer confinadas a un contexto de scripting limitado, las expresiones controladas por el atacante pueden acceder a funciones de Java, utilizar reflection o iniciar subprocesos.

Las descripciones técnicas identifican cuatro tipos de tareas de Conductor explotables:

• INLINE
• LAMBDA
• DO_WHILE
• SWITCH

El ataque comienza con una solicitud a la API de workflows expuesta. El atacante proporciona una definición de workflow que contiene una expresión maliciosa en uno de estos tipos de tareas y, a continuación, provoca la ejecución del workflow. GraalVM evalúa la expresión con acceso sin restricciones al host, lo que permite invocar comandos del sistema operativo mediante el runtime de Java.

Con la configuración predeterminada vulnerable, este proceso puede requerir una sola solicitud a la API sin autenticación. No se ha informado de la necesidad de ingeniería social, de una cuenta existente ni de la intervención de un administrador.

Los comandos resultantes heredan los permisos del proceso de Conductor. Este detalle modifica sustancialmente el daño potencial: según los informes disponibles, los servicios de Conductor suelen ejecutarse como root. En esos entornos, la explotación puede pasar directamente de la inyección de código a nivel de aplicación al control total del host subyacente.

La explotación se aceleró tras la publicación del código de prueba de concepto

Las pruebas de ataques activos aparecieron poco después de que las instrucciones de explotación estuvieran disponibles públicamente. Empirical Security observó explotación el 21 de agosto. Posteriormente, Fortinet registró aproximadamente 1.300 intentos bloqueados durante el periodo de dos días comprendido entre el 8 y el 9 de septiembre.

La alerta de brote emitida después por Fortinet indica que el escaneo y la explotación no terminaron con esa oleada de tráfico. La información disponible no revela los payloads enviados en cada intento, la infraestructura utilizada por los atacantes ni si la actividad corresponde a una sola operación o a varias campañas no relacionadas.

CVE-2026-58138 tiene una puntuación CVSS v3.1 de 9,8, crítica, con el siguiente vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Esta evaluación refleja la accesibilidad a través de la red, la baja complejidad del ataque, la ausencia de requisitos de autenticación y de interacción del usuario, así como el alto impacto potencial sobre la confidencialidad, la integridad y la disponibilidad.

Una evaluación CVSS v4.0 proporcionada por una CNA y realizada por VulnCheck le asigna una puntuación de 9,3, crítica, mediante el siguiente vector:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

El registro de NVD muestra la evaluación v4.0 de VulnCheck, pero NVD no ha proporcionado su propia puntuación CVSS v4.0. NVD publicó el registro el 30 de junio de 2026, lo modificó por última vez el 14 de julio de 2026 y lo marca como «Not Scheduled» para ampliaciones posteriores.

A fecha del 18 de septiembre de 2026, la información disponible en NVD no muestra CVE-2026-58138 en el catálogo Known Exploited Vulnerabilities de CISA. Por tanto, no existe un plazo de corrección establecido por CISA. La ausencia de un plazo en KEV no cambia las pruebas directas de que los atacantes ya están explotando la vulnerabilidad.

Una solicitud maliciosa puede exponer los hosts y los servicios conectados

El resultado inmediato de la explotación es la ejecución arbitraria de comandos con la cuenta de servicio de Conductor. Si esa cuenta tiene privilegios elevados, el atacante podría tomar el control total del servidor.

Entre los activos potencialmente expuestos se encuentran las credenciales de aplicaciones, las variables de entorno, los datos de workflows, los secretos de API y los archivos de configuración almacenados en el host. Los atacantes también pueden modificar o eliminar workflows, instalar mecanismos de persistencia, establecer conexiones salientes no autorizadas o alterar archivos de las aplicaciones.

El riesgo puede extenderse más allá del servidor de Conductor. Como la plataforma coordina microservicios y otros workflows, una instancia comprometida puede disponer de credenciales o acceso de red a sistemas posteriores. Las implementaciones que orquestan agentes de IA también podrían exponer workflows de agentes, secretos asociados o servicios conectados.

No todos los intentos de explotación provocan necesariamente el compromiso total de la infraestructura. El impacto efectivo depende de los permisos del sistema operativo, la segmentación de red, los secretos disponibles y el acceso de Conductor a otros servicios. Las instancias que se ejecutan como root y tienen una conectividad interna amplia representan el escenario más grave.

No se han divulgado indicadores específicos de la campaña, direcciones IP maliciosas, hashes de archivos ni cadenas de comandos. Por tanto, los equipos defensivos deben basarse en las evidencias de comportamiento y en la auditoría de workflows, en lugar de recurrir a una lista fija de indicadores.

Actualizar primero y, después, investigar la exposición previa

Los administradores deben actualizar a Conductor 3.30.2 o una versión posterior. Restringir el acceso de red puede reducir la exposición, pero no elimina el comportamiento vulnerable de evaluación en las versiones antiguas.

Conductor no debería estar accesible directamente desde internet público salvo que exista un requisito operativo documentado. Las organizaciones deben situar el servicio detrás de un firewall o una gateway controlada, y aplicar autenticación y autorización a las funciones de administración de workflows.

Los equipos de seguridad deben revisar los workflows creados o modificados recientemente en busca de JavaScript o Python inesperados, prestando especial atención a las tareas INLINE, LAMBDA, DO_WHILE y SWITCH. El contenido de scripts que acceda a clases de Java, utilice reflection o intente crear subprocesos requiere una investigación inmediata.

La supervisión a nivel de host debe buscar:

• Shells o intérpretes de comandos iniciados por el proceso de Conductor o Java
• Procesos secundarios de Java inesperados
• Creación inusual de subprocesos durante la ejecución de workflows
• Cambios no autorizados en workflows o archivos de aplicaciones
• Nuevos mecanismos de persistencia o tareas programadas
• Acceso a credenciales y variables de entorno
• Conexiones de red salientes sin explicación
• Actividad realizada mediante la cuenta de servicio de Conductor

Cualquier instancia afectada que haya sido accesible desde una red no fiable debe considerarse potencialmente comprometida, incluso después de actualizarla. La actualización bloquea la vulnerabilidad conocida, pero no puede eliminar la persistencia ni revertir los comandos que ya se hayan ejecutado.

Los equipos de respuesta deben conservar los registros relevantes de API, workflows, aplicaciones, procesos, autenticación y red antes de reconstruir o limpiar los sistemas. También deben rotar los secretos disponibles para el proceso de Conductor y revisar los servicios posteriores en busca de accesos no autorizados.

No se ha divulgado ninguna medida de mitigación independiente por parte del proveedor. En las instalaciones expuestas, actualizar y realizar una evaluación retrospectiva del compromiso son las principales medidas defensivas.