Le API Conductor di Orkes esposte trasformano gli script dei workflow in percorsi d’attacco con privilegi di root

Le implementazioni di Orkes Conductor sono prese di mira attraverso una vulnerabilità critica di code injection che consente ad attaccanti non autenticati di eseguire comandi del sistema operativo inviando definizioni di workflow malevole.

Tracciata come CVE-2026-58138, la vulnerabilità interessa Conductor 3.21.21 e tutte le versioni successive precedenti alla 3.30.2. La versione 3.30.2 contiene la correzione. Il rischio è maggiore per le installazioni esposte a Internet che utilizzano la configurazione open source predefinita, poiché l’API dei workflow potrebbe essere accessibile senza autenticazione.

Non si tratta più di una debolezza teorica. Empirical Security ha rilevato lo sfruttamento il 21 agosto, mentre Fortinet ha bloccato circa 1.300 tentativi tra l’8 e il 9 settembre e ha diramato un avviso di attacco in corso relativo al protrarsi dell’attività.

Versioni di Conductor interessate e condizioni di distribuzione

Orkes Conductor è un framework open source per il coordinamento di microservizi, workflow applicativi e agenti di intelligenza artificiale. Il componente vulnerabile elabora espressioni JavaScript e Python incorporate nelle definizioni dei workflow.

L’intervallo di versioni interessato è il seguente:

• Interessate: Conductor dalla 3.21.21 a tutte le versioni precedenti alla 3.30.2
• Corretta: Conductor 3.30.2
• Debolezza: CWE-94, Improper Control of Generation of Code
• Tipo di attacco: esecuzione di codice da remoto senza autenticazione
• Privilegi richiesti: nessuno
• Interazione dell’utente: nessuna descritta
• Superficie d’attacco: l’API dei workflow di Conductor

Secondo quanto riportato, la configurazione predefinita del server open source non impone l’autenticazione sull’API interessata. Di conseguenza, un attaccante in grado di raggiungere quell’interfaccia può inviare un workflow ostile senza dover prima ottenere credenziali.

SecurityWeek ha riferito che la vulnerabilità è stata corretta a giugno. Il codice di exploit proof-of-concept è comparso all’inizio di agosto, seguito poco dopo da attacchi reali. Non sono noti il numero preciso delle organizzazioni compromesse né la distribuzione geografica dell’attività.

Non è stato identificato alcun threat actor.

L’accesso all’host tramite GraalVM compromette la sandbox degli script

Conductor supporta task che contengono script e che valutano JavaScript o Python inline. Le versioni vulnerabili creano valutatori GraalVM con impostazioni altamente permissive, tra cui:

• HostAccess.ALL
• allowAllAccess(true)

Queste opzioni consentono alle espressioni valutate di interagire ampiamente con l’ambiente host Java. Anziché rimanere confinate in un contesto di scripting limitato, le espressioni controllate dall’attaccante possono raggiungere le funzionalità Java, utilizzare la reflection o avviare subprocessi.

Le descrizioni tecniche individuano quattro tipi di task Conductor sfruttabili:

• INLINE
• LAMBDA
• DO_WHILE
• SWITCH

L’attacco inizia con una richiesta all’API dei workflow esposta. L’attaccante invia una definizione di workflow contenente un’espressione malevola in uno di questi tipi di task e ne avvia l’esecuzione. GraalVM valuta l’espressione con accesso illimitato all’host, consentendole di invocare comandi del sistema operativo attraverso il runtime Java.

Con la configurazione predefinita vulnerabile, questa procedura può richiedere una sola richiesta API non autenticata. Non risultano necessari né social engineering, né un account esistente, né l’interazione di un amministratore.

I comandi eseguiti ereditano i privilegi del processo Conductor. Questo dettaglio modifica sostanzialmente la portata dei potenziali danni: secondo le informazioni disponibili, i servizi Conductor vengono spesso eseguiti come root. In questi ambienti, lo sfruttamento può passare direttamente dall’iniezione di codice a livello applicativo al controllo completo dell’host sottostante.

Lo sfruttamento ha accelerato dopo la pubblicazione del codice proof-of-concept

Le prove di attacchi in corso sono emerse poco dopo la pubblicazione delle istruzioni per lo sfruttamento. Empirical Security ha osservato attività di exploitation il 21 agosto. Successivamente, Fortinet ha registrato circa 1.300 tentativi bloccati nell’arco dei due giorni tra l’8 e il 9 settembre.

Il successivo avviso di attacco in corso di Fortinet indica che le attività di scansione e sfruttamento non si sono concluse con quel picco di traffico. Le informazioni disponibili non rivelano i payload inviati in ogni tentativo, l’infrastruttura utilizzata dagli attaccanti né se l’attività sia riconducibile a un’unica operazione o a diverse campagne non correlate.

CVE-2026-58138 ha ottenuto un punteggio CVSS v3.1 di 9,8, Critical, con il vettore:

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

