Log4jのFilteredObjectInputStream回避でRCE再現、PoCが公開-Apacheは「脆弱性ではない」と公式見解、CVE未採番

Apache Log4j 2のFilteredObjectInputStream（FOIS）を使ったJavaデシリアライズ処理について、allowlistを回避して任意オブジェクトをデシリアライズできるとして、2026年8月24日にGitHub Issue #4255で問題提起が行われました。その後、独立したセキュリティ研究者がLog4j 2.26.1とJDK 17を使った環境でリモートコード実行（RCE）を再現するPoCを公開しています。

ただし、Apache Logging Servicesはこの挙動をLog4jの脆弱性とは認定していません。

Apacheは公式のセキュリティFAQと脅威モデルで、Log4jは通常動作として外部から受信したデータをJavaデシリアライズせず、FilteredObjectInputStreamは安全境界ではなく防御強化のための補助機能だと説明しています。非信頼のシリアライズ済みデータをアプリケーション側がObjectInputStreamへ渡す構成自体を推奨しておらず、FOISのallowlist回避は「脆弱性ではなく、さらなるハードニングの機会」と位置付けています。

実際、今回問題視されているjava.rmi.MarshalledObjectを経由したallowlist回避は、8月24日のIssueより前となる7月1日、Apache Log4jのメンテナーが公開したDiscussion #4168ですでに具体的に説明されていました。

2026年8月27日時点でIssue #4255はClosedとなっており、CVEは確認できません。Apacheの公式Securityページにも本件は脆弱性として掲載されておらず、本件を修正対象とするリリースも公表されていません。最新のLog4j 2系リリースは2.26.1です。

Log4j FilteredObjectInputStream問題のサマリー

• 【確認済み】2026年8月24日、Apache Log4jのGitHub Issue #4255でFilteredObjectInputStreamのallowlist回避が問題として公開されました。
• 【確認済み】Issue #4255は8月26日にClosedとなり、現在は本文が削除された状態です。
• 【確認済み】同じMarshalledObject.get()によるallowlist回避は、Apache Log4jメンテナーが7月1日のDiscussion #4168ですでに公開していました。
• 【Apache公式見解】Apache Logging ServicesはFOISのallowlist回避をLog4jの脆弱性とは扱っていません。
• 【Apache公式見解】FOISは「security boundary」ではなく、防御を補強するための補助機能とされています。
• 【確認済み】通常のLog4j Coreには、ネットワーク等から受信したデータをObjectInputStream.readObject()へ渡す処理経路はないとApacheは説明しています。
• 【PoC確認済み】独立研究者がLog4j 2.26.1／JDK 17環境で、条件付きのRCEを再現する公開PoCを公開しています。
• 【重要】PoCは通常のLog4j利用だけでは成立せず、非信頼のシリアライズ済みLogEventをFOISで受け取るアプリケーション構成などが必要です。
• 【研究者報告】研究者はlog4j-api 2.11.0～2.26.1、log4j-core 2.8.0～2.26.1を検証対象・影響候補として挙げていますが、Apacheは公式な「影響バージョン」を定義していません。
• 【未確認】実際の攻撃で本件が悪用されたとの一次情報は確認できませんでした。
• 【未確認】CVE、公式CVSS、Apache Security Advisoryは確認できませんでした。
• 【未掲載】2026年8月27日時点でCISA KEV Catalogへの掲載も確認できませんでした。

項目	内容
公開日	2026年8月24日（Issue #4255）
先行するApache公開情報	2026年7月1日 Discussion #4168
対象	Apache Log4j 2のJavaデシリアライズ関連処理
問題となる機能	FilteredObjectInputStream、LogEventProxy、MarshalledObject
想定される影響	条件を満たすアプリケーションで任意オブジェクトのデシリアライズ、RCEにつながる可能性
Apacheの評価	Log4jの脆弱性とは扱わず、ハードニング上の課題
CVE	確認できず
CVSS	公式評価なし
PoC	独立研究者によるRCE再現PoCが公開済み
実攻撃での悪用	確認できず
CISA KEV	2026年8月27日時点で掲載確認できず
最新Log4j 2	2.26.1
本件専用の修正版	公表されていない
Issue #4255	Closed
主な対策	非信頼データのJavaデシリアライズを停止、シリアライズ済みログ受信機能を外部公開しない

8月24日にIssue #4255が公開、現在はClosed

SecurityOnlineは8月26日、Log4jのFOISを回避してリモートコード実行につながる問題が8月24日に公開されたと報じました。

起点となったのはApache Log4jのGitHub Issue #4255です。

現在のIssueページでは、8月24日に作成されたことと、ステータスがClosedであることを確認できます。一方、投稿者はghostと表示され、元のIssue本文は削除されています。

そのため、Issue #4255自体を現在の一次資料として詳細に参照することは難しい状態です。

ただし、本件の技術的な論点そのものはIssue #4255より前からApacheプロジェクト内で公開されていました。

同じ問題をApacheメンテナーが7月1日にすでに公開

Apache Log4jのDiscussion #4168「Log4j 2.x deserialization hardening」は2026年7月1日に公開されています。

このDiscussionでは、FilteredObjectInputStreamやJava 9以降で利用されるDefaultObjectInputFilterのallowlistについて複数のハードニング上の課題を整理しています。

その中で最優先の項目として挙げられているのが、今回Issue #4255で注目されたjava.rmi.MarshalledObjectを介したallowlist回避です。

Apache側の説明では、LogEventProxyが保持するMarshalledObjectの内部データを展開する際、別のデシリアライズ処理が行われ、Log4j側のallowlistによる制限がそのまま適用されない経路があります。

ただしApacheメンテナーは、この挙動について明確に「security issueではない」としています。

理由は、Log4jが非信頼のデータを安全にJavaデシリアライズできることを保証しておらず、FOISを安全境界として設計していないためです。

Apache「FilteredObjectInputStreamはsecurity boundaryではない」

Apache Logging Servicesの公式Securityページでは、非信頼データのデシリアライズに関する脅威モデルを明示しています。

Apacheは、Log4j Coreが通常動作として外部のネットワークソケット、メッセージキューなどからデータを受け取り、ObjectInputStream.readObject()へ渡す処理は行わないと説明しています。

Log4j 2には後方互換性のためSerializableを実装するクラスが残っていますが、それらを非信頼の入力からデシリアライズすることの安全性は保証していません。

FilteredObjectInputStreamについても、シリアライズ済みログイベントを扱う既存アプリケーションのための「defense-in-depth helper」と位置付けています。

Apacheは公式FAQで、allowlistが完全で回避不能であることを保証せず、allowlist回避はLog4jの脆弱性ではなく、追加のハードニング機会として評価すると説明しています。

したがって、「Log4jを導入しているだけで未認証RCEが成立する」という理解は適切ではありません。

公開PoCはRCEを再現、ただし成立条件あり

Issue #4255の公開後、複数の独立研究者が検証環境を公開しています。

そのうちの一つは、Apache公式のLog4j 2.26.1アーティファクトとJDK 17を使用した環境で、FOISを使ってシリアライズ済みLogEventを受け取るサービスに対し、allowlistの内側から別のデシリアライズ処理へ到達できることを検証しています。

さらに、対象環境のクラスパスに悪用可能なデシリアライズ用クラス群が存在する場合、コード実行まで再現したとしています。

一方、このPoC自身も「application-conditional」であり、Log4jを利用するすべてのアプリケーションに対するRCEではないと明記しています。

成立には少なくとも、アプリケーション側がシリアライズ済みのLog4jイベントを受信し、それをFOISを通じてデシリアライズする構成が必要です。

さらにRCEへ発展するには、対象プロセスのクラスパス上に利用可能なデシリアライズ経路が存在するなど、追加条件が必要になります。

Log4Shellとは攻撃面が大きく異なる

今回の問題を2021年のLog4Shell（CVE-2021-44228）と同列に扱うべきではありません。

Log4Shellは、一般的なログ出力処理に攻撃者が制御する文字列を到達させることで悪用可能となり、多数の通常構成のJavaアプリケーションが影響を受けました。

一方、今回のFOIS問題は、攻撃者が制御するJavaシリアライズデータを受け取るアプリケーション側のデシリアライズ処理が前提です。

Apacheの公式FAQによると、Log4j 1にはシリアライズ済みログイベントをネットワークで送受信するSocketServerなどがありましたが、現在のLog4j 2 Coreの本番コードには同等の受信機能はありません。

SerializedLayoutもLog4j 2.9以降は非推奨です。

したがって、SBOMや依存関係からLog4j 2.26.1が見つかったという理由だけで、「今回のRCEに脆弱」と判断することはできません。

研究者が示すバージョン範囲とApacheの扱いは異なる

公開PoCの研究者は、FilteredObjectInputStreamが導入されたlog4j-api 2.11.0以降と、関連するLogEventProxyのシリアライズ処理を持つlog4j-core 2.8.0以降を対象として、2.26.1までを影響候補として挙げています。

ただし、これは研究者側の評価です。

Apacheは本件を脆弱性として扱っていないため、公式Securityページに「Affected Versions」「Fixed Versions」は掲載していません。

そのため、一般的なCVE記事のように「2.26.1以下が脆弱、2.26.2で修正」と整理できる状態ではありません。

2026年8月27日時点でApache公式の最新Log4j 2リリースは2.26.1で、本件を修正するための2.26.2などは公開されていません。

CVE未採番、CISA KEVにも掲載確認できず

本件について、2026年8月27日時点でCVE番号は確認できませんでした。

Apache Logging Servicesの公式SecurityページにもIssue #4255は脆弱性として掲載されておらず、公式CVSSもありません。

CISA Known Exploited Vulnerabilities Catalogでも、本件に対応する新規Log4j項目は確認できませんでした。

なお、CISA KEVには2021年のLog4Shell、CVE-2021-44228が現在も掲載されていますが、今回のFOIS問題とは別の脆弱性です。

また、実際の攻撃で今回の経路が悪用されたとの一次情報も確認できませんでした。

公開PoCが存在することと、実環境で悪用が確認されていることは区別する必要があります。

「修正版なし」ではなく「Apacheが脆弱性として扱っていない」

SecurityOnlineなど一部の報道は、本件について「unpatched vulnerability」「no patched release exists」と説明しています。

技術的には、本件の挙動を変更する専用修正版が現時点で存在しないことは事実です。

一方、「未修正の脆弱性」という表現だけでは、Apacheが本件を正式な脆弱性として認定しながら修正を保留しているようにも受け取れます。

実際にはApacheは、非信頼データのJavaデシリアライズ自体をLog4jのセキュリティ保証範囲外としており、FOISのallowlist回避を脆弱性とは認定していません。

したがって、現状は「脆弱性として認定されたがパッチがない」のではなく、「研究者はRCEにつながる問題として評価している一方、Apacheは脅威モデル上の脆弱性ではないと評価している」という状態です。

情報システム・開発部門への示唆

企業が最初に確認すべきなのは、Log4jのバージョンだけではありません。

Javaアプリケーションの中に、外部から受け取ったJavaシリアライズデータ、とりわけシリアライズ済みのLog4j LogEventをデシリアライズする処理が存在するかを確認する必要があります。

特に、過去のLog4jサンプルや独自実装を参考にしたログ受信サーバー、古い監視・ログ集約システム、自社開発のソケット受信処理などは確認対象です。

該当する処理が存在しない一般的なLog4j利用環境であれば、今回の公開PoCと同じ攻撃経路は成立しません。

一方、該当するレガシー構成が残っている場合は、単にネットワーク制限を追加するだけでなく、Javaネイティブシリアライズによるログ転送そのものを廃止することが優先されます。

Apacheは代替策として、JSONやRFC 5424などの構造化形式をTLSで転送する方式を推奨しています。

やむを得ずシリアライズ済みデータを扱う場合は、送信元・受信元を相互認証し、非信頼ネットワークから到達できないようにするとともに、JVM全体のシリアライズフィルターを設定することが推奨されています。

また、FOISを利用していることだけを理由に「安全なデシリアライズが保証されている」と判断すべきではありません。

今回の問題で最も重要なのは、特定クラスのallowlist回避そのものより、「Javaネイティブデシリアライズを外部入力に対するセキュリティ境界として使わない」という設計原則です。

セキュリティ対策Labでは、Log4jの別の脆弱性として、Socket AppenderのTLSホスト名検証に関するCVE-2025-68161も取り上げています。今回の問題とは原因も攻撃条件も異なるため、Log4j関連という理由だけで同一リスクとして扱わないことが重要です。

出典

• Frequently Reported Vulnerabilities – Apache Logging Services
• Security – Apache Logging Services
• Log4j 2.x deserialization hardening Discussion #4168 – Apache Log4j / GitHub
• Issue #4255 – Apache Log4j / GitHub
• Download Apache Log4j – Apache Logging Services
• Release notes – Apache Log4j
• FilteredObjectInputStream Javadoc – Apache Log4j
• Log4j2 Issue #4255 independent reproduction – GitHub
• Public Disclosure: Unpatched Log4j RCE Flaw in FilteredObjectInputStream, No CVE Assigned – SecurityOnline
• Log4j「Socket Appender」でTLSのホスト名検証が効かない脆弱性(CVE-2025-68161) – セキュリティ対策Lab