Fastjson 1.2.83 は、デフォルトの AutoType=false でも、従来の gadget を使用せずにリモートコード実行をトリガー可能であり、JDK 8/17/21/25 + Spring Boot Loader イソレーション環境で再現済みです。文章作者、来源:GCSA
要約
従来のJavaデシリアライズ脆弱性対策体系において、業界には以下の認識の盲点が広く存在していた。「AutoTypeはデフォルトで無効化されていれば安全」「parseObjectの第二引数(トップレベルのターゲット型)を固定していれば安全」「ローカルClasspathのデシリアライズGadget依存をすべて削除していれば安全」。しかし、最新の技術的攻防の進化は、これらの侥幸心理を完全に打ち破った。
GCSAグローバルサイバーセキュリティアライアンスは本日、この技術インサイトレポートを独占公開します。本レポートでは、Fastjson 1.2.83がデフォルトのAutoType=false状態でも、従来のGadgetに依存しないリモートコード実行(RCE)を引き起こす根本的な原因を詳細に分析しています。現在、この攻撃手法はJDK 8/17/21/25およびSpring Boot Loaderの隔離環境でエンドツーエンドで再現されています。この脆弱性は、従来の「ブラックリストを回避してローカルGadgetを探す」タイプではなく、Fastjson自体のClassメタデータ探査ロジックを、リモート悪意のあるClassの取得と認可チャネルに転用するものです。以下に本文を示します。
発行機関:GCSAグローバルサイバーセキュリティアライアンス
報告タイプ:独占技術インサイト/脆弱性深度分析報告
報告日:2026-07-21
報告ステータス:ソースコード監査および隔離環境での再現が完了しました
脆弱性番号:内部調査番号 FJ-GETRESOURCE-RCE(公開済みCVEには対応していません)
Fastjson 1.2.83は、デフォルトのAutoType=false設定下でも、従来のgadgetを必要とせずにリモートコード実行をトリガー可能であり、JDK 8/17/21/25 + Spring Boot Loader隔離環境で再現済みです。直ちにSafeModeを有効化し、Fastjson 2.xへの移行を推奨します。
1. 実行の要約
Fastjson 1.2.83 の ParserConfig.checkAutoType は、ユーザーが制御可能な @type 値を class リソース名に変換し、現在の ClassLoader の getResourceAsStream に渡します。

絶対URLリソース名を解析可能なfat-jar ClassLoader環境において、攻撃者はドットを置換してhttp:、jar:http:、jar:file: URLを構築し、攻撃側から@JSONType注釈付きの悪意のあるクラスをダウンロードできます。Fastjsonがこの注釈を検出すると、危険な基底クラスチェックおよびターゲット型互換性チェックの前に直接そのクラスを返します。クラスがインスタンス化・初期化される時点で、任意のコードが実行されます。
この攻撃は、ターゲットのclasspathに既存の従来のデシリアライズガジェットに依存せず、FastjsonのAutoType=falseのデフォルト状態でもトリガー可能です。JSON.parseObjectのターゲット型を固定しても実行を阻止できません。SafeModeを有効にすると、リソースアクセス前に通常の攻撃パスをブロックできます。
本報告は、同じJSONペイロードを使用して隔離されたLinuxコンテナ内で以下を再現しました:

2. Vulnerability Rating

コンポーネントのバージョンのみに基づいてCVSS 9.8を一括で評価することは推奨されません。通常のAppClassLoaderは負のコントロールであり、現代的なJDKの完全なチェーンは、2種類の絶対JAR URLを解析できるローダーと/proc/self/fdに依存しています。本レポートの正の環境を満たすアプリケーションにおいて、この脆弱性の影響は認証不要のネットワークRCEとなります。
3. 影響範囲と前提条件
3.1 確認済みの範囲
- 実行時確認:Fastjson 1.2.83
- JDKの確認:8、17、21、25
- オペレーティングシステムの確認:Linux;macOSでは/dev/fdを使用してJDK 17/21/25の再現が完了しました
- loader 確認:Spring Boot 2.7.18 クラシック loader + JDK 8;Spring Boot 3.2.0 loader + JDK 17/21/25
- API確認:JSON.parse、および固定トップレベル型のJSON.parseObject
バージョン3.2の範囲説明
外部記述の 1.2.68–1.2.83 は、脆弱性導入バージョンというより、既知のテスト範囲として適切である。ソースコードの確認によると、決定的な class リソース検出コードは 1.2.67 および 1.2.68 に既に存在している。本レポートでは、1.2.83 に対してのみ、複数の JDK ランタイムでの完全な検証を実施した。
3.3 利用条件
1. 攻撃者は、Fastjson に渡される JSON を制御でき、入力内の @type が解析されます。
2. SafeMode は無効です。
3. Fastjson の ClassLoader は、構築された絶対リソース名を URL として解決できます。
4. 被害プロセスは攻撃側のHTTPサービスに接続できます。
5. 現代のLinuxチェーンは、/proc/self/fdが読み取り可能であり、ローダーが解析できることを要求します
jar:file:/proc/self/fd/N!...。
1. JDK は通常のリモート JAR 一時キャッシュを作成できる必要があります。これは通常、JVM の一時ディレクトリが書き込み可能であることを意味します。
攻撃者は必要としません:
- ターゲットのclasspathにファイルを書き込みます
- 目標のclasspathにTemplatesImpl、JNDI、C3P0、Commons Collectionsなどのgadgetを事前インストール
- Fastjson AutoTypeを有効にする
- JSON.parseObjectの第二パラメータを制御する
4. 根本原因分析
4.1 ユーザータイプ名がリソースURLとして扱われています
ソースコードの場所:

コアコード:

このロジックは、resourceが通常のclasspathパスであると仮定していますが、プロトコル、絶対パスの意味、またはソースを制限していません。特定のfat-jarローダーの場合、以下の入力は置換後に絶対URLになります:

したがって、getResourceAsStreamは、ローカルメタデータのクエリを越えて、攻撃者が制御可能なネットワークリソースを読み込みます。
4.2 リモートクラスの@JSONTypeが認可の根拠として扱われる
Fastjson は独自の ASM ClassReader を使用してリソース内容を解析します:

攻撃側は、リモートクラスにFastjsonの@JSONTypeアノテーションを付与するだけで、jsonTypeをtrueに設定できます。ここでチェックされるのは、攻撃者が提供したバイトコードであり、信頼できるclasspathによって読み込まれたクラスではありません。
4.3 jsonType が実際のクラスローディングをトリガー
ソースコードの場所:
TypeUtils.loadClassは、明示的なローダー、スレッドコンテキストローダー、およびClass.forNameを順に試行します。正の環境では、スレッドコンテキストローダーが同じ絶対リソース名を再度解決し、クラスをダウンロードしてdefineClassを実行します。
4.4 @JSONType 早期返回以跳過後續安全檢查
ソースコードの場所:
- 危険基底クラスのチェックは実行されません
- expectClass.isAssignableFrom(clazz) は実行されません
- クラスの初期化前に固定データバインディングタイプの実行を防ぐことはできません
4.5 例外/エラー:サフィックス生成に失敗したソフトチャネル
ソースコードの場所:
4.6 SafeModeの位置
SafeModeのチェックはリソースアクセスの前に実行されます:
5. リンクの詳細
5.1 JDK 8:リモートクラスの直接ロード
最短形式:
JDK 17+ もネットワークリクエストを完了しますが、内部名内の空のパスセグメントを拒否します。
5.2 現代JDK第1段階:リモートJARのダウンロード
単一ペイロードの最初の配列要素:
JDK 17+ はその後、第一段階のjar:http://... 内部名を拒否するが、FastjsonはExceptionサフィックスにより配列の解析を継続する。
5.3 現代JDK第2段階:キャッシュFDを再開
後続の候補要素:
JDK 17のclass-loadログにおける最初のヒットは:
5.4 なぜ1つのペイロードがJDK 8と現代のJDKの両方と互換性があるのか
- JDK 8 は第一段階の jar:http://... クラスを直接受け入れて実行します
- 第一段階のclassが実行コマンド後に意図的にRuntimeException("stage-one-stop")をスローし、JDK 8が関係のないsocket/pipe FDの試行を阻止する
- JDK 17+ はクラスの初期化前に第一段階で不正な名前により失敗し、その後例外を通じてソフトに返却されてFD列挙段階に入ります
6. 再現環境と証拠
6.1 検査対象コンポーネントのハッシュ
6.2 一键复現

期待される出力:スクリプトは:
- 被害したfat jarをコンパイルする;
- FD専用クラスを含む攻撃JARを生成する;
- JSON配列のペイロードを生成する;
- Dockerネットワークを隔離して攻撃側のHTTPサービスを起動する;
- JDK 8/17/21/25 の被害コンテナをそれぞれ起動する;
- 各コンテナにマッピングされた/tmp/fastjson-getresource-rceを確認してください。
6.3 手動で攻撃用JARとペイロードを生成する
6.4 Burp Suite を使用して送信
Burpは、Fastjson解析ポイントを持つ被害インターフェースにのみJSONを送信する。JARの攻撃は、攻撃側のHTTPサービスによって提供される必要がある。
リクエストテンプレート:
アプリケーションが固定されたトップレベル型を使用する場合、フィールド構造に応じて配列をラップできます。例えば:
本実験では、JSON.parseObject(json, BoundEnvelope.class)を使用して上記のラッパーを解析しましたが、結果は依然としてRCE-OKであり、BoundEnvelopeが正常に返されました。
6.5 キー境界テスト

7. 修正および緩和案 7.1 最良の対策:Fastjson 1.x からの移行
メンテナンス中の Fastjson 2.x への優先的な移行を行い、すべての多相型、AutoType、互換モード設定を再検証してください。JAR を置き換えるだけでは不十分であり、回帰テストを実施してください。
7.2 SafeModeを即時有効化
コード設定:
JVMパラメータ:
注意:AutoTypeCheckHandler を登録している場合、Handler は SafeMode のチェック前に実行されるため、監査または削除してください。
7.3 シリアライズ入口の制限
- 信頼できないリクエストをそのままJSON.parse/JSON.parseObjectに渡さないでください
- ゲートウェイまたはアプリケーションのエントリポイントで、あらゆる種類の特殊メタデータを拒否します。
- トップレベルのJava型を固定するだけでは十分な防御ではないため、ネストされたオブジェクトは依然として@typeを処理でき、本脆弱性のjsonTypeは互換性チェックを早期に回避する。
7.4 WAF/ゲートウェイ一時ルール
@type に等しい JSON キーのデコード後リクエストを一時的にブロックし、URL パラメータ、リクエストボディ、およびネストされたオブジェクトを上書きします。明文の "@type" を検索するだけでは不十分です。Fastjson lexer はフィールド名を先にデコードします。例えば:
WAFルールは緩和策としてのみ使用でき、コンポーネントのアップグレードやSafeModeの代わりにはなりません。
7.5 ネットワーク外出力とランタイムハードニング
- JVMは、不要な外部アドレスへのHTTP/HTTPS接続を禁止します。
- アプリケーションコンテナに最小ネットワークポリシーを適用します。
- 互換性が許す場合、/proc/self/fd の露出を制限するか、より厳格なコンテナサンドボックスを使用してください。
- ClassLoader の絶対 URL リソース名の処理を監査し、http:、https:、jar:、file: などのプロトコル形式を拒否します。
- JVMの一時ディレクトリ内の異常なjar_cache*アクティビティを監視します。
8. 検出提案とIOC
8.1 リクエスト側の特徴
注目すべきは、デコードされた @type 値に含まれるもの:
単独でExceptionが発生してもアラートを出さず、プロトコル形式、@type、および配列内の連続したFD候補と関連付けて分析する必要があります。
8.2 ネットワーク側の特徴
- JVM が拡張子のない JAR または .class ファイルを不正なホストに要求しています
- 同一解析リクエスト期間中に1〜3回の重複GET/HEADが発生しました
- リクエストパスには /x、/a.class、または攻撃者が定義した同等のパスが含まれる可能性があります
8.3 ホスト側の特徴
- JVMの一時ディレクトリにjar_cache*を作成
- Javaプロセスは/proc/self/fd/Nを通じて自身のファイルを再オープンします
- class-load ログに次のような内容が表示されます:
9. 結論
この脆弱性は、従来の「ブラックリストを回避してローカルガジェットを検索する」タイプではなく、Fastjson自体のclassメタデータ探査ロジックをリモートclass取得および認可チャネルに変換したものである。@JSONTypeによる早期返却により、攻撃者が提供したclassが危険な基底クラスおよびタイプバインディングチェックの前に受け入れられる。ExceptionのソフトフォールバックとJDKのjar:http:一時キャッシュにより、JDK 8の直接ロードプリミティブがJDK 17/21/25に拡張された。
したがって、以下の一般的な判断はすべて成り立ちません:
- 「AutoTypeはデフォルトでオフなので安全」— これは成り立たない
- 「固定 parseObject の第二引数なので安全」— これは成立しない
- クラスパスに既知のガジェットがないため安全である」— これは成立しない
- “JKD 17+ は http:// 内部名を拒否するため、SSRF にとどまるだけ” — 成立しない
検証済みのローダー、ネットワーク、ファイル記述子の条件を満たすデプロイ環境では、この問題は単一の認証されていないJSONリクエストから実際のリモートコード実行へと発展する可能性があります。Fastjson 2.xへの移行を優先し、すぐにSafeModeを有効にし、アウトバウンドおよびClassLoaderリソース解決の境界を厳格化してください。
10. 添付ファイルおよび証拠のパス
転載および著作権表示:本レポートおよび関連する技術分析は、GCSAグローバルサイバーセキュリティアライアンスによって独占的に公開されています。転載の場合は、GCSA公式出典および元のリンクを完全に保持し、レポートの核心的な見解を悪意を持って改変しないでください。
出典:GCSAグローバルサイバーセキュリティアライアンス
公式サイト:www.gcsa.org
