Apache OFBizの認証不要RCEと認証回避を修正 24.09.08への更新と確認手順

Apache OFBizの24.09.08より前の版には、ログイン画面の処理を悪用して認証なしでサーバー上のコードを実行できるCVE-2026-83542と、アプリ間のログインキーを再利用して別人としてアクセスできるCVE-2026-82907があります。運用担当者は24.09.08へ更新し、公開経路から古いインスタンスを外したうえで、ログイン失敗時の画面表示とアプリ間の遷移を別々に確認してください。管理画面に入るためのパスワードがあるだけでは、ログイン前の処理を狙う前者を防げません。

Apache OFBiz開発者による脆弱性の一括公表は現地時間2026年11月4日（日本時間11月5日）付で、複数の問題に対して24.09.08への更新を案内しています。Apache OFBizのセキュリティ情報は両CVEの修正を同版に記載しています。以下では、同じ更新で直る問題のうち、入口と対応判断が異なるこの2件に絞ります。確認したApacheの告知は、特定の運用環境が侵害されたと報告するものではありません。

認証前の画面描画でコードが実行される経路

CVE-2026-83542では、ログインが失敗した場合にも行われる画面描画が攻撃の入口になります。OFBizのウィジェットは画面の構成を記述する仕組みです。影響版では、細工されたウィジェットXMLを先に配置させ、管理アプリのログイン処理で使う画面の装飾定義の参照先を外部入力で差し替えられます。サーバーがその定義を読み込むと、Groovyの式が隔離されずに評価され、OFBizを動かすプロセスの権限で任意のコードを実行されるおそれがあります。

ここで境界になるのは「ログインできたか」より前に、「未認証の要求が画面を描くための設定を変更できるか」です。ログイン画面が正常に表示され、誤ったパスワードが拒否されていても、そのエラー画面をサーバーが組み立てる過程が安全とは限りません。調査時もログイン成功履歴だけではこの経路を拾えません。また、ログイン画面だけを見て、他の公開コントローラーやアップロード受付への経路がないと結論付けないでください。

Apache OFBizの修正PR #1654では、画面やフォームなどのリソース参照先を共通の仕組みで検査し、file:形式やコンポーネント内で上位ディレクトリをたどる参照を拒否します。コンポーネント以外の参照先は既定で拒否し、明示した許可パターンを使います。匿名のJSONリクエストで、アプリが信頼して設定した属性を上書きする経路も塞いでいます。修正版で独自テーマの画面が出なくなった場合、以前と同じファイルが置かれているかに加え、参照の形式と許可範囲が新しい条件に合うかを確認します。

アプリ間ログインキーは有効な値を取得されると再利用される

CVE-2026-82907はログイン画面のコード実行とは別の問題です。古い版では、アプリ間の移動に使われるexternalLoginKeyを取得した第三者が、その値を送るだけで発行元ユーザーとして扱われるおそれがありました。受け付け処理が通常の認証やCSRF検査より先に行われ、値が元のクライアントに結び付いておらず、使った後も失効しないことが問題です。フレームワークがアプリ間のリンクに付けたキーが、不正なリンク先に渡る経路も指摘されています。

後者で最初に確認すべきなのは、管理画面が公開されているかだけでなく、業務アプリ間を移動する際にキーを付けたURLがどこへ渡るかです。ブラウザーにログインCookieが残っていなくても、取得されたキーの再送が成立する場合があります。外部向けログ転送、問い合わせ票、画面共有などにURLを残す運用があるなら、値を表示しない形でキーの有無と流通先を確認してください。生の値を調査のためにチケットやチャットへコピーすると、閲覧者が増えて追跡が難しくなります。

Apache OFBizの修正PR #1856は、キーの検証先を同じサーバー上の任意のアプリから、本来の遷移先アプリに絞る変更です。Apache OFBizの修正PR #1848ではキーを有効にする設定の扱いも修正しています。キー機能の設定と、遷移先ごとの制約は別の確認点です。従来から設定を無効にしていた環境でも、設定値の見た目だけで影響対象外とは判断せず、修正版で意図した挙動を確認します。独自のアプリ間リンクを作っている場合は、どのリンクが認証状態の引き継ぎを本当に必要とするかも整理できます。

更新対象はリポジトリではなくリクエストを処理する実体で確認する

まず、公開ストア、管理機能、別ホスト名の業務アプリがどのOFBizプロセスに転送されるかを対応表にします。ロードバランサーの通常の宛先に加え、保守用の入口、旧系統のホスト名、同じデータに接続する予備ノードも対象です。管理機能へのリンクをストア画面から消していても、同じ入口からURLを指定して到達できる構成はあり得ます。構成表は画面のメニューではなく、実際の転送規則と稼働中のデプロイから作ります。

Apache OFBizの公式ダウンロードでは24.09.08の配布物とPGP署名・SHA512が公開されています。配布物の真正性を確認してから、各環境で同じ確認済みのソースを使います。独自ビルドやコンテナを使う場合は、依存関係の宣言やイメージのタグの表示だけで完了とせず、各実行環境にどの成果物が展開されたかをビルド記録やイメージのダイジェストにひも付けて確認します。ソースツリーのバージョンを上げても、稼働中のプロセスが旧成果物を使っていれば修正は届きません。

店舗や受注業務の停止時間を抑えるために段階的に切り替える場合は、切り替え途中の旧ノードをどの入口からも再利用できないようにします。ヘルスチェックが成功していることは、そのノードが修正版であることの証拠ではありません。更新作業中に想定外の画面エラーが出た場合は、公開経路を旧版に戻す前に、対象を限定して新旧の動作差を確認できる場所を確保しておきます。障害対策として旧版を残すなら、公開経路へ自動で復帰しない設計にしておきます。

すぐに更新できない場合、管理アプリや使用していないアプリへの到達を業務上必要な経路に限定すると、露出を減らせます。これは本サイトの暫定提案です。認証前に呼ばれる機能がすべてその制限の内側にあると確認できなければ、対策の完了にはできません。特定のURL文字列やパラメーターを入口の装置で拒否するだけで、別の公開経路や既に渡ったキーの問題まで解決するとは考えないでください。

更新後は正常動作と拒否動作を対にして確かめる

本番と同じアプリ構成の検証環境で、通常ユーザーと管理担当者を別のテストアカウントに分けます。最初は匿名のブラウザーで管理アプリを開き、通常のログイン画面が表示され、誤ったパスワードでは管理機能を利用できないことを確認します。次に正規のテストアカウントでサインインし、通常の管理画面と独自テーマ、カタログ編集など、運用に必要な画面を開きます。更新前に使っていた参照形式のために描画が失敗する場合は、独自ウィジェットを信頼済みコンポーネントの管理下に移せるかを先に調べます。外部の任意ファイルを読めるよう許可範囲を広げて以前の表示を再現すると、修正の意図を損ないます。

アプリ間遷移は、たとえばカタログ管理から受注管理へ移る正規の経路を選び、許可される担当者の操作と、許可されない担当者の操作をそれぞれ試します。キー機能を使う場合はテスト専用の値だけを扱い、意図しない遷移先や別ブラウザーで認証状態が引き継がれないかを確認します。キー機能を使わない構成では、キーを伴わない正規の操作が続けられることと、キーによるログインが受け付けられないことを確認します。最終画面のHTTPステータスだけで判断せず、実際のユーザー表示と権限、サーバー側に記録されたアカウントを照合してください。

この確認は、更新で変わりやすい業務画面と認証境界を点検するための手順です。実環境で攻撃用XMLをアップロードしたり、従業員のキーを収集したりする必要はありません。既存の自動テストに足すなら、正常なアプリ間遷移の成功、権限外の画面への到達拒否、匿名での管理操作の拒否を別々の項目にします。正規の遷移が壊れた結果、すべて失敗している状態を「不正な遷移を防いだ」と取り違えないためです。

旧版の公開期間を切り分けてログを調べる

更新はこれからの要求を守る措置で、旧版が公開されていた期間に何が起きたかは別の調査になります。入口のアクセスログとアプリのログを時刻で突き合わせ、ファイル受付と、その直後に起きた管理側の画面描画エラーや予期しない処理を見ます。アプリプロセスが予期しない子プロセスを起動した記録や、管理アプリから通常とは異なる外向き通信があれば、同じ時間帯の変更記録と照合します。画面のエラーやアップロードの記録だけでは悪用の証明にならず、ログインの記録がないこともコード実行を否定する材料にはなりません。

キーの経路については、入口のログでクエリ文字列を取得しているかを確認し、キーを伴うアプリ間の要求と、それに対応するセッションの開始時刻や利用された機能を比較します。クエリを保存していない場合は、キーを含むアクセスの有無をそのログから断定できません。ログに値がある場合は、証跡へのアクセスを制限し、共有用の写しから値を伏せます。正規ユーザーと区別しにくいアクセスがあれば、注文やカタログなど対象アプリで行われた操作を業務記録と照合して、調査範囲を広げるか判断します。

コード実行が疑われる場合は、旧インスタンスを公開経路から切り離し、更新のために上書きする前に必要な証跡を保全します。OFBizプロセスが読めるデータベース接続情報や外部連携用の資格情報は、アクセス範囲を確認したうえで、侵害調査の結果に応じて失効や交換を判断します。キーの不正利用が疑われる場合は、パスワードだけに着目せず、残存するセッションや発行済みの値をどの範囲で無効化できるかも確認します。どちらも侵害を公表済みとみなした対応ではなく、疑わしい痕跡を見つけた場合に取る作業です。

更新完了の基準は、外部から届くすべての経路で24.09.08の成果物が動き、正規のログインとアプリ間の操作が継続でき、意図しない遷移が拒否されることです。そこに旧版の露出期間と確認できた証跡の範囲を添えると、更新作業の終了と、追加調査が必要かどうかを分けて引き継げます。