英語版で読む
技術約10分で読めます

Fastjson 1.xの未修正RCEはSpring Boot fat-JARとSafeMode無効で成立する

セキュリティCVERCEJavaSpring脆弱性
いけさん目次

TL;DR

影響 Fastjson通常版1.2.68〜1.2.83。Spring Boot executable fat-JARで動き、SafeModeが無効で、外部から制御できるJSONがFastjson 1.xのパーサーへ到達する構成が対象

差分 AutoTypeを有効化していなくても成立。固定DTOへ JSON.parseObject(body, SomeDto.class) しているコードも、DTO内の Object や Map 型フィールド経由で対象

対応 Fastjson 1.xの新しい通常版修正版は出ていない。短期はSafeModeを有効化するか 1.2.83_noneautotype へ切り替え、長期はFastjson2へ移行

Fastjson 1.xの最後の通常リリースだった1.2.83に、CVE-2026-16723のRCEが見つかった。
Alibabaのアドバイザリは2026年7月21日公開で、CVEレコード上の対象は1.2.68〜1.2.83。
CVSSはAlibaba CNA評価で9.0、NVD側は2026年7月26日時点で独自評価なしのままだが、CNAスコアとして9.0 Criticalを載せている。

CVEの正式な影響範囲と、問題のコードが入った最初の版は一致していない。
CVEレコードは1.2.68〜1.2.83を影響ありとし、それ以外は defaultStatus を unaffected にしている。AlibabaのWikiは1.2.60以前を不影響とする一方、1.2.61〜1.2.67の根拠を説明していない。
GCSAのソースコード解析では、決定的なリソース解決が1.2.67にもあると指摘している。ただし同社がすべてのJDKでエンドツーエンドに再現したFastjsonは1.2.83だけで、1.2.61〜1.2.67については対象と言える根拠も、正式範囲外だから安全と言える根拠も揃っていない。

過去のFastjson系では「AutoTypeをオンにしている」「クラスパスに使えるガジェットがいる」という条件がよく出てきていた。
今回はAutoTypeが無効でも、SafeModeが無効なら成立する。
Alibabaのアドバイザリにも、標準設定のまま悪用でき、クラスパス上のガジェットも不要とある。

成果物がSpring Boot executable fat-JARかを見分ける

Alibabaは、ライブラリのバージョンに加えて、Spring Boot executable fat-JARとして java -jar xxx.jar で起動していることも前提条件に挙げている。
Spring Boot 2.x、3.x、4.xとJDK 8、11、17、21でエンドツーエンドに検証済みとも書いているが、全組み合わせの結果やOS、組み込みサーバー別の条件表は公開していない。

このブログでは前に Spring BootでRequest SmugglingとRequest Splittingを取り違えない で、Spring Bootの確認対象として、アプリコード、組み込みTomcat、前段プロキシ、実際の起動形態を分けて書いた。
今回も、pom.xml にFastjsonがあるかどうかと、実行中の成果物がどの形式なのかは別々の条件になる。

Alibabaの不影響条件には、素のnon-fat JAR、汎用のuber-JAR、Tomcat/JettyへのWAR配備が挙げられている。
今回の条件は、Fastjson 1.xの型解決経路とSpring Boot fat-JARのローダーが組み合わさったときに成立する。

通常のJARも java -jar で起動するので、コマンドラインからはSpring Boot executable fat-JARかどうか判別できない。
実際に配備した成果物のマニフェストと BOOT-INF を確認する。

unzip -p app.jar META-INF/MANIFEST.MF \
  | rg '^(Main-Class|Start-Class):'
jar tf app.jar \
  | rg '^BOOT-INF/(classes/|lib/fastjson-.*\.jar$)'

Spring Boot 2.xから3.1系のマニフェストでは org.springframework.boot.loader.JarLauncher、3.2以降と4.xでは org.springframework.boot.loader.launch.JarLauncher が Main-Class の候補になる。
BOOT-INF/lib/fastjson-1.2.83.jar のような実ファイルがあれば、配布物そのものに通常版Fastjsonが入っていることまで確認できる。

