Offen zugängliche Orkes-Conductor-APIs machen Workflow-Skripte zu Angriffspfaden mit Root-Rechten

Orkes-Conductor-Installationen werden über eine kritische Code-Injection-Schwachstelle angegriffen, durch die nicht authentifizierte Angreifer Betriebssystembefehle ausführen können, indem sie manipulierte Workflow-Definitionen übermitteln.

Die als CVE-2026-58138 erfasste Schwachstelle betrifft Conductor 3.21.21 sowie alle nachfolgenden Versionen vor 3.30.2. Version 3.30.2 enthält die Fehlerbehebung. Internetexponierte Installationen mit der standardmäßigen Open-Source-Konfiguration sind besonders gefährdet, da die Workflow-API möglicherweise ohne Authentifizierung erreichbar ist.

Diese Schwachstelle ist nicht länger nur theoretischer Natur. Empirical Security stellte am 21. August eine Ausnutzung fest. Fortinet blockierte zwischen dem 8. und 9. September rund 1.300 Angriffsversuche und warnte in einem Ausbruchsalarm vor anhaltenden Aktivitäten.

Betroffene Conductor-Versionen und Voraussetzungen für die Ausnutzung

Orkes Conductor ist ein Open-Source-Framework zur Koordination von Microservices, Anwendungs-Workflows und AI-Agenten. Die verwundbare Komponente verarbeitet JavaScript- und Python-Ausdrücke, die in Workflow-Definitionen eingebettet sind.

Betroffen ist folgender Versionsbereich:

• Betroffen: Conductor 3.21.21 bis zu allen Versionen vor 3.30.2
• Fehlerbehebung: Conductor 3.30.2
• Schwachstelle: CWE-94, Improper Control of Generation of Code
• Angriffsart: Nicht authentifizierte Remote-Code-Ausführung
• Erforderliche Berechtigungen: Keine
• Erforderliche Benutzerinteraktion: Keine beschrieben
• Angriffsfläche: Die Conductor-Workflow-API

Die standardmäßige Open-Source-Serverkonfiguration erzwingt für die betreffende API offenbar keine Authentifizierung. Ein Angreifer, der diese Schnittstelle erreichen kann, kann daher einen manipulierten Workflow übermitteln, ohne zuvor Zugangsdaten zu benötigen.

SecurityWeek berichtete, dass die Schwachstelle im Juni behoben wurde. Anfang August tauchte Proof-of-Concept-Exploit-Code auf; kurz darauf folgten Angriffe in freier Wildbahn. Wie viele Organisationen genau kompromittiert wurden und wie sich die Aktivitäten geografisch verteilen, ist nicht bekannt.

Es wurde kein Bedrohungsakteur identifiziert.

GraalVM-Zugriff auf das Hostsystem durchbricht die Skript-Sandbox

Conductor unterstützt Aufgaben, die Inline-JavaScript oder Python auswerten. Die verwundbaren Versionen erzeugen GraalVM-Auswerter mit äußerst weitreichenden Berechtigungen, darunter:

• HostAccess.ALL
• allowAllAccess(true)

Diese Optionen ermöglichen es ausgewerteten Ausdrücken, umfassend mit der Java-Hostumgebung zu interagieren. Statt auf einen eingeschränkten Skriptkontext begrenzt zu bleiben, kann von Angreifern kontrollierter Code Java-Funktionen erreichen, Reflection verwenden oder Subprozesse starten.

In den technischen Beschreibungen werden vier ausnutzbare Conductor-Aufgabentypen genannt:

• INLINE
• LAMBDA
• DO_WHILE
• SWITCH

Ein Angriff beginnt mit einer Anfrage an die offengelegte Workflow-API. Der Angreifer übermittelt eine Workflow-Definition, die in einem dieser Aufgabentypen einen schädlichen Ausdruck enthält, und bringt den Workflow anschließend zur Ausführung. GraalVM wertet den Ausdruck mit uneingeschränktem Hostzugriff aus, sodass er über die Java-Laufzeit Betriebssystembefehle aufrufen kann.

In der verwundbaren Standardkonfiguration kann dafür bereits eine einzige nicht authentifizierte API-Anfrage ausreichen. Es gibt keine Hinweise darauf, dass Social Engineering, ein bestehendes Konto oder eine Interaktion durch einen Administrator erforderlich wären.

Die ausgeführten Befehle übernehmen die Berechtigungen des Conductor-Prozesses. Dieses Detail erhöht das potenzielle Schadensausmaß erheblich: Den verfügbaren Berichten zufolge laufen Conductor-Dienste häufig als root. In solchen Umgebungen kann ein Angreifer durch die Ausnutzung direkt von der Code-Injection auf Anwendungsebene die vollständige Kontrolle über das zugrunde liegende Hostsystem erlangen.

Ausnutzung nahm nach Veröffentlichung von Proof-of-Concept-Code zu

Kurz nachdem Anleitungen zur Ausnutzung öffentlich verfügbar wurden, gab es Hinweise auf aktive Angriffe. Empirical Security beobachtete am 21. August eine Ausnutzung. Fortinet registrierte später im Zeitraum vom 8. bis 9. September rund 1.300 blockierte Angriffsversuche.

Der anschließende Ausbruchsalarm von Fortinet deutet darauf hin, dass Scans und Ausnutzungsversuche nach dieser Welle nicht beendet waren. Die verfügbaren Informationen geben weder Aufschluss über die in allen Versuchen übermittelten Payloads noch über die von den Angreifern verwendete Infrastruktur oder darüber, ob die Aktivitäten auf eine einzige Operation oder mehrere voneinander unabhängige Kampagnen zurückgehen.

CVE-2026-58138 hat einen CVSS-v3.1-Wert von 9,8, Kritisch, mit folgendem Vektor:

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

Diese Bewertung berücksichtigt die Erreichbarkeit über das Netzwerk, die geringe Angriffskomplexität, die fehlende Authentifizierung, die fehlende Benutzerinteraktion sowie die erheblichen potenziellen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.

Eine von einer CNA bereitgestellte CVSS-v4.0-Bewertung von VulnCheck stuft die Schwachstelle mit 9,3, Kritisch ein. Verwendet wird dabei:

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

Der NVD-Eintrag zeigt die v4.0-Bewertung von VulnCheck an, enthält jedoch keine eigene CVSS-v4.0-Bewertung. NVD veröffentlichte den Eintrag am 30. Juni 2026, änderte ihn zuletzt am 14. Juli 2026 und kennzeichnet ihn für eine weitere Anreicherung mit „Not Scheduled“.

Am 18. September 2026 ist CVE-2026-58138 den verfügbaren NVD-Informationen zufolge nicht im CISA-Katalog der Known Exploited Vulnerabilities aufgeführt. Daher liegt keine CISA-Frist für Abhilfemaßnahmen vor. Das Fehlen einer KEV-Frist ändert nichts an den direkten Belegen dafür, dass Angreifer die Schwachstelle bereits ausnutzen.

Eine erfolgreiche Anfrage kann Hosts und verbundene Dienste offenlegen

Das unmittelbare Ergebnis der Ausnutzung ist die Ausführung beliebiger Befehle unter dem Dienstkonto von Conductor. Verfügt dieses Konto über weitreichende Berechtigungen, kann ein Angreifer die vollständige Kontrolle über den Server übernehmen.

Zu den potenziell offengelegten Ressourcen gehören Zugangsdaten für Anwendungen, Umgebungsvariablen, Workflow-Daten, API-Secrets und auf dem Host gespeicherte Konfigurationsdateien. Angreifer können außerdem Workflows ändern oder löschen, Persistenzmechanismen installieren, nicht autorisierte ausgehende Verbindungen herstellen oder Anwendungsdateien manipulieren.

Das Risiko kann über den Conductor-Server hinausgehen. Da die Plattform Microservices und andere Workflows koordiniert, kann eine kompromittierte Instanz über Zugangsdaten oder Netzwerkzugriff auf nachgelagerte Systeme verfügen. Installationen, die AI-Agenten orchestrieren, können auf ähnliche Weise Agenten-Workflows, zugehörige Secrets oder verbundene Dienste offenlegen.

Nicht jeder Ausnutzungsversuch führt zwangsläufig zu einer vollständigen Kompromittierung der Infrastruktur. Die tatsächlichen Auswirkungen hängen von den Berechtigungen auf Betriebssystemebene, der Netzwerksegmentierung, den verfügbaren Secrets und dem Zugriff von Conductor auf andere Dienste ab. Instanzen, die als root mit weitreichender interner Konnektivität ausgeführt werden, stellen den schwerwiegendsten Fall dar.

Es wurden keine kampagnenspezifischen Indikatoren, schädlichen IP-Adressen, Datei-Hashes oder Befehlszeichenfolgen veröffentlicht. Verteidiger müssen sich daher auf Verhaltensanalysen und die Prüfung von Workflows stützen, statt auf eine feste Liste von Indikatoren.

Zuerst aktualisieren, dann frühere Zugriffe untersuchen

Administratoren sollten auf Conductor 3.30.2 oder höher aktualisieren. Eine Einschränkung des Netzwerkzugriffs kann die Angriffsfläche verringern, beseitigt jedoch nicht das verwundbare Auswertungsverhalten älterer Versionen.

Conductor sollte nicht direkt aus dem öffentlichen Internet erreichbar sein, sofern dafür kein dokumentierter betrieblicher Bedarf besteht. Unternehmen sollten den Dienst hinter einer Firewall oder einem kontrollierten Gateway betreiben und Authentifizierung sowie Autorisierung für Funktionen zur Workflow-Verwaltung erzwingen.

Sicherheitsteams sollten neu erstellte oder geänderte Workflows auf unerwartetes JavaScript oder Python prüfen, insbesondere auf Aufgaben vom Typ INLINE, LAMBDA, DO_WHILE und SWITCH. Skriptinhalte, die Java-Klassen erreichen, Reflection verwenden oder versuchen, Subprozesse zu erstellen, müssen umgehend untersucht werden.

Die Überwachung auf Hostebene sollte auf Folgendes achten:

• Von Conductor oder dem Java-Prozess gestartete Shells oder Befehlsinterpreter
• Unerwartete untergeordnete Java-Prozesse
• Ungewöhnliche Erstellung von Subprozessen während der Workflow-Ausführung
• Nicht autorisierte Änderungen an Workflows oder Anwendungsdateien
• Neue Persistenzmechanismen oder geplante Aufgaben
• Zugriffe auf Zugangsdaten und Umgebungsvariablen
• Nicht erklärte ausgehende Netzwerkverbindungen
• Aktivitäten, die über das Conductor-Dienstkonto ausgeführt werden

Jede betroffene Instanz, die aus einem nicht vertrauenswürdigen Netzwerk erreichbar war, sollte als potenziell kompromittiert betrachtet werden – auch nach der Aktualisierung. Das Update blockiert die bekannte Schwachstelle, kann jedoch keine Persistenzmechanismen entfernen oder bereits ausgeführte Befehle rückgängig machen.

Incident-Responder sollten relevante API-, Workflow-, Anwendungs-, Prozess-, Authentifizierungs- und Netzwerkprotokolle sichern, bevor sie Systeme neu aufsetzen oder bereinigen. Außerdem sollten sie die für den Conductor-Prozess verfügbaren Secrets rotieren und nachgelagerte Dienste auf nicht autorisierte Zugriffe prüfen.

Es wurde keine separate Hersteller-Workaround veröffentlicht. Für exponierte Installationen sind die Aktualisierung und eine nachträgliche Untersuchung auf eine mögliche Kompromittierung die wichtigsten Abwehrmaßnahmen.