Les API Orkes Conductor exposées transforment les scripts de workflow en vecteurs d’attaque au niveau root

Les déploiements Orkes Conductor sont ciblés par une faille critique d’injection de code qui permet à des attaquants non authentifiés d’exécuter des commandes du système d’exploitation en soumettant des définitions de workflow malveillantes.

Référencée sous le nom de CVE-2026-58138, la vulnérabilité affecte Conductor 3.21.21 ainsi que les versions ultérieures antérieures à la 3.30.2. La version 3.30.2 corrige le problème. Les installations accessibles depuis Internet qui utilisent la configuration open source par défaut sont les plus exposées, car l’API des workflows peut être accessible sans authentification.

Il ne s’agit plus d’une faiblesse théorique. Empirical Security a détecté une exploitation le 21 août, tandis que Fortinet a bloqué environ 1 300 tentatives entre le 8 et le 9 septembre et publié une alerte de propagation signalant la poursuite de l’activité.

Versions de Conductor concernées et conditions de déploiement

Orkes Conductor est un framework open source destiné à orchestrer des microservices, des workflows applicatifs et des agents d’IA. Le composant vulnérable traite les expressions JavaScript et Python intégrées aux définitions de workflow.

La plage de versions concernée est la suivante :

• Versions concernées : Conductor 3.21.21 et toutes les versions antérieures à la 3.30.2
• Version corrigée : Conductor 3.30.2
• Faiblesse : CWE-94, Improper Control of Generation of Code
• Type d’attaque : Exécution de code à distance sans authentification
• Privilèges requis : Aucun
• Interaction utilisateur : Aucune décrite
• Surface d’attaque : L’API des workflows Conductor

D’après les informations disponibles, la configuration par défaut du serveur open source n’impose pas d’authentification sur l’API concernée. Un attaquant capable d’atteindre cette interface peut donc soumettre un workflow malveillant sans devoir obtenir de justificatifs au préalable.

SecurityWeek a indiqué que la faille avait été corrigée en juin. Du code d’exploitation de preuve de concept est apparu début août, rapidement suivi par des attaques réelles. Le nombre exact d’organisations compromises et la répartition géographique de l’activité ne sont pas connus.

Aucun acteur malveillant n’a été identifié.

L’accès à l’hôte via GraalVM brise la sandbox des scripts

Conductor prend en charge les tâches contenant des scripts qui évaluent du JavaScript ou du Python intégré. Les versions vulnérables créent des évaluateurs GraalVM avec des paramètres extrêmement permissifs, notamment :

• HostAccess.ALL
• allowAllAccess(true)

Ces options permettent aux expressions évaluées d’interagir largement avec l’environnement hôte Java. Au lieu de rester confinée à un contexte de script limité, une charge contrôlée par l’attaquant peut accéder aux fonctionnalités Java, utiliser la réflexion ou lancer des sous-processus.

Les descriptions techniques identifient quatre types de tâches Conductor exploitables :

• INLINE
• LAMBDA
• DO_WHILE
• SWITCH

L’attaque commence par une requête adressée à l’API des workflows exposée. L’attaquant fournit une définition de workflow contenant une expression malveillante dans l’un de ces types de tâches, puis déclenche l’exécution du workflow. GraalVM évalue l’expression avec un accès illimité à l’hôte, ce qui lui permet d’invoquer des commandes du système d’exploitation via l’environnement d’exécution Java.

Avec la configuration par défaut vulnérable, une seule requête API non authentifiée peut suffire. Rien n’indique qu’une ingénierie sociale, un compte existant ou une intervention d’administrateur soit nécessaire.

Les commandes exécutées héritent des privilèges du processus Conductor. Ce point modifie considérablement l’ampleur des dommages potentiels : d’après les informations disponibles, les services Conductor s’exécutent fréquemment avec les privilèges de root. Dans ces environnements, l’exploitation peut faire passer directement d’une injection de code au niveau applicatif à une prise de contrôle complète de l’hôte sous-jacent.

L’exploitation s’est accélérée après la publication du code de preuve de concept

Des attaques actives ont été observées peu après la publication des instructions d’exploitation. Empirical Security a détecté une exploitation le 21 août. Fortinet a ensuite recensé environ 1 300 tentatives bloquées sur les deux jours des 8 et 9 septembre.

L’alerte de propagation publiée par Fortinet indique que les opérations de balayage et d’exploitation ne se sont pas arrêtées après cette vague de trafic. Les informations disponibles ne précisent ni les charges utiles transmises lors de chaque tentative, ni l’infrastructure utilisée par les attaquants, ni si l’activité relève d’une seule opération ou de plusieurs campagnes sans lien entre elles.

CVE-2026-58138 affiche un score CVSS v3.1 de 9,8, Critique, avec le vecteur suivant :

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

Cette évaluation tient compte de l’accessibilité via le réseau, de la faible complexité de l’attaque, de l’absence d’authentification requise et d’interaction utilisateur, ainsi que de l’impact potentiellement élevé sur la confidentialité, l’intégrité et la disponibilité.

