GitHubにOGNLの制限回避情報、影響は設定など3条件で判断

GitHub Advisory Databaseに、OGNLの呼び出し制限を回避できる脆弱性「CVE-2026-113730」の情報が掲載されています。対象の判断には、OGNLの利用有無だけでなく、入力する式とアクセス制御など3つの条件の確認が必要です。資料では公開日を確認できません。

厳格呼び出しモードでも、別経路の操作を防げない

OGNLの厳格呼び出しモードは、危険なクラスへの直接のメソッド呼び出しを遮断する任意の機能です。メソッドとは、プログラムの処理を呼び出す仕組みを指します。遮断対象にはRuntime、ProcessBuilder、ClassLoaderが含まれます。

今回の問題は、リフレクションという、プログラム内のクラスやメソッドを動的に扱う仕組みを経由すると、この制限を回避できることです。OGNLは呼び出すメソッドの宣言元クラスを使って遮断を判断しますが、修正前の遮断リストには、リフレクションのMethod、Constructor、Fieldが含まれていません。

アドバイザリによると、Javaの開発キットであるJDKの内部で実行される反射呼び出しは、OGNLの遮断判定を通りません。公開された実証コードは、厳格呼び出しを有効にした標準コンテキストで、ファイルを作成できることを示しています。

修正内容は、java.lang.reflectのMethod、Constructor、Fieldを遮断対象に加えるものです。ただし、今回の資料には影響する版や修正版の番号がありません。日本での提供は発表には書かれていません。

主な防御はMemberAccess、追加の遮断だけに頼らない

アドバイザリは、この問題を主要なセキュリティ境界の突破ではなく、多層防御の補強と位置付けています。主なアクセス制御を担うのは、組み込み先のフレームワークやアプリが提供するMemberAccessです。これは、どのメンバーへのアクセスを許すかを制御する仕組みです。

OGNLの標準コンテキストは公開メンバーを許可します。信頼できない入力を隔離するための環境ではありません。このため、厳格呼び出しモードを有効にしているという確認だけでは、影響の有無を判断できません。信頼できない式を扱う場合は、MemberAccessの適切な設定が必要です。

影響する会社・しない会社

• 影響する: 信頼できない、または攻撃者が制御するOGNL式を評価し、標準などの寛容なMemberAccessでjava.lang.reflectを許可し、さらに厳格呼び出しモードの遮断リストを隔離の仕組みとして頼っている会社です。この3条件を全て満たす必要があります。
• 影響しない: Apache StrutsでSecurityMemberAccessを適切に設定している会社は、アドバイザリ上、影響を受けません。
• 影響しない: 上記の3条件が全てそろわない構成は、今回示された影響条件には該当しません。ただし、それだけでアプリ全体の安全を保証するものではありません。

情シスが今日やること

1. 今日、開発担当や委託先に利用状況を照会します。 対象アプリの依存関係の一覧と設定ファイルで、OGNLの利用有無と導入版を確認してもらいます。資料には修正版番号がないため、版番号だけで対応済みとは判断しないでください。
2. 影響判定の前に、式の入力元を確認します。 開発担当に、OGNLで評価する式がどこから渡されるか、信頼できない入力や攻撃者が制御する値を式として評価する経路があるかを確認してもらいます。結果はアプリごとに記録します。
3. 設定と実装を、3条件に照らして点検します。 MemberAccessの実装・設定でjava.lang.reflectを許可しているか、厳格呼び出しモードを隔離の仕組みとして頼っていないかを確認します。Apache Strutsでは、SecurityMemberAccessが適切に設定されているかを開発担当に確認してもらいます。資料に管理画面の操作手順はありません。
4. 対応方針を決める前に、修正情報を照合します。 開発担当や委託先に、遮断対象の追加を含む修正が導入先へ反映されているか確認を依頼します。3条件がそろう場合は、その結果とMemberAccessの設定見直し方針を、システム責任者へ報告してください。資料に更新期限の指定はありません。