La valutazione riflette l’accessibilità tramite rete, la bassa complessità dell’attacco, l’assenza di requisiti di autenticazione e di interazione dell’utente, nonché l’elevato impatto potenziale su riservatezza, integrità e disponibilità.

Una valutazione CVSS v4.0 fornita da una CNA e realizzata da VulnCheck assegna un punteggio di 9,3, Critical, utilizzando:

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 scheda NVD mostra la valutazione v4.0 di VulnCheck, ma non ha fornito un proprio punteggio CVSS v4.0. NVD ha pubblicato la scheda il 30 giugno 2026, l’ha modificata l’ultima volta il 14 luglio 2026 e la indica come “Non pianificata” per ulteriori arricchimenti.

Al 18 settembre 2026, le informazioni disponibili in NVD non mostrano CVE-2026-58138 nel catalogo Known Exploited Vulnerabilities di CISA. Non è quindi disponibile alcuna scadenza per la remediation indicata da CISA. L’assenza di una scadenza nel catalogo KEV non modifica le prove dirette del fatto che gli attaccanti stiano già sfruttando la vulnerabilità.

Una richiesta eseguita con successo può esporre gli host e i servizi connessi

Il risultato immediato dello sfruttamento è l’esecuzione arbitraria di comandi con l’account del servizio Conductor. Se l’account dispone di privilegi elevati, l’attaccante può assumere il controllo completo del server.

Tra le risorse potenzialmente esposte rientrano le credenziali applicative, le variabili d’ambiente, i dati dei workflow, i segreti API e i file di configurazione archiviati sull’host. Gli attaccanti possono inoltre modificare o eliminare workflow, installare meccanismi di persistenza, effettuare connessioni in uscita non autorizzate o modificare i file dell’applicazione.

Il rischio può estendersi oltre il server Conductor. Poiché la piattaforma coordina microservizi e altri workflow, un’istanza compromessa potrebbe contenere credenziali o disporre dell’accesso di rete a sistemi downstream. Le implementazioni che orchestrano agenti di intelligenza artificiale potrebbero esporre analogamente i workflow degli agenti, i relativi segreti o i servizi connessi.

Non tutti i tentativi di sfruttamento comportano necessariamente la compromissione completa dell’infrastruttura. L’impatto effettivo dipende dai privilegi del sistema operativo, dalla segmentazione di rete, dai segreti disponibili e dall’accesso di Conductor agli altri servizi. Le istanze eseguite come root e dotate di ampia connettività interna rappresentano lo scenario più grave.

Non sono stati divulgati indicatori specifici della campagna, indirizzi IP malevoli, hash di file o stringhe di comando. I difensori devono quindi basarsi sulle evidenze comportamentali e sull’audit dei workflow, anziché su un elenco fisso di indicatori.

Prima l’aggiornamento, poi l’analisi dell’esposizione pregressa

Gli amministratori devono eseguire l’aggiornamento a Conductor 3.30.2 o versioni successive. Limitare l’accesso alla rete può ridurre l’esposizione, ma non elimina il comportamento di valutazione vulnerabile dalle versioni precedenti.

Conductor non dovrebbe essere accessibile direttamente da Internet, salvo in presenza di un requisito operativo documentato. Le organizzazioni dovrebbero collocare il servizio dietro un firewall o un gateway controllato e applicare autenticazione e autorizzazione alle funzioni di gestione dei workflow.

I team di sicurezza dovrebbero esaminare i workflow creati o modificati di recente alla ricerca di JavaScript o Python inattesi, prestando particolare attenzione ai task INLINE, LAMBDA, DO_WHILE e SWITCH. I contenuti degli script che raggiungono classi Java, utilizzano la reflection o tentano di creare subprocessi richiedono un’indagine immediata.

Il monitoraggio a livello host dovrebbe cercare:

• Shell o interpreti di comandi avviati dal processo Conductor o dal processo Java
• Processi Java figlio inattesi
• Creazione anomala di subprocessi durante l’esecuzione dei workflow
• Modifiche non autorizzate a workflow o file dell’applicazione
• Nuovi meccanismi di persistenza o task pianificati
• Accessi a credenziali e variabili d’ambiente
• Connessioni di rete in uscita non giustificate
• Attività eseguite attraverso l’account del servizio Conductor

Qualsiasi istanza interessata che sia stata raggiungibile da una rete non attendibile deve essere considerata potenzialmente compromessa, anche dopo l’aggiornamento. L’update blocca la vulnerabilità nota, ma non può rimuovere la persistenza né annullare i comandi già eseguiti.

Prima di ricostruire o ripulire i sistemi, chi interviene nell’incident response dovrebbe conservare i log pertinenti relativi ad API, workflow, applicazioni, processi, autenticazione e rete. Dovrebbe inoltre ruotare i segreti accessibili al processo Conductor e verificare l’eventuale presenza di accessi non autorizzati ai servizi downstream.

Non è stato divulgato alcun workaround separato da parte del vendor. Per le installazioni esposte, l’aggiornamento e una valutazione retrospettiva della compromissione rappresentano le principali azioni difensive.