Une évaluation CVSS v4.0 fournie par une CNA et réalisée par VulnCheck lui attribue la note 9,3, Critique, avec le vecteur suivant :

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

La fiche NVD affiche l’évaluation v4.0 de VulnCheck, mais n’a pas fourni son propre score CVSS v4.0. La NVD a publié la fiche le 30 juin 2026, l’a modifiée pour la dernière fois le 14 juillet 2026 et lui attribue le statut « Not Scheduled » pour tout enrichissement supplémentaire.

Au 18 septembre 2026, les informations disponibles dans la NVD n’indiquent pas que CVE-2026-58138 figure dans le catalogue des vulnérabilités exploitées connues de la CISA. Aucun délai de remédiation fixé par la CISA n’est donc disponible. L’absence de délai KEV référencé ne change rien aux preuves directes montrant que des attaquants exploitent déjà la faille.

Une requête réussie peut exposer les hôtes et les services connectés

L’exploitation permet immédiatement d’exécuter des commandes arbitraires avec le compte de service Conductor. Si ce compte dispose de privilèges élevés, un attaquant peut prendre le contrôle complet du serveur.

Les actifs potentiellement exposés comprennent les identifiants applicatifs, les variables d’environnement, les données des workflows, les secrets d’API et les fichiers de configuration stockés sur l’hôte. Les attaquants peuvent également modifier ou supprimer des workflows, installer des mécanismes de persistance, établir des connexions sortantes non autorisées ou modifier des fichiers applicatifs.

Le risque peut dépasser le serveur Conductor. Comme la plateforme orchestre des microservices et d’autres workflows, une instance compromise peut disposer d’identifiants ou d’un accès réseau à des systèmes en aval. Les déploiements qui orchestrent des agents d’IA peuvent de la même manière exposer les workflows des agents, les secrets associés ou les services connectés.

Toute tentative d’exploitation n’entraîne pas nécessairement une compromission complète de l’infrastructure. L’impact réel dépend des privilèges du système d’exploitation, de la segmentation réseau, des secrets disponibles et des accès de Conductor aux autres services. Les instances exécutées avec les privilèges de root et bénéficiant d’une connectivité interne étendue représentent le cas le plus grave.

Aucun indicateur propre à la campagne, aucune adresse IP malveillante, aucune empreinte de fichier ni chaîne de commande n’a été communiqué. Les défenseurs doivent donc s’appuyer sur les éléments comportementaux et l’audit des workflows plutôt que sur une liste figée d’indicateurs.

Mettre à niveau en priorité, puis rechercher d’éventuelles compromissions antérieures

Les administrateurs doivent effectuer la mise à niveau vers Conductor 3.30.2 ou une version ultérieure. Restreindre l’accès réseau peut réduire l’exposition, mais cela ne supprime pas le comportement d’évaluation vulnérable des anciennes versions.

Conductor ne doit pas être directement accessible depuis Internet, sauf exigence opérationnelle documentée. Les organisations doivent placer le service derrière un pare-feu ou une passerelle contrôlée et imposer une authentification ainsi qu’une autorisation pour les fonctions de gestion des workflows.

Les équipes de sécurité doivent examiner les workflows nouvellement créés ou modifiés à la recherche de JavaScript ou de Python inattendus, en accordant une attention particulière aux tâches INLINE, LAMBDA, DO_WHILE et SWITCH. Tout script qui accède à des classes Java, utilise la réflexion ou tente de créer des sous-processus doit faire l’objet d’une investigation immédiate.

La supervision au niveau de l’hôte doit rechercher les éléments suivants :

• Shells ou interpréteurs de commandes lancés par le processus Conductor ou Java
• Processus enfants Java inattendus
• Création inhabituelle de sous-processus lors de l’exécution des workflows
• Modifications non autorisées des workflows ou des fichiers applicatifs
• Nouveaux mécanismes de persistance ou tâches planifiées
• Accès aux identifiants et aux variables d’environnement
• Connexions réseau sortantes inexpliquées
• Activité effectuée via le compte de service Conductor

Toute instance concernée qui était accessible depuis un réseau non fiable doit être considérée comme potentiellement compromise, même après la mise à niveau. La mise à jour bloque la vulnérabilité connue, mais ne peut ni supprimer une persistance déjà installée ni annuler les commandes déjà exécutées.

Les équipes d’intervention doivent préserver les journaux pertinents des API, des workflows, des applications, des processus, de l’authentification et du réseau avant de reconstruire ou de nettoyer les systèmes. Elles doivent également renouveler les secrets accessibles au processus Conductor et vérifier les services en aval afin de détecter tout accès non autorisé.

Aucune mesure de contournement distincte fournie par l’éditeur n’a été communiquée. Pour les installations exposées, la mise à niveau et l’évaluation rétrospective d’une éventuelle compromission constituent les principales mesures défensives.