攻撃者がBonitaサーバーに1件のWebリクエストを送信すると、誰にも到達されないはずだった内部APIの中に入り込んでしまいます。しかもそのリクエストは認証なしで届きます。
そこから攻撃者はホスト上でコードを実行できます。Bonita BPMは銀行、保険会社、政府機関において融資審査、保険金請求、従業員のオンボーディングを処理しており、その内部インターフェースが見ず知らずの相手に応答してしまうのです。
Noveeの脆弱性研究者たちがこの経路を発見しました。彼らは本日、Black Hat USA 2026において、エンタープライズJavaにおけるプリ認証リモートコード実行に関するブリーフィングでこの内容を発表しました。
今回の監査は4つのエンタープライズJavaプラットフォームを対象としており、サンドボックスエスケープ1件を含む12件の脆弱性が見つかりました。そのうち4件はログイン前の状態でも悪用可能なものでした。
研究者たちは、そのうちの2つの攻撃チェーン、BonitaのものとOFBizのものについて詳しく解説しました。両者は同じパターンをたどっています。ルーティングが、呼び出し元を信頼しきったインターフェースに到達し、そこにある実行シンクがその到達性をコード実行へと変えてしまうのです。
1つのWebアドレスが3つの防御をすり抜ける
Bonita BPM 10.4.3は、パブリックAPIインターフェースと内部APIインターフェースの両方を稼働させています。パブリックインターフェースはセッションとCSRFトークンを要求します。一方、内部インターフェースはベーシック認証を受け付け、受信した内容をそのままXStream(XMLを生きたJavaオブジェクトに変換するライブラリ)に渡してしまいます。
この両者の境界は3つの独立したチェックによって守られていますが、たった1つのWebアドレスでそのすべてを同時に突破できてしまいます。各チェックはそれぞれ独立して動作し、他のチェックが仕事を果たしていることを前提にしているのです。
最初のチェックはパスをある方式で読み取りますが、Tomcatのディスパッチャは別の方式で読み取ります。..;という形式で書かれたパスセグメントは、セキュリティフィルタを通常の名前として通過してしまいます。Tomcatはセミコロンを取り除き、残りの部分をディレクトリツリーを1つ上がるものとして扱い、リクエストを内部インターフェースへとルーティングしてしまいます。
2つ目のチェックは、あらゆる部分文字列に反応するマッチ処理を実行します。パス内に作り込まれたアプリ名は認証フィルタを満たしてしまい、同じ部分文字列がCSRFフィルタも満たしてしまいます。両フィルタとも、マッチした部分文字列の時点で読み取りを止めてしまうのです。
残る1つのチェックは、直接のリクエストは保護する一方で、転送されたリクエストは素通しにしてしまいます。Bonitaはこの保護を1種類のリクエストタイプに対してのみ宣言しており、それ以外は対象外です。内部転送によって到着したリクエストは無傷で通過してしまいます。
これらを連鎖させると、ログインの壁は1件のPOSTリクエストへと折りたたまれてしまいます。攻撃者は認証なしのまま、内部APIの内側に立つことになります。
XStreamがXMLをシェルに変える
XStreamはあらゆる型を受け入れます。攻撃者が用意したXMLはCommons Collectionsのクラスからガジェットチェーンを再構築し、通常の安全性チェックを飛ばすメモリのショートカットを経由させて、コマンドを実行するGroovyの呼び出しに到達します。この一連の処理は、1回のXStream呼び出しの中で、リクエストが完了する前に実行されます。
1つの鍵がOFBizの扉を開ける
Apache OFBiz 24.09.05は、設定ファイルに保存された鍵を使ってシングルサインオントークンに署名しています。この鍵は公開されているソースリポジトリにそのまま含まれています。デフォルト設定のままのすべてのインストール環境では、誰でも読める秘密鍵でトークンに署名していることになります。
この鍵でトークンに署名すれば、OFBizはその中身のクレームをそのまま信頼してしまいます。ユーザーをadminに設定すれば、adminセッションが出来上がります。攻撃者は偽造したトークンによってadmin権限を手にすることになります。
同じ鍵はウィジェットエンジンのコールバックトークンの署名にも使われています。トークンには、レンダリングすべき画面領域の名前を示すフィールドが含まれます。OFBizはトークンからこのフィールドを読み取り、Groovyを評価するテンプレート展開処理に渡してしまいます。
この評価処理が実行されるかどうかは、あるアクセシビリティ設定によって決まります。この設定はadminが切り替えることができます。偽造されたadminがこれを有効にした上で、画面名の代わりにGroovyコマンドを埋め込んだトークンを送信します。
デニーリスト(ブロックリスト)がスクリプトインジェクションの阻止を試みますが、これは小文字のテキストと既知の接頭辞にしかマッチしません。ProcessBuilderの先頭を大文字のPにするだけですり抜けられてしまいます。また、自動インポートされるクラスは接頭辞を必要としないため、これもすり抜けてしまいます。
その結果がCVE-2026-31986で、深刻度は「クリティカル」と評価されています。シングルサインオンを有効にしたすべてのOFBizインストール環境において、認証なしのGETリクエスト2回でコード実行に到達できてしまいます。
スキャナーには何も見えない
それぞれの攻撃チェーンは、単体で見れば無害に見える部品から組み立てられています。迷い込んだURLセグメント、誤ったモードに設定されたマッチ処理、設定ファイルに欠けている1行、デフォルトの鍵、大文字小文字を区別しない正規表現。
シグネチャベースのスキャナーには、マッチさせるものが何もありません。汎用的なモデルがコードを読んでも、せいぜい「デシリアライゼーションの可能性あり」とフラグを立てる程度です。そのシンクに実際に到達可能であるという証拠は得られないままです。エクスプロイトは、個々の部品がどうつながっているかという点にこそ宿っているのです。
BonitaとOFBizが取った対応
Noveeはすべての発見事項を該当プロジェクトに報告し、公表前に各プロジェクトと協力して対応にあたりました。
「OFBizはこれらの特定の脆弱性に対応した新バージョンをすでにリリースしており、Bonitaも私たちの開示を受けて新バージョンをリリースしました。総じて両ベンダーとも非常に迅速に対応してくれました。特にOFBizは、修正作業の間、常に最新状況を私たちに共有し続けてくれました。両ベンダーとも、標準的な90日間の開示期限内に修正を完了させています」と、Noveeの創業メンバーで脆弱性研究者のLidor Ben Shitrit氏はHelp Net Securityに語りました。
残る2つのプラットフォームについては、名前が明かされていません。
「残る2つのプラットフォームも、大規模なエンタープライズ向けプラットフォームと見なされているものです。どちらのベンダーからも、最近のところ特に更新情報は受け取っていません。ただ、今回取り上げているBonitaとOFBizという2つのプラットフォームが、最も深刻な影響を及ぼすものであったことはお伝えできます」とBen Shitrit氏は述べています。
Noveeは攻撃者視点のAIシステムを構築し、こうしたアプリケーションを標的として分析しています。
「今回実施した作業内容を振り返ると、リサーチの大部分は人間の手によって行われたものであり、そこに私たちのNovee Agentによるピンポイントの支援が加わる形でした。Noveeに組み込まれたAIエージェントは常に学習を重ね、知見を拡張し、こうしたリサーチを通じて成果を着実に向上させています。こうした実際の発見が、私たちの製品を継続的に磨き上げ、精度を高めることにつながっています」とBen Shitrit氏は語りました。
自社のスタックで確認すべきこと
同じ弱点は、エンタープライズJava全体で繰り返し見られます。Web設定が直接のリクエストは保護する一方で、転送されたリクエストは素通しにしてしまう。フィルタの除外設定が部分文字列だけでマッチしてしまう。
1つの署名鍵が複数の別々の機能を同時に認可してしまう。デニーリストがスクリプト評価エンジンを守っている。設定フラグ1つが、危険なコードへの分岐を開いてしまう。
これらはいずれも監査に値する項目です。内部ルーティングは、あたかもインターネット上に公開されているかのように堅牢化すべきです。安全でない実行プリミティブは取り除くべきです。レンダリングの切り替えフラグが、eval呼び出しのゲートになるようなことは決してあってはなりません。
両方の攻撃チェーンに含まれる部品は、それぞれ単体で見れば正当化できるものばかりです。しかし、それらが組み合わさった瞬間、見ず知らずの他人のコードが実行されてしまうのです。
翻訳元: https://www.helpnetsecurity.com/2026/08/05/pre-auth-rce-java-bonita-ofbiz-cve-2026-31986/
