Le RCE sans authentification d’Orkes Conductor est exploité dans la nature, trois mois après sa publication
Le 19 septembre 2026, Fortinet a confirmé l’exploitation active de CVE-2026-58138, une exécution de code à distance sans authentification dans Orkes Conductor publiée au NVD dès le 30 juin. Mettez à niveau vers 3.30.2 et traitez toute instance exposée comme compromise.
19 septembre 2026. Fortinet confirme que CVE-2026-58138 est exploité activement dans la nature. 30 juin 2026. La faille était pourtant publiée au NVD — il y a presque trois mois. 9 septembre 2026. L’éditeur a bloqué 1 290 tentatives en 24 heures. Pourquoi c’est important : il s’agit d’une exécution de code à distance sans authentification, notée CVSS 9.8, dans un moteur d’orchestration de workflows — la classe d’outils qui détient les clés de vos automatisations, de vos intégrations et souvent de votre infrastructure.
La faille : un évaluateur GraalVM sans bac à sable
Orkes Conductor est la distribution commerciale du moteur d’orchestration hérité de Netflix Conductor. Son rôle est d’exécuter des workflows — des graphes de tâches qui enchaînent appels d’API, scripts et décisions. C’est précisément cette capacité à exécuter du code qui est la source du problème.
CVE-2026-58138 touche les versions 3.21.21 à 3.30.2 exclue. La description du NVD est sans ambiguïté : un attaquant distant peut soumettre des définitions de workflow en ligne contenant des expressions JavaScript ou Python malveillantes à l’API de workflow, avant toute authentification. Ces expressions sont évaluées par des évaluateurs GraalVM configurés sans restriction — HostAccess.ALL ou allowAllAccess(true) — via quatre types de tâches : INLINE, LAMBDA, DO_WHILE et SWITCH.
La conséquence technique est nette. L’évaluateur n’étant pas cloisonné, l’attaquant échappe à l’environnement de script prévu et invoque des commandes système arbitraires, soit par réflexion Java, soit par des appels de sous-processus directs. Le tout s’exécute avec les privilèges du processus Conductor — souvent un compte de service disposant de droits larges sur les systèmes qu’il orchestre.
Le score reflète cette gravité. Le vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H décrit la faille parfaite du point de vue de l’attaquant : réseau, complexité faible, aucun privilège, aucune interaction utilisateur, et un impact élevé sur confidentialité, intégrité et disponibilité. Le CWE-94 (injection de code) confirme la nature du bug. L’EPSS la place à 9,26 % de probabilité d’exploitation, dans le 95ᵉ centile — le reflet statistique d’une faille déjà ciblée.
Le détail technique qui rend la faille exploitable tient à la configuration de GraalVM, l’environnement d’exécution polyglotte chargé d’évaluer les expressions JavaScript et Python. Deux réglages ouvrent la porte. HostAccess.ALL autorise le script à atteindre n’importe quelle classe et méthode de la machine virtuelle Java hôte ; allowAllAccess(true) désactive les restrictions d’accès à l’hôte. Avec ces deux réglages en place, un simple appel réflexif vers java.lang.Runtime.getRuntime().exec(…) suffit à transformer une expression de workflow en commande système. Le correctif de 3.30.2 n’ajoute donc pas un pare-feu supplémentaire : il rétablit une configuration sûre qui aurait dû être la valeur par défaut.
L’exploitation : un pic, puis une routine
Le décrochage entre la publication (30 juin) et l’exploitation massive (septembre) n’est pas un hasard. Fortinet a publié cette semaine une alerte d’épidémie détaillant ce qu’elle observe. Le 9 septembre 2026, elle a bloqué 1 290 tentatives en 24 heures, soit une hausse de 132 % de l’activité quotidienne. Entre le 2 et le 9 septembre, près de 7 000 tentatives ont été neutralisées.
Les sources de l’activité confirment une campagne distribuée : la majorité des tentatives proviennent d’Allemagne, de Hong Kong, d’Indonésie, des Émirats arabes unis et d’Inde. La télémétrie de Previdian rapporte trois tentatives contre ses honeypots depuis le 24 juillet 2026, depuis deux adresses IP uniques en France et aux États-Unis. Empirical Security affirme avoir détecté une exploitation dans la nature encore le 21 août 2026.
Autrement dit, ce n’est pas un simple proof of concept. C’est une campagne opportuniste qui scanne les instances Conductor exposées et tente d’injecter des définitions de workflow piégées, en espérant qu’une instance tourne encore sur une version vulnérable. Le délai entre la publication et l’exploitation est le temps qu’il a fallu aux attaquants pour écrire, tester et industrialiser l’exploit — et pour que les équipes, elles, n’aient toujours pas patché.
Pourquoi les moteurs de workflow sont une cible
L’intérêt de CVE-2026-58138 dépasse le cas Orkes. Les moteurs d’orchestration occupent une position particulière dans l’entreprise : ils détiennent des identifiants, des jetons d’API, des clés de cloud et des droits d’exécution sur les systèmes qu’ils automatisent. Compromettre le moteur, c’est souvent hériter de tout ce qu’il a le droit de faire — sans avoir à attaquer chaque cible une par une.
C’est la même logique que celle des plates-formes CI/CD, des gestionnaires de secrets ou des outils de gestion de configuration. Ce sont des points de passage : une fois dedans, l’attaquant dispose d’un relais légitime vers le reste du parc. La faille d’Orkes est d’autant plus sévère qu’elle n’exige aucune authentification — pas de vol d’identifiant préalable, pas de phishing, juste une API exposée et une requête forgée.
Le sous-texte est une erreur de configuration récurrente. Le bac à sable GraalVM existe, mais il faut l’activer et le durcir. Par défaut, ou par commodité, des déploiements laissent HostAccess.ALL ouvert, ce qui revient à offrir un shell à quiconque atteint l’endpoint. La correction de 3.30.2 ne consiste pas seulement à boucher un trou : elle rétablit une séparation que la configuration par défaut aurait dû garantir.
Trois mois de latence, deux leçons
L’écart entre le 30 juin — la publication — et le 19 septembre — l’alerte d’exploitation — mérite d’être examiné pour ce qu’il dit de la gestion des correctifs. CVE-2026-58138 n’était pas un secret : elle figurait au NVD avec un score critique, un vecteur trivial et un CWE-94. Une instance Conductor exposée en septembre aurait dû être corrigée depuis près de trois mois.
La première leçon est que la visibilité ne suffit pas. Une faille publiée n’est corrigée que si quelqu’un la relie à un inventaire réel des instances concernées. Les moteurs d’orchestration, souvent déployés hors du périmètre que surveille l’équipe de sécurité, échappent aux scanners d’infrastructure classiques. La seconde leçon est que les attaquants lisent le NVD aussi attentivement que les défenseurs : la courbe décrite par Fortinet — un pic de 132 % de hausse quotidienne en septembre — est le reflet d’un exploit industrialisé, distribué et prêt à être lancé dès qu’une instance vulnérable apparaît.
Que faire : corriger, puis enquêter
La première action est mécanique : mettre à niveau vers Conductor 3.30.2 ou ultérieur. C’est la seule version qui corrige la faille. Tout déploiement qui expose l’API de workflow sur Internet sans cette version doit être considéré comme potentiellement compromis — pas seulement vulnérable.
La détection d’une exploitation passée est plus délicate, car l’attaque se fond dans le trafic légitime des workflows. Les signaux à chercher sont les soumissions de workflows inhabituelles, l’apparition de types de tâches INLINE ou LAMBDA non attendus, et toute exécution de commande inexpliquée depuis le compte du processus Conductor :
# Repérer les soumissions récentes de tâches inline/lambda dans les journaux Conductor
grep -iE 'INLINE|LAMBDA|DO_WHILE|SWITCH' /var/log/conductor/*.log | tail -50
# Croiser avec les process lancés par le compte de service Conductor
ps -eo user,pid,cmd | grep -i conductorSi la mise à jour immédiate est impossible, Fortinet recommande de restreindre l’accès externe aux endpoints de l’API de workflow, de placer les instances derrière des contrôles d’accès réseau et de surveiller les soumissions suspectes. Ces mesures atténuent le risque sans le supprimer : le correctif reste la seule vraie frontière.
Verdict
CVE-2026-58138 est la démonstration que le délai entre une publication NVD et une exploitation active se mesure désormais en semaines, pas en années. Si vous exploitez Orkes Conductor, mettez à niveau vers 3.30.2 immédiatement et partez du principe qu’une instance exposée a été visitée — auditez les workflows et les comptes de service avant de reprendre une activité normale. Si votre moteur d’orchestration n’est pas Conductor, appliquez la même leçon à votre outil : un évaluateur de script non cloisonné derrière une API exposée est un shell en attente, quel que soit le produit.