Orkes Conductor: Kritische Pre-Auth-RCE CVE-2026-58138 wird aktiv ausgenutzt
CVE-2026-58138 erlaubt in Orkes Conductor die Ausführung beliebiger Betriebssystembefehle ohne Anmeldung, über Inline-Workflow-Definitionen am Workflow-API-Endpunkt. CVSS v3.1 9.8, behoben in 3.30.2. FortiGuard meldet aktive Angriffsversuche, öffentlicher Exploit-Code ist verfügbar. Was Admins jetzt prüfen sollten.
Für die Workflow-Orchestrierungsplattform Orkes Conductor gibt es eine kritische Schwachstelle, die ohne jede Anmeldung zur vollständigen Codeausführung auf dem Server führt. Die Lücke trägt die Kennung CVE-2026-58138, wird mit einem CVSS-v3.1-Wert von 9.8 und einem CVSS-v4-Wert von 9.3 bewertet und betrifft laut NVD die Versionen von 3.21.21 bis vor 3.30.2. Behoben ist sie in Conductor 3.30.2 und neuer. Wer eine dieser Versionen betreibt und die Workflow-API aus dem Internet erreichbar hält, sollte heute handeln und nicht auf das nächste Wartungsfenster warten.
Der Grund für die Dringlichkeit ist nicht der CVSS-Wert allein, sondern die Angriffslage. FortiGuard meldet in einem Outbreak Alert vom 15. September 2026 aktive Ausnutzungsversuche in der eigenen Telemetrie, dazu ist öffentlicher Exploit-Code verfügbar. Wer keinen Orkes Conductor einsetzt, ist von dieser konkreten Lücke nicht betroffen. Das Tückische ist allerdings, dass Conductor häufig als eingebetteter Baustein in Plattformen und Eigenentwicklungen steckt. Der erste Schritt ist deshalb eine nüchterne Inventarisierung, nicht Panik.
Was ist passiert?
CVE-2026-58138 erlaubt entfernten Angreifern, beliebige Betriebssystembefehle auszuführen. Dafür schicken sie noch vor der Authentifizierung eine sogenannte Inline-Workflow-Definition an den Workflow-API-Endpunkt. In dieser Definition stecken bösartige JavaScript- oder Python-Ausdrücke, die der Server anschließend auswertet.
Möglich wird das durch ungesandboxte GraalVM-Evaluatoren, die mit HostAccess.ALL beziehungsweise allowAllAccess(true) konfiguriert sind. Damit darf der eingebettete Skriptcode ungebremst auf die Java-Laufzeitumgebung zugreifen. Betroffen sind laut Beschreibung die Task-Typen INLINE, LAMBDA, DO_WHILE und SWITCH. Die eigentliche Befehlsausführung erfolgt dann per Java-Reflection oder über direkte Subprozess-Aufrufe.
Praktisch heißt das: Ein einzelner HTTP-Request an einen nicht geschützten Endpunkt genügt, um Code mit den Rechten des Conductor-Prozesses auszuführen. Es braucht keinen gültigen Benutzer, kein gestohlenes Token und keine vorherige Fußfassung im Netz.
Wer ist betroffen?
Betroffen sind Installationen von Orkes Conductor in den Versionen ab 3.21.21 bis einschließlich aller Stände unterhalb von 3.30.2. Wer bereits auf 3.30.2 oder neuer steht, ist gegen diese konkrete Lücke abgesichert. Wer gar keinen Conductor betreibt, ist von CVE-2026-58138 nicht betroffen.
Die entscheidende Einschränkung lautet: Viele Unternehmen wissen nicht, dass sie Conductor überhaupt im Einsatz haben. Die Plattform wird gern als Orchestrierungsschicht in größere Produkte, Datenpipelines und interne Eigenentwicklungen eingebaut. Ein Blick in die Liste der bewusst beschafften Software reicht deshalb nicht. Sinnvoller ist eine Suche nach laufenden Java-Prozessen, Container-Images und offenen Ports auf den typischen Conductor-Endpunkten.
| Merkmal | Angabe |
|---|---|
| Kennung | CVE-2026-58138 |
| Produkt | Orkes Conductor (Workflow-Orchestrierung) |
| Verwundbare Versionen | 3.21.21 bis vor 3.30.2 |
| Behoben in | 3.30.2 und neuer |
| CVSS v3.1 | 9.8 |
| CVSS v4 | 9.3 |
| Angriffsart | Remote Code Execution ohne Authentifizierung |
| Betroffene Task-Typen | INLINE, LAMBDA, DO_WHILE, SWITCH |
| Exploit-Lage | öffentlicher PoC verfügbar, aktive Angriffsversuche gemeldet |
Wie kritisch ist das?
Die Einstufung als kritisch ist hier nicht nur eine Zahl im Advisory. FortiGuard beschreibt in seinem Outbreak Alert vom 15. September 2026 aktive Angriffsversuche gegen verwundbare Orkes-Conductor-Instanzen. Mit Stand 9. September 2026 hatte Fortinet innerhalb von 24 Stunden 1.290 Angriffsversuche blockiert, was einem Anstieg der Tagesaktivität um 132 Prozent entsprach. Zwischen dem 2. und dem 9. September 2026 waren es zusammen knapp 7.000 blockierte Versuche.
Die Angriffsaktivität stammte überwiegend aus Deutschland, Hongkong, Indonesien, den Vereinigten Arabischen Emiraten und Indien. Diese Zahl bitte korrekt lesen: Sie beschreibt die Herkunft der Angriffsquellen, nicht die Anzahl deutscher Opfer. Ein Rückschluss auf besonders viele betroffene Unternehmen in Deutschland lässt sich daraus nicht ziehen.
Zur Exploit-Lage: Öffentlicher Proof-of-Concept-Code ist verfügbar, darunter ein funktionierender Exploit gegen Conductor v3.23.0. Am 9. August 2026 wurde zudem ein öffentlicher unauthentifizierter RCE-Exploit als EDB-52633 bei Exploit-DB veröffentlicht. Fortinet stuft internetexponierte Instanzen ausdrücklich als hohe Priorität für die Behebung ein, weil die Lücke aus der Ferne und ohne Anmeldung ausnutzbar ist.
Ergänzend berichtet TheHackerNews am 19. September 2026 über weitere Telemetrie. Previdian meldet drei Ausnutzungsversuche gegen eigene Honeypots seit dem 24. Juli 2026, ausgehend von zwei eindeutigen IP-Adressen aus Frankreich und den USA. Empirical Security führt Ausnutzung in freier Wildbahn zuletzt für den 21. August 2026. Diese Zahlen sind klein, bestätigen aber unabhängig, dass die Lücke tatsächlich angegriffen wird und nicht nur theoretisch ausnutzbar ist.
Was sollten Admins jetzt tun?
- Zuerst klären, ob Orkes Conductor überhaupt im Einsatz ist. Auch eingebettete Verwendungen in Plattformen, Datenpipelines und Eigenentwicklungen zählen. Ein reiner Blick in die Beschaffungsliste reicht nicht.
- Versionsstand jeder gefundenen Instanz ermitteln. Alles ab 3.21.21 und unterhalb von 3.30.2 gilt als verwundbar.
- Auf Conductor 3.30.2 oder neuer aktualisieren. Das ist die offizielle Gegenmaßnahme und die einzige, die die Ursache beseitigt.
- Sofort prüfen, ob die Workflow-API aus dem Internet erreichbar ist, und diese Exposition schließen. Internetexponierte Instanzen haben laut Fortinet die höchste Priorität.
- Wenn sofortiges Patchen nicht möglich ist: externen Zugriff auf die Conductor-Workflow-API-Endpunkte einschränken und die Instanzen hinter geeignete Netzwerk-Zugriffskontrollen stellen.
- Konfiguration der GraalVM-Evaluatoren prüfen, insbesondere auf
HostAccess.ALLundallowAllAccess(true). - Logs auf verdächtige Workflow-Einreichungen durchsuchen, vor allem auf Definitionen mit INLINE-, LAMBDA-, DO_WHILE- oder SWITCH-Tasks aus unerwarteten Quellen.
- Auf unerwartete Prozessstarts und ungewöhnliche Befehlsausführung auf den Conductor-Hosts überwachen.
- Bei Verdacht auf Kompromittierung prüfen, mit welchen Rechten der Conductor-Dienst läuft und welche weiteren Systeme von dort aus erreichbar sind.
- Zugangsdaten, Tokens und Secrets, die der Conductor-Prozess lesen kann, in die Bewertung einbeziehen und im Zweifel rotieren.
Einordnung für Unternehmen
Orkes Conductor ist keine Randkomponente am Netzübergang, sondern eine Orchestrierungsschicht, die typischerweise tief in der internen Automatisierung sitzt. Genau das macht eine Remote Code Execution an dieser Stelle so unangenehm. Ein Angreifer landet nicht in einer isolierten Webanwendung, sondern mitten in der Schicht, die Aufträge an andere Systeme verteilt, und zwar mit den Rechten des Conductor-Prozesses. In vielen Umgebungen bedeutet das Zugriff auf Datenbanken, Objektspeicher, interne APIs und hinterlegte Zugangsdaten.
Für kleine und mittlere Unternehmen ist die praktische Lehre vor allem eine Inventarfrage. Orchestrierungswerkzeuge kommen selten über eine bewusste Kaufentscheidung ins Haus, sondern über Dienstleister, Plattformprodukte und gewachsene Eigenentwicklungen. Wer nicht weiß, welche Automatisierungsbausteine laufen, kann weder Patchstände bewerten noch Angriffsflächen schließen.
Die allgemeine Regel gilt unabhängig vom konkreten Produkt: Unauthentifizierte API-Endpunkte von Automatisierungsplattformen gehören nicht ins offene Internet. Wo ein Zugriff von außen fachlich nötig ist, gehört er hinter Authentifizierung, Reverse Proxy und klare Netzwerkregeln, und nicht als offener Port auf die öffentliche Adresse. Das kostet im Aufbau wenig und verhindert genau die Klasse von Vorfällen, die hier beobachtet wird.
Passende Anleitungen auf S-EDV
- Langflow CVE-2026-5027: Angriffe auf eine Workflow-Plattform: vergleichbarer Fall, bei dem eine Automatisierungsplattform über einen offenen Endpunkt angegriffen wurde.
- Kestra mit Docker Compose betreiben: zeigt, wie eine Workflow-Orchestrierung sauber aufgesetzt und abgegrenzt wird.
- Temporal als Workflow-Orchestrierung mit Docker: Alternative zu Conductor samt Hinweisen zum Betrieb im internen Netz.