flowchart TD
    A[外部入力JSON] --> B[Fastjson 1.x parser]
    B --> C["@type からクラスリソース名を生成"]
    C --> D["getResourceAsStreamで<br/>URL形式のリソースを解決"]
    D --> E[攻撃者側JARからクラスのバイト列を取得]
    E --> F["@JSONType を検出"]
    F --> G{直接classを定義できるか}
    G -->|JDK 8などで成功| H[クラス初期化]
    H --> K[Javaプロセス権限でコード実行]
    G -. JDK 9以降は失敗 .-> I[リモートJARの一時キャッシュ]
    I --> J["Linuxでは /proc/self/fd/N<br/>から再参照する公開手順"]
    J --> H

FearsOffのKirill Firsov氏の解析では、Fastjsonは攻撃者が制御する @type からクラスリソース名を作り、getResourceAsStream で内容を読む。
Spring Boot executable JARのランチャー用 ClassLoader では、そのリソース名をURLとして解決できる場合があり、攻撃者側のJARへ到達する。
読み込まれるのは攻撃者が用意した外部のJARで、アプリのfat-JARに同梱されたnested JARは使わない。

取得したクラスのバイト列に @JSONType アノテーションがあると、Fastjsonは通常のAutoType拒否より前に loadClass へ進む。
FearsOffの検証では、JDK 8の直接ロード経路とJDK 9以降で挙動が分かれた。JDK 9以降は :// を含むクラス名を拒否するため、最初のリモートJAR取得はSSRF（Server-Side Request Forgery、サーバー側から任意URLへアクセスさせる攻撃）で止まる。
同社が新しいJDKと既定設定のTomcatで示したRCEは、JVMが一時ファイルとして開いたリモートJARを、後続の候補から /proc/self/fd/N 経由で再参照する多段経路だった。

/proc/self/fd はLinux固有である。独立再現したGCSAはmacOSの /dev/fd でも確認したが、Windowsを含む全OSで同じ経路が成立する証拠にはならない。
一方、AlibabaのアドバイザリはOSを不影響条件にしていないため、Linux以外であることを根拠に安全判定もできない。公開されている攻撃手順では、Javaプロセスから攻撃者側HTTPサービスへの通信と、一時JARキャッシュを作れる環境も条件に入る。外向き通信の制限は、攻撃者側JARの取得を遮断する多層防御になる。型解決そのものはFastjson側の設定で止める。

固定DTOを指定してもObject型やMap型のフィールドから入る

Alibabaのアドバイザリは、到達しうる入口として JSON.parse、JSON.parseObject(String)、JSON.parseObject(String, Class) を挙げている。
JSON.parseObject(body, SomeDto.class) のように対象クラスを固定しているコードも、この一覧に入っている。

入力JSONを固定DTOへ束縛しても、DTO側に Object や Map 型のフィールドがあれば、そのフィールドの中身は型が決まらない。
中身の値は外側のクラス指定を経由せずにFastjsonの型解決へ渡り、そこで同じリソース解決の経路に入る。

まず com.alibaba:fastjson の直接依存と推移依存を出し、配布したfat-JAR内の版と突き合わせる。
その上で、外部入力のJSON文字列がFastjsonへ入る場所を探す。

mvn dependency:tree -Dincludes=com.alibaba:fastjson
./gradlew dependencyInsight \
  --dependency com.alibaba:fastjson \
  --configuration runtimeClasspath
jar tf app.jar | rg '^BOOT-INF/lib/fastjson-.*\.jar$'
rg "JSON\\.parse|JSON\\.parseObject|JSONReader|JSONObject\\.parse" src

この検索で出るのは候補で、静的インポート、社内ラッパー、別モジュールを経由する呼び出しは文字列検索には出てこない。
依存関係ツリーでライブラリの有無を出しても、外部から到達するJSONの入口は、HTTPリクエストのほかに管理画面、Webhook、内部API、メッセージキューのコンシューマまで広がる。

SafeModeの有効判定は実際に使うParserConfigで決まる

2026年7月26日時点で、Fastjson 1.xの新しい通常版修正版は出ていない。
GitHubのfastjsonリポジトリは2024年10月23日にアーカイブ済みで、タグの先頭も2022年5月23日の1.2.83、つまり今回攻撃されている版のままだ。

