【ITニュース解説】Orkes Conductor CVE-2026-58138: Exploitation Activity Observed Against Unauthenticated Workflow RCE

最近、IT業界で注目されているセキュリティの話題として、Orkes Conductorというツールに発見された重大な脆弱性「CVE-2026-58138」がある。この脆弱性は、システムエンジニアを目指す皆さんにとって、ソフトウェアの安全性を理解する上で非常に重要な事例となる。

まず、Orkes Conductorとは何かから説明する。これは、複数の異なるシステムやサービスを連携させ、複雑なビジネスプロセスを自動化するための「ワークフローオーケストレーションツール」である。例えば、あるデータが入力されたら、それを別のシステムで処理し、その結果をさらに別のシステムに通知するといった一連の流れを定義し、実行する役割を担う。多くのマイクロサービスやAIエージェントを活用する現代のシステムにおいて、Conductorのようなツールは中心的な役割を果たすことが多い。

今回見つかった脆弱性「CVE-2026-58138」は、このConductorの非常に重要な部分に存在する。具体的には、Conductorが外部からのワークフロー定義（どのような処理をいつ、どのように実行するかを記述したプログラムのようなもの）を受け付ける「Workflow API」という窓口に問題がある。このAPIがデフォルトで認証なしに公開されている場合、外部の人間が自由にワークフローを登録し、実行できてしまうという点が問題の核心だ。

この脆弱性が特に危険なのは、認証されていない状態で、悪意のあるJavaScriptやPythonのプログラムコードをワークフロー定義に含めて送信できることである。Conductorは、これらのコードを実行するために「GraalVM」という特殊な実行環境を使用している。通常、この種の実行環境は、セキュリティのために外部から与えられたコードがシステム内の重要な機能に直接アクセスできないように制限されている。しかし、今回のConductorの脆弱なバージョンでは、GraalVMの設定が「HostAccess.ALL」または「allowAllAccess(true)」となっており、外部からのコードがサーバーのOSコマンド（例えば、ファイルの中身を見たり、新しいプログラムを起動したりする命令）を自由に実行できてしまう状態だった。

攻撃者は、この仕組みを悪用する。まず、インターネット上に公開されている、認証が不十分なConductor Workflow APIを見つける。次に、INLINE、LAMBDA、DO_WHILE、SWITCHといった特定のタスクタイプの中に、OSコマンドを実行するための悪意のあるJavaScriptやPythonのコードを埋め込んだワークフロー定義を作成し、それをAPIに送信する。認証がないため、この定義は簡単に登録され、そのまま実行されてしまう。結果として、Conductorが動作しているサーバー上で、攻撃者の意図するOSコマンドが実行されてしまうのだ。

この攻撃が成功すると、その影響は非常に大きい。Conductorプロセスが持つ権限で任意のOSコマンドが実行されるため、サーバーのファイルシステムにアクセスされたり、機密情報が盗まれたり、他のシステムへの不正アクセスを許してしまったりする可能性がある。特に、デフォルトのコンテナ環境ではConductorプロセスがシステム内で最も高い権限を持つ「root」ユーザーとして動作していることが多いため、サーバー全体が完全に攻撃者に制御されてしまう危険性がある。このサーバーが企業内の他のマイクロサービスやデータベース、AIエージェントなどと連携している場合、その全てに被害が広がることも考えられる。

実際に、この脆弱性に対する攻撃活動はすでに観測されている。セキュリティ企業が約1,300件もの攻撃試行をブロックしたという報告もあり、多くのシステムが狙われていることがわかる。攻撃が成功したかどうかは公には確認されていないが、攻撃者が活発に脆弱なシステムを探し、攻撃を試みているのは明らかだ。

では、この深刻な脆弱性からシステムを守るためにはどうすればよいのだろうか。最も重要かつ緊急性の高い対策は、Orkes Conductorを最新の安全なバージョンにアップデートすることである。具体的には、バージョン3.21.21から3.30.1までのConductor OSSが脆弱性を持つため、バージョン3.30.2以降に更新する必要がある。これにより、GraalVMの安全な設定が適用され、悪意のあるコードがOSコマンドにアクセスできなくなる。

また、アップデートだけでなく、いくつかの防御策を組み合わせることも非常に重要だ。まず、ConductorのWorkflow APIは外部からアクセスできないように、内部ネットワークのみに制限すべきである。インターネットに直接公開されていると、常に攻撃の標的となる。次に、APIアクセスには必ず認証と認可の仕組みを導入し、権限を持つ正規のユーザーやシステムだけがワークフローを登録・実行できるようにする。さらに、Conductorプロセスを必要最小限の権限で動作させる「最小権限の原則」を守ることも重要だ。デフォルトでroot権限で動作させるのではなく、より低い権限で運用することで、万が一攻撃が成功した場合でも被害を限定できる可能性がある。

システムを管理する側としては、Conductorがどこでどのように使われているかを正確に把握することも欠かせない。自分の組織でConductorが利用されていないか、どのバージョンが使われているか、APIの公開状況はどうか、といった情報を棚卸しする必要がある。そして、不審なワークフロー定義の登録や、Conductorから通常では考えられないような外部への通信、あるいはConductorがJavaやPythonなどの子プロセスを起動しているログがないかなど、異常な活動を常に監視することが求められる。

このConductorの脆弱性は、ソフトウェアを開発・運用する上で、セキュリティがいかに重要であるかを改めて教えてくれる事例だ。システムエンジニアを目指す皆さんは、単に機能を実現するだけでなく、そのシステムの安全性、特に外部からの不正アクセスに対する防御策や、脆弱性情報に常にアンテナを張る習慣を身につけることが極めて重要となるだろう。ソフトウェアは常に最新の状態に保ち、不必要な公開や高すぎる権限を与えない、そして万が一の事態に備えてログを監視するといった基本的なセキュリティプラクティスを徹底することが、デジタル社会を守る上で不可欠である。