この記事の内容
2026年8月5日、Lidor Ben Shitrit 氏率いる Novee の研究者たちが Black Hat USA で研究を発表し、四つのエンタープライズ Java プラットフォームにわたる十二件の脆弱性を明らかにしました。その中には、ログインを一切必要とせずにサーバー上でコードを実行できる二つの深刻な攻撃チェーンが含まれており、ワークフロープラットフォームの Bonita BPM と、オープンソースの ERP である Apache OFBiz に存在します。経営者にとっての実務上の教訓はこうです。社内向けだから守られていると思い込んでいるシステムも、外部に露出していてパッチが適用されていなければ、ブラウザからのリクエスト二回で到達されてしまいます。本当の防御は、ネットワーク境界を信頼することではなく、運用しているものの棚卸しとパッチ適用の習慣から始まります。
研究者たちが実際に発見したこと
この研究は、ひとつの派手なバグの上に成り立っているわけではありません。ミドルウェアによくある小さなミスを組み合わせることで構築されています。URL の解析方法の違い、リクエスト処理層での不完全な保護、ソースコードにハードコードされた暗号鍵、そして安全でないテンプレート評価です。個々にはどれも危険には見えません。だからこそコードレビューをすり抜け、優先度の低い問題として扱われてしまうのです。しかしこれらを連鎖させると、匿名の訪問者からサーバー上でのコマンド実行に至る完全な経路が出来上がります。十二件の脆弱性のうち、四件は認証前に機能し、一件は実行サンドボックス内部の分離を破ります。
BadBonita チェーン:三つの弱点がひとつの完全な侵害を生む
最初のチェーンは Bonita BPM バージョン 10.4.3 に影響します。その起点は、互いに結びついた三つの弱点から成る認証回避です。..; 表記を使ったパストラバーサル、完全なパスではなく部分文字列で照合するセキュリティフィルター、そして内部のリクエスト転送ロジックです。その結果、外部の誰にも見えるはずのなかった内部 API にリクエストが届いてしまいます。この API は信頼できない XML を受け取り、それをそのまま XStream ライブラリに渡してデシリアライズさせます。そしてよく知られた Commons Collections のガジェットチェーンを経て、最終的にサーバー上で Groovy コマンドが実行されます。
これらの手順のいずれにも、漏えいしたパスワードやソーシャルエンジニアリング、事前のアクセス権は必要ないことに注意してください。攻撃者に必要なのは、システムにネットワーク経由でアクセスできることだけです。
OFBiz:公開リポジトリに掲載された署名鍵
二つ目の問題は CVE-2026-31986 として追跡され、深刻度は「重大」と評価されています。シングルサインオンが有効になっている Apache OFBiz バージョン 24.09.05 に影響します。問題は、デフォルトの署名鍵が一般公開されているソースコードの中にあることです。多くのインストール環境ではデフォルト設定がそのまま残されているため、攻撃者は管理者アカウントの名義で有効な SSO トークンを偽造できます。その後、リクエストは java、process、import といった語をブロックしようとする拒否リストを通過しますが、このリストは大文字と小文字を区別し、特定のパターンしか確認していなかったため、一文字の大文字・小文字を変えるか、自動インポートされる別のクラス名を使うだけで通り抜けられます。最終的な結果として、SSO を運用しているあらゆる環境で、認証なしの GET リクエスト二回だけでコード実行に到達できます。
なぜこれがあなたに直接関係するのか
どちらも周辺的なツールではないからです。OFBiz は多くの企業が在庫、調達、請求の管理に使っているオープンソースの ERP であり、Bonita は社内の承認や手続きを動かすワークフローエンジンです。この二つの場所に到達した者は、単にデータを読むだけではなく、あなたの業務サイクルのど真ん中に立つことになります。発注書、仕入先の価格、従業員の記録、顧客の履歴です。研究者たちによれば、両ベンダーとも標準的な九十日間の開示期間内に修正版をリリースしました。つまり更新はすでに存在し、責任は今や開発者ではなく、システムを運用する側にあるということです。
市場における本当のギャップは、パッチがないことではなく、棚卸しがないことです。多くの組織は、実際に何を、どのバージョンで、どのドメインで運用しているのかを示す最新の一覧を持っていません。そのため、古いステージング環境のコピーが忘れられたサブドメインに二年間も放置され、誰も考えもしなかった侵入口になってしまうのです。
今週やるべきこと
- システムの棚卸し:運用しているすべてのシステムについて、そのバージョン、インターネットに公開されているかどうか、そして担当者の氏名を記した書面の一覧を作成します。
- Bonita または OFBiz を運用している場合は、ただちに修正版へ更新し、アップグレードの前に Apache の公式セキュリティページを読んでください。
- 製品に同梱されていたデフォルトの暗号鍵や署名鍵をすべて置き換えます。ドキュメントに記載されている値は、どれも秘密ではありません。
- 管理用の入口をオープンなインターネットから遮断し、プライベートネットワークまたは短いアドレス許可リスト経由でアクセスするようにします。
- 古いステージング環境のコピーや使われていないサブドメインを廃止します。これらは最も狙われやすく、最も監視が手薄な標的です。
- アクセスログを有効にし、保管します。ログがなければ、後になって誰かが侵入したのかどうかさえ答えられません。
エンジニアリング上の教訓:社内ネットワークはセキュリティ境界ではない
この研究から得られる最も重要な提言は、社内のルーティングをインターネットと同等の統制で扱うべきだということです。ファイアウォールの内側にあるものはすべて安全だという古い考え方は、実際には破綻しています。認証回避の脆弱性がひとつあるだけで、すべての社内エンドポイントが公開されたものになってしまうからです。ここから三つのエンジニアリング上のルールが導かれ、それらは開発標準に組み込むべきものです。
危険な操作を守るために拒否リストに頼ってはいけません。あるコードパスで式の評価が必要ないのであれば、フィルターしようとするのではなく、完全に取り除いてください。
第二のルールは、システム内部から変更できる設定フラグやユーザー設定に、機密性の高い操作の可否を委ねてはならないということです。第三のルールは、認証フィルターのロジックに部分文字列による照合がないかを監査することです。これはこの種の問題で最も繰り返され、最も悪用されやすいミスだからです。Origami で新しい業務システムを構築する際には、これを標準として適用しています。すべてのエンドポイントで明示的に認可を行い、リクエストがネットワーク上のどこにあるかを根拠とした信頼は一切与えません。
サウジアラビアにおける規制の観点
侵害されたシステムが王国内の個人の個人データを保持している場合、これは純粋に技術的な問題ではなくなります。個人データ保護法(PDPL)は、管理者に対し、そのデータを保護するために必要な措置を講じること、そしてそのプライバシーに影響を及ぼすインシデントを報告することを義務付けています。国家サイバーセキュリティ庁(NCA)は、脆弱性管理、パッチ適用、資産管理を対象とする必須管理策を公開しており、それらはまさにこの攻撃チェーンを食い止められたはずの管理策です。既知で、すでにパッチが提供されている脆弱性を抱えた古いバージョンの製品を運用し続けることは、どのような監査においても弁明が難しい立場です。
シンプルなルール:セキュリティ更新は、インシデントの後に行う緊急作業としてではなく、担当者と期日を定めた毎月の運用上の約束として扱ってください。
出典
- Help Net Security:認証前 RCE チェーンと CVE-2026-31986 の詳細:helpnetsecurity.com
- Apache OFBiz 公式セキュリティページ:ofbiz.apache.org/security.html
- 国家サイバーセキュリティ庁(NCA):管理策と規制フレームワーク:nca.gov.sa
- サウジデータ・AI 庁(SDAIA):個人データ保護法(PDPL):sdaia.gov.sa
よくある質問
自社はこれらの脆弱性の影響を受けますか?
Bonita BPM 10.4.3 以前、またはシングルサインオンを有効にした Apache OFBiz 24.09.05 以前を運用しており、そのシステムにネットワーク経由でアクセスできる場合は、影響を受けます。契約書や引き継ぎ資料に書かれたバージョンではなく、実際に稼働しているバージョンを確認し、修正版にアップグレードしてください。
当社のシステムは社内向けでインターネットには公開していませんが、安全ですか?
必ずしも安全とは言えません。この研究の核心は、認証回避の脆弱性がひとつあるだけで、あらゆる社内エンドポイントが開かれたものになってしまうという点です。ネットワーク上の感染した端末が一台、あるいは漏えいした従業員アカウントがひとつあれば、そこに到達できます。社内システムも同じ水準で保護してください。明示的な認可、デフォルトではない鍵、そして定期的な更新です。
システムベンダーに最低限求めるべきことは何ですか?
次の三点を書面で求めてください。システムが依存しているコンポーネントとそのバージョンの一覧、重大な脆弱性に対する対応期限を定めたセキュリティ更新ポリシー、そして更新が実際に適用されたことを証明する定期報告です。これらの条項はメールのやり取りではなく、サポート・保守契約に盛り込んでください。
オープンソースソフトウェアはクローズドソースより安全性が低いのですか?
いいえ。違いは、オープンソースの脆弱性はパッチとともに公開されるため、自分で確認して対処できるのに対し、クローズドソースの脆弱性はベンダーのスケジュールに左右されるという点です。本当のリスクはどちらの場合も同じで、更新が存在するのに古いバージョンを使い続けることです。オープンソースがより危険になるのは、デフォルトの鍵や設定を出荷時のまま放置した場合だけです。
GoogleでOrigamiをフォロー
Origamiを優先ソースに追加すると、Google検索やトップニュースで私たちの記事が優先的に表示されます。