短期対応はSafeMode有効化、またはnoneautotypeビルドへの切り替えになる。
SafeModeは、今回のクラスリソース解決より前の段階で型解決を止める。

java -Dfastjson.parser.safeMode=true -jar app.jar

コード側で入れる場合、全呼び出しがグローバルインスタンスを使うと確認できるなら次の設定で止められる。

ParserConfig.getGlobalInstance().setSafeMode(true);

ただし、new ParserConfig() や独自の ParserConfig をパーサーへ渡しているコードには、グローバルインスタンスのフィールド変更がそのまま適用されない。
Fastjson 1.2.83は、ParserConfig 自身のSafeMode、呼び出し時の Feature.SafeMode、JSON.DEFAULT_PARSER_FEATURE のいずれかで有効判定する。起動引数だけでなく、設定ファイルと実際の呼び出し方まで調べる。

jcmd 12345 VM.system_properties \
  | rg '^fastjson\.parser\.safeMode='
jar tf app.jar | rg '(^|/)fastjson\.properties$'
unzip -p app.jar BOOT-INF/classes/fastjson.properties \
  | rg '^fastjson\.parser\.safeMode='
rg "setSafeMode|Feature\\.SafeMode|new ParserConfig|AutoTypeCheckHandler" src

システムプロパティに出ていなくても、コードや呼び出し時の Feature 指定でSafeModeを有効にしている場合がある。
逆にグローバルインスタンスの isSafeMode() がtrueでも、別の ParserConfig を使う入口があれば、そのパーサーには設定が反映されていない。AutoTypeCheckHandler はSafeMode判定より前に呼ばれるため、登録しているなら許可型を厳しい許可リストに限定できているかも確認する。

もう一つのP0対応は com.alibaba:fastjson:1.2.83_noneautotype。
Alibabaのアドバイザリは、このビルドを脆弱なAutoType関連コードをコンパイル時に除去したものと説明している。
ただし、依存先ライブラリ経由で通常版fastjsonが再び入ると意味がないので、Mavenなら依存関係管理、Gradleなら解決戦略まで含めて実成果物を確認する。

Fastjson2には、今回の根本原因になったリソース探索と、アノテーションを信頼して検査を飛ばす経路がない。
型の許可も許可リスト優先で処理する。
移行には互換性確認がいるが、Alibabaが長期対応に挙げているのはFastjson2移行だ。noneautotypeビルドは今回のCVEの経路を塞ぐが、保守が終わった1.xを使い続ける点は変わらない。

攻撃は観測されているが被害の証跡は公開されていない

ThreatBookは2026年7月22日、検知ルールの追加後に実環境での悪用を確認したと報告した。
ただし同社の再現結果はもう少し狭く、Spring Boot fat-JAR + JDK 8では完全なコード実行、組み込みTomcatのテストではリモートJARの取得かSSRFまでだったとしている。

ImpervaもCVE-2026-16723の悪用試行を報告し、金融、医療、コンピューティング、小売などへの通信を観測した。
地域は主に米国で、シンガポールとカナダが少量。
同社はWAF側で不審な @type の値、nested JARのURLパターン、RCEの手口を検査すると説明している。

公開情報で確認できるのは、攻撃リクエストや悪用試行の観測だ。
実環境でコード実行まで進んだ証跡、被害組織名、侵害件数、生のリクエスト、実行後のプロセス証跡は、両社の公開記事に出ていない。
NVDの変更履歴には、CISA-ADPが2026年7月23日にSSVCの exploitation を none として追加した記録もある。
これは同日時点のCISA-ADPによる分類で、ベンダーの観測主張とは一致していない。
2026年7月26日時点ではCISA KEVにも未掲載だ。KEVへの掲載を待たずに、通常版1.2.68〜1.2.83、SafeMode無効、外部JSONが到達するパース入口、Spring Boot fat-JARが重なる構成から変える。

ログ側の検出対象は @type、jar:http、jar:file、外向きHTTP/HTTPS通信、Javaプロセスからの子プロセス起動、Webシェル、予期しないファイル変更になる。
WAFやCDNのログに残るのはリクエストまでで、Javaプロセスが実行した内容はそこに出ない。
RCEの成否は、EDR、auditd、systemd journal、アプリログ、コンテナランタイムのログを突き合わせて判定する。

参考: