Критический RCE в Orkes Conductor: побег из GraalVM-песочницы эксплуатируется

Коротко о главном

В оркестраторе рабочих процессов Orkes Conductor нашли критическую уязвимость CVE-2026-58138 с баллом CVSS 9.8: неаутентифицированный злоумышленник может отправить в API запуска workflow inline-определение с вредоносным JavaScript- или Python-выражением, сбежать из GraalVM-песочницы и выполнить произвольные команды операционной системы с правами процесса Conductor. Уязвимы версии с 3.21.21 по 3.30.1 включительно; исправление — обновление до 3.30.2. Уже опубликован рабочий PoC, а Fortinet за одни сутки заблокировала около 1300 попыток эксплуатации — это повод для внепланового патча, а не для планового обновления к следующему релизу.

Для команд, которые строят конвейеры автоматизации и микросервисную оркестрацию, вывод прямой: движок workflow, принимающий определения задач по сети без аутентификации, — это полноценная поверхность атаки. Мы в YuSMP закрываем такие риски в рамках услуг по информационной безопасности и аудита кода приложения — ниже разбираем, что именно сломалось и как реагировать.

Ключевой нюанс — экспозиция. Дефект опасен именно там, где Conductor Workflow API доступен из недоверенной сети: тогда атака не требует ни входа, ни участия пользователя. Если ваш экземпляр закрыт периметром и сегментацией, риск ниже, но патчиться всё равно нужно — публичный эксплойт снимает планку входа для атакующего до минимума. Тем, кто разворачивает Conductor в облаке, стоит связать реакцию с ревизией сетевого доступа и DevOps-практик.

Что такое Orkes Conductor и почему это важно

Conductor — популярный движок оркестрации рабочих процессов, изначально созданный в Netflix и развиваемый компанией Orkes. Он описывает бизнес-логику как граф задач (workflow) и координирует их выполнение между микросервисами: запускает шаги, ждёт результатов, ветвит логику, обрабатывает ошибки и ретраи. По сути это «дирижёр» распределённой системы, через который проходят обращения ко множеству сервисов и данных. Компрометация такого узла даёт атакующему точку с широким доступом к внутренней инфраструктуре.

Чтобы описывать условия и вычисления прямо в определении workflow, Conductor поддерживает inline-выражения в задачах типов INLINE, LAMBDA, DO_WHILE и SWITCH. Эти выражения вычисляются встроенным движком скриптов на базе GraalVM — среды исполнения, которая умеет запускать JavaScript и Python внутри JVM. Идея в том, чтобы дать разработчику гибкость лёгких вычислений без отдельного сервиса. Именно этот механизм оценки пользовательских выражений и оказался небезопасным.

Как устроена уязвимость

По данным advisory VulnCheck и Empirical Security, корень проблемы в том, что Conductor создаёт GraalVM-контекст с настройкой HostAccess.ALL (эквивалент allowAllAccess(true)). Эта опция полностью отключает изоляцию: гостевой скрипт получает беспрепятственный доступ к хостовым Java-классам и методам. В результате «песочница» становится фикцией — из JavaScript- или Python-выражения можно через Java-рефлексию дотянуться до системных вызовов и запустить подпроцесс.

Публичный PoC демонстрирует цепочку: вредоносное inline-выражение внутри определения workflow обращается к хостовым классам, добирается до механизма запуска процессов и выполняет команду ОС. Критично, что API запуска workflow принимает и вычисляет такое определение до проверки аутентификации — поэтому атака возможна без каких-либо учётных данных. Вектор — сетевой, сложность низкая, привилегии и участие пользователя не требуются: отсюда и максимально высокий балл. VulnCheck приводит вектор CVSS v4 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, что соответствует критическому уровню.

Эксплуатация в реальном мире

Это не теоретический риск. Исправление вышло ещё в июне 2026 года в версии 3.30.2, но в начале августа появился публичный proof-of-concept, а примерно с 21 августа зафиксированы попытки эксплуатации в реальных атаках. FortiGuard Labs выпустила Outbreak Alert по этой уязвимости; по данным телеметрии Fortinet, только за сутки 8–9 сентября было заблокировано около 1300 попыток эксплуатации. Мишень атакующих — публично доступные, необновлённые экземпляры Conductor с открытым Workflow API.

Схема массовой эксплуатации типична для такого класса: атакующий сканирует интернет на предмет открытых Conductor API, регистрирует и запускает workflow с вредоносным выражением и получает выполнение команд на хосте. Наличие готового эксплойта означает, что фаза «ручной разработки атаки» пройдена и в дело вступают автоматизированные сканеры. Для владельцев уязвимых версий это переводит инцидент из категории «возможно» в категорию «вопрос времени».

Что это значит для команд разработки

Главный урок шире одного CVE: движок скриптов, вычисляющий пользовательские выражения, — это не граница безопасности сам по себе. Настройка HostAccess.ALL удобна на этапе прототипа, но в проде она означает, что любое выражение равно исполнению кода на хосте. Как только система принимает извне данные, которые где-то интерпретируются как код (SQL, шаблоны, скрипт-выражения, сериализованные объекты), вокруг этого места нужны настоящие границы — минимум привилегий у процесса, контейнерная изоляция, seccomp/AppArmor и сетевая сегментация.

Второй урок — про экспозицию и порядок проверок. Инструмент, доступный по сети и вычисляющий ввод до аутентификации, превращает внутреннюю утилиту в открытую дверь. Для оркестраторов и внутренних платформ это распространённая ошибка: команды исходят из того, что «API дёргают только наши сервисы», и не закрывают транспорт. Практический вывод — инвентаризация всех сервисов, которые слушают сеть, с явной проверкой, требуют ли они аутентификации и что именно происходит с недоверенным вводом до неё.

Что делать прямо сейчас

Немедленно обновите Orkes Conductor до версии 3.30.2 или новее — это устраняет корневую причину, ограничивая права GraalVM-эвалуатора и вводя проверку аутентификации до обработки определения workflow. Если обновиться сразу нельзя, закройте Workflow API от недоверенной сети: уберите его из публичного доступа, поставьте перед ним аутентифицирующий прокси и ограничьте доступ доверенной подсетью.

Дальше — проверьте логи на подозрительные запуски workflow с inline-выражениями и аномальные дочерние процессы у сервиса Conductor за период до патча: раз есть публичный PoC и подтверждённые атаки, стоит исходить из того, что сканирование уже идёт. Убедитесь, что процесс работает под непривилегированным пользователем в изолированном контейнере с урезанными capabilities — чтобы даже успешный побег упирался в следующий слой защиты. И заложите в процесс регулярную проверку зависимостей и версий инфраструктурных компонентов: инцидент этого класса не последний.

Часто задаваемые вопросы

Насколько это серьёзно? Максимально высоко: CVSS 9.8, удалённое выполнение кода без аутентификации при сетевой экспозиции Workflow API. Есть публичный PoC и подтверждённые атаки в реальном мире.

Какие версии затронуты и где исправление? Уязвимы версии Orkes Conductor с 3.21.21 по 3.30.1 включительно. Исправление вышло в 3.30.2 — обновление до неё или новее закрывает дефект.

Мы держим Conductor во внутренней сети без публичного доступа — нас это касается? Риск ниже, но не нулевой: атака возможна от любого, кто дотянется до Workflow API, включая скомпрометированный внутренний хост. Патч всё равно обязателен, а доступ к API стоит закрыть аутентификацией и сегментацией.

Была ли эксплуатация? Да. С конца августа 2026 года зафиксированы попытки в реальных атаках; Fortinet сообщила о порядка 1300 заблокированных попыток за сутки 8–9 сентября. Уязвимость в CISA KEV на момент публикации не заявлена, но это не снижает срочности с учётом активной эксплуатации.

Источники

VulnCheck — Orkes Conductor 3.21.21 < 3.30.2 Unauthenticated RCE via GraalVM Script Evaluators (CVE-2026-58138), advisory с техническими деталями и вектором CVSS.

SecurityWeek — Critical Orkes Conductor Vulnerability Exploited in Attacks, 2026 (данные об эксплуатации и телеметрии Fortinet).

FortiGuard Labs — Orkes Conductor Evaluator Remote Code Execution, Outbreak Alert.