// 5 CRITICAL · 2 ZERO-DAY · 10 CVE · 5 EXPLOIT NELLE ULTIME 24H
Orkes Conductor affronta exploitation in-the-wild per CVE-2026-58138, RCE con CVSS 9.8. La patch esisteva dal 3 giugno, ma senza advisory: migliaia di installazioni

Il 21 agosto 2026 Empirical Security ha rilevato i primi attacchi in-the-wild contro Orkes Conductor, workflow engine open-source con oltre 32.000 stelle su GitHub e più di 3.000 clienti enterprise. La sorpresa: la patch correttiva, versione 3.30.2, era già disponibile dal 3 giugno. Nessun advisory, nessun CVE allegato, nessuna etichetta di sicurezza nei release notes. Il risultato è una finestra di esposizione di quasi tre mesi in cui il fix tecnicamente esisteva ma operativamente non esisteva.

Punti chiave
  • CVE-2026-58138 è una vulnerabilità RCE unauthenticated in Orkes Conductor con punteggio CVSS 9.8, classificata CRITICAL dal NVD
  • Il meccanismo sfrutta GraalVM script evaluators configurati con HostAccess.ALL, che permettono reflection da JavaScript verso java.lang.Runtime.exec()
  • Empirical Security ha confermato exploitation attiva dal 21 agosto; Fortinet ha bloccato circa 1.300 tentativi tra l'8 e il 9 settembre
  • La patch completa è arrivata il 3 giugno 2026 in versione 3.30.2, ma senza security label; le versioni 3.30.0 e 3.30.1 contenevano solo una blocklist parziale

Come funziona l'attacco: dalla registrazione del workflow all'esecuzione

L'attacco si articola in due POST non autenticati. Il primo colpisce /api/metadata/workflow e registra un workflow contenente un task INLINE malevolo. Il secondo chiama /api/workflow/<name> per eseguirlo. La vulnerabilità risiede nel modo in cui Conductor gestisce gli script embedded.

Secondo Empirical Security, citato da SecurityWeek, "An INLINE task (and LAMBDA, DO_WHILE, and SWITCH tasks) evaluates a user-supplied JavaScript or Python expression, and Conductor builds that evaluator on a GraalVM context configured with HostAccess.ALL". Questa configurazione disabilita la sandbox GraalVM e permette al codice ospite di accedere via reflection a qualsiasi classe Java disponibile nel classpath, inclusa java.lang.Runtime. Da lì, l'esecuzione di comandi sul sistema operativo è diretta.

Il processo Conductor, nella container image predefinita, gira spesso con privilegi di root. Questo eleva l'impatto da esecuzione remota a compromissione completa del sistema ospite. La combinazione di autenticazione assente di default e script evaluators non sandboxati rende l'exploitation completamente automatizzabile e scalabile.

La timeline del silenzio: patch senza advisory, exploitation senza preavviso

La cronologia rivela un pattern ricorrente nel software infrastrutturale. Il 3 giugno 2026 il team di sviluppo rilascia la versione 3.30.2 con una modifica descritta nei release notes come "restricting GraalVM JavaScript further". Nessuna parola su sicurezza, nessun CVE riferito. Il 30 giugno il CVE-2026-58138 viene pubblicato formalmente. All'inizio di agosto il codice proof-of-concept diventa pubblico. Solo allora la vulnerabilità diventa "scopribile" per la maggior parte delle organizzazioni.

Empirical Security ha formulato il problema con chiarezza: "patching only helps the instances you can find". La mancanza di un advisory strutturato ha impedito ai programmi di vulnerability management di flaggare l'aggiornamento come prioritario. Nessun plugin scanner — né Tenable né Qualys, secondo la stessa fonte — ha segnalato la versione vulnerabile in tempo utile. Il software workflow engine, per sua natura load-bearing ma non security-critical negli inventari aziendali, è svanito dal perimetro di attenzione.

"No login stands in the way, because the open-source server enforces no authentication by default and leaves its workflow API open. A single unauthenticated POST registers a workflow with a hostile INLINE task and starts it" — Empirical Security

Dai dati di Fortinet alla conferma della campagna

La telemetry di rete ha trasformato ipotesi in evidenza. Fortinet ha documentato circa 1.300 tentativi di exploitation concentrati tra l'8 e il 9 settembre 2026, seguiti da un outbreak alert nella settimana corrente. I ricercatori di Empirical Security avevano già osservato attacchi dal 21 agosto, con una settimana di anticipo rispetto al picco rilevato dai firewall.

I dati convergono su un'unica conclusione: gli attaccanti non hanno sfruttato la vulnerabilità quando è diventata patchabile, ma quando è diventata pubblicizzabile. Il PoC ha funto da trigger di discovery, non il CVE. Questo ritardo tra disponibilità tecnica e consapevolezza operativa è ciò che Empirical Security definisce "the discovery gap in practice": un fenomeno dove la visibilità strumentale fallisce su componenti che non rientrano nei tradizionali radar di sicurezza.

Cosa fare adesso

  • Identificare tutte le istanze Conductor nell'infrastruttura, inclusi deployment containerizzati e ambienti di sviluppo non catalogati, con focus sulle versioni comprese tra 3.21.21 e 3.30.1
  • Aggiornare prioritariamente alla versione 3.30.2, unica release con fix completo: le precedenti 3.30.0 e 3.30.1 limitano solo parzialmente la superficie di attacco con blocklist incomplete
  • Abilitare l'autenticazione sul workflow API dove assente, dato che il server open-source non la impone di default e l'endpoint di registrazione workflow resta esposto
  • Monitorare i log per POST a /api/metadata/workflow seguiti da esecuzioni di workflow con task type INLINE, LAMBDA, DO_WHILE o SWITCH in origini non autorizzate

Perché CVE-2026-58138 è un segnale di sistema

Orkes Conductor non è un prodotto di nicchia. È usato da LinkedIn, Twilio e Quest Diagnostics, tra gli oltre 3.000 enterprise citati dal vendor. La sua invisibilità nel perimetro di sicurezza non deriva da scarsa diffusione, ma da una categorizzazione sbagliata: workflow engine è infrastructure, non application, e come tale tende a sfuggire ai cicli di patch management tradizionali.

La lezione di CVE-2026-58138 supera il singolo prodotto. Quando una patch correttiva viene rilasciata senza advisory, il sistema di intelligence della comunità difensiva si spezza. Gli scanner non rilevano, gli asset management non aggiornano, i SOC non correlano. L'exploitation diventa quasi inevitabile non per mancanza di difese tecniche, ma per mancanza di allerta umana. In questo caso specifico, il fix c'era. Mancava solo chi sapesse che esisteva.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. securityweek.com
  2. sherlockforensics.com
  3. exploit-intel.com
  4. thehackerwire.com
  5. cyberstrike.io
  6. nvd.nist.gov
  7. cve.org
  8. research.empiricalsecurity.com
  9. cisa.gov