CVE-2026-58138: Orkes Conductor'da kimlik doğrulaması gerektirmeyen RCE sahadaki saldırılarda kullanılıyor

Saldırganlar yamasız Conductor örneklerini yokluyor

Mikroservisleri ve giderek artan şekilde yapay zekâ ajanlarını koordine etmek için kullanılan açık kaynak workflow orkestrasyon motoru Orkes Conductor, CVSS v3.1 temel puanı 9.8 olan kritik bir uzaktan kod yürütme açığı olan CVE-2026-58138 üzerinden aktif olarak hedefleniyor. Empirical Security'nin analizine dayanan bir dev.to yazısına göre firma, telemetrisinde 21 Ağustos 2026'da istismar faaliyeti gözlemledi; SecurityWeek ise Fortinet'in 8–9 Eylül arasında yaklaşık 1.300 istismar girişimini engellediğini bildirdi. Bu girişimlerde kod yürütmenin başarılı olduğu kamuya açık şekilde doğrulanmadı; yani gözlemlenen faaliyet tarama ile gerçek istismar teslimatının bir karışımı olabilir.

Saldırı nasıl işliyor

Sorunun kökü, Conductor'ın Workflow API'sinin varsayılan olarak kimlik doğrulaması istememesi. Açta bir örnete ağ üzerinden erişimi olan saldırgan, kötü niyetli bir JavaScript veya Python ifadesi gömen bir INLINE, LAMBDA, DO_WHILE veya SWITCH görevi içeren bir workflow tanımı kaydedebilir ve ardından workflow'u başlatabilir.

Bu ifadeler, HostAccess.ALL veya allowAllAccess(true) ile geniş host erişimiyle yapılandırılmış bir GraalVM bağlamında değerlendirilir. Bu, ifade içinden Java reflection ve alt süreç (subprocess) oluşturmaya izin verir; bu da Conductor sürecinin ayrıcalıklarıyla çalışan işletim sistemi komut yürütmeye karşılık gelir. Empirical Security'ye göre varsayılan container imajında bu süreç çoğu zaman root olarak çalışır.

Kullanıcı etkileşimi gerekmez ve Conductor arayüzünde görünür bir belirti olmayabilir; yani açıkta olan bir örneğin işletmecileri, ekranda bariz bir şey değişmeden saldırıya uğrayabilir.

Etkilenen sürümler ve düzeltmeler

Güvenlik açığı, Conductor OSS'nin 3.21.21 sürümünden 3.30.2 hariç 3.30.2'ye kadar olan sürümlerini etkiliyor. İstismar, iki koşul birlikte sağlandığında başarılı olur: örnek savunmasız bir sürüm çalıştırıyorsa ve Workflow API, önünde kimlik doğrulaması veya ağ kontrolleri olmadan erişilebilse.

Düzeltmeleri ifade etmek basit: 3.30.2 veya üzeri bir sürüme güncelleyin, Workflow API'sini iç ağlara kısıtlayın ve workflow kaydı ile yürütmesi için kimlik doğrulaması ve yetkilendirmeyi zorunlu kılın.

Savunmacılar nelere bakmalı

Empirical Security'nin göstergeleri dört alana odaklanıyor:

• Meşru kullanıcılar tarafından oluşturulmamış workflow tanımları; özellikle ifadelerinde Java reflection, Runtime, ProcessBuilder veya subprocess çağrılarına referans veren INLINE, LAMBDA, DO_WHILE veya SWITCH görevleri.
• Workflow API'sine yapılan harici POST istekleri, ardından Conductor host'undan giden DNS çözümlemesi ve veri çekme.
• Endpoint veya EDR telemetrisinde görülen, Java veya Conductor süreci tarafından başlatılan shell, Python yorumlayıcısı veya curl gibi alt süreçler.
• SaaS veya bulut ortamlarında workflow tanımlarını, yürütme geçmişini, secret referanslarını ve bağlı API'leri kapsayan denetim günlükleri.

Davranış, MITRE ATT&CK T1190 (Exploit Public-Facing Application) ve T1059 (Command and Scripting Interpreter) ile eşleşiyor. Pratik bir boşluk: örneğin önünde bir API ağ geçidi veya denetim günlüğü kaydı yoksa, kötü niyetli tanımı kimin kaydettiğini belirlemek zor.

Önerilen yanıt

Kısmak için analiz, 3.30.2 veya sonrasına güncelleme, API'ye dış erişimi engelleme, ele geçirilen örnekleri izole etme ve Conductor'ın erişebildiği kimlik bilgileri ve secret'ları döndürmeyi öneriyor. Gerçek ele geçirilme olduğunu doğrulamak, kötü niyetli workflow başlatmalarını Conductor alt süreçleri veya komut çıktılarıyla ilişkilendirmek ve ardından herhangi bir secret erişimini, bağlantı değişikliklerini veya komuta-kontrol faaliyetini ikincil kanıtlarla teyit etmek anlamına geliyor.

Kaç ortamın başarılı şekilde istismar edildiği, hangi komutların çalıştırıldığı, aktörlerin kim olduğu, engellenen yaklaşık 1.300 girişimin kaç tekil kaynak ve hedeften geldiği ve sorunun Orkes Cloud sürümlerine ile türev dağıtımlara ne kadar uzandığı dahil olmak üzere birkaç soru hâlâ açık.

Neden önemli

Conductor, kurumsal envanterlerde nadiren standart bir varlık olarak kabul edilir; oysa mikroservis ve yapay zekâ ajanı topolojilerinin merkezinde ayrıcalıklı bir konum işgal eder. Servis kimlik bilgilerini tutar ve veri depolarına, iç servislere ve ajanlara bağlanır; bu yüzden tek bir ön-kimlik doğrulaması RCE'si, motorun dokunabildiği her şeyle orantılı yatay hareket imkânı sağlar. Örnekler çoğu zaman güvenlik ekiplerinin takip etmediği ürünlerin, container'ların ve geliştirici yönetimindeki ortamların içinde geldiğinden, birçok kuruluş savunmasız sürümleri bilmeksizin çalıştırıyor olabilir. Bu, SBOM'lar, container envanterleri ve maruziyet incelemeleriyle keşfi en az yamalama kadar acil hale getiriyor ve güncellemeyi ayrıcalık azaltma, ağ kısıtlamaları ve Conductor'ın tuttuğu secret'ların azaltılmasıyla eşleştirmeyi savunuyor.