Apache Log4j2 の脆弱性 CVE-N/A：新たに発見されたバイパス経路とリモート・コード実行

New Apache Log4j2 Flaw Lets Attackers Bypass Security Checks and Execute Remote Code

2026/08/27 CyberSecurityNews — 新たに報告された Apache Log4j2 の脆弱性を悪用する脅威アクターが、特定の環境におけるデシリアライズ時の許可リストを回避してリモート・コード実行を引き起こす可能性がある。この Log4j2 #4255 として追跡されている問題は、ネットワーク経由でアクセス可能な Java デシリアライズ経路を介して、シリアライズされた Log4j イベントを受け入れるアプリケーションに影響を及ぼす。

この問題は、シリアライズされたログ・イベントの読み取り時にロード可能な Java クラスを制限する Log4j の FilteredObjectInputStream に関連しており、その許可リストには、別のシリアライズ済みオブジェクトを不透明なバイト配列として格納する Java の java.rmi.MarshalledObject が含まれている。つまり、許可リストを通過できる外側のオブジェクトに、別のオブジェクトを隠すことが可能な構造となっている。

研究者が発見したのは、この仕組みにより悪意の内部オブジェクトを隠した外側のオブジェクトが Log4j の許可リストを通過できることである。その後に Log4j が MarshalledObject.get() を呼び出すと、Java はフィルタリングされていない新しい ObjectInputStream を使用して埋め込まれたペイロードをデシリアライズするため、元の許可リストでは隠されたオブジェクト・グラフまでは検査されない。

Apache Log4j2 の新たな脆弱性

この脆弱な処理フローは、Log4j イベントをシリアライズした表現である Log4jLogEvent$LogEventProxy に関連しており、このプロキシはイベント・メッセージを MarshalledObject 内に格納して、デシリアライズ時に自動的に取り出す。したがって、この脆弱性を悪用する攻撃者は、シリアライズ済みの悪意の Log4j イベントを作成して脆弱なレシーバーへ送信することで、標的のクラスパス上で悪意のガジェット・チェーンを実行できる。

GitHub で Log4j2 #4255 を報告した Dinosn が、公開された再現ラボで明らかにしているのは、JDK 17 上で動作する Log4j 2.26.1 での実証結果である。そこで確認できるのは、FilteredObjectInputStream を使用する未認証の TCP レシーバーが、MarshalledObject に埋め込まれた悪意のペイロードを処理する際にコード実行が引き起こされる状況である。

さらに、このラボでは、攻撃者が被害システム上にクラスを用意しなくても Commons Collections 3.2.1 のガジェット・チェーンを実行できることが示されている。ただし、この問題は、広範囲に影響を及ぼした Log4Shell 脆弱性とは異なり、アプリケーションのログ・メッセージに悪意の文字列を挿入するだけでは引き起こすことができない。

悪用に際しては、攻撃者が制御するシリアライズ済み Log4j イベントを受け入れるレシーバーの公開／FilteredObjectInputStream によるイベントの処理／利用可能な Java デシリアライズ用ガジェット・チェーンの存在という、限定的な構成条件が必要になる。この変化は、現在の Log4j Core の一般的な本番コードが、ソケット／キューなどの外部ソースから受信したデータをデシリアライズしないところに起因し、悪用には特定のレガシー／カスタム構成が必要となる。

Apache は FilteredObjectInputStream について、完全なセキュリティ境界ではなく多層防御のためのユーティリティと説明しており、アプリケーションで信頼できないログ・イベント・ストリームをデシリアライズすべきではないと警告している。

ユーザー組織は、古いソケット・ブリッジ・パターンに基づく未認証のネットワーク・サービスを中心に、レガシーなシリアライズ済み Log4j イベント・レシーバーを特定する必要がある。

一時的な緩和策としては、JVM のシリアライズ・フィルタを設定して java.rmi.MarshalledObject を拒否する方法があるが、この対策では正当なシリアライズ済み Log4j イベントもブロックされる可能性がある。より恒久的な防御策としては、ログ転送における Java シリアライズの排除／脆弱なガジェット・チェーンを構成する依存関係のアップグレードまたは削除／相互認証されたエンドポイントの使用／TLS 経由の JSON または RFC 5424 に基づくロギングへの移行などがある。Apache が特に推奨しているのは、Java でシリアライズされたログ転送ではなく、構造化フォーマットと TLS の使用である。

なお、執筆時点で Log4j2 issue #4255 は未解決であり、CVE は割り当てられていない。この問題は、通常の Log4j 環境全般に影響するリモート・コード実行の脆弱性ではなく、レガシーまたはカスタムの Log4j イベント・レシーバーに存在する、デシリアライズ時の許可リストを回避する問題と捉えるのが適切である。

Apache Log4j2 におけるデシリアライズ時の検証回避と、その対策を解説する記事です。本来は制限対象であるはずの悪意あるデータを保護フィルターが誤って通過させてしまう不具合が発端となっています。ネットワークを越えて送られるログデータの中に攻撃プログラムが忍び込み、サーバー上で不正な命令が意図せず処理される危険が生じます。主な影響として権限外でのファイル操作／不正なコマンド実行／情報漏洩などの問題を引き起こす恐れがあります。システムの健全性を保つための対応策としては古い受信機能の停止／ログ送信形式の JSON 化／シリアライズ処理の廃止／通信経路の TLS 化などによる、安全な設計へ向けた見直しが強く求められます。