xiaoqimikko/fastjson-checkZero-dependency, offline CLI scanner that finds fastjson inside JARs and Spring Boot fat-JARs, flags CVE-2026-16723 exposure, and detects shaded dependencies for CI gating.
1つのコマンドで、あなたの Java アプリケーションに fastjson が存在するか、どこに隠れているか、CVE-2026-16723 の影響を受けるかを明らかにします。
依存ゼロ · 完全オフライン · 単一の 23KB の jar · Java 8+ 対応
2026年7月21日、fastjson 公式は CVE-2026-16723（CVSS 9.0、リモートコード実行）を公表しました：
多くのセキュリティアドバイザリ（複数の英語セキュリティメディアを含む）は今なお「1.x は EOL、パッチは永遠に出ない、fastjson2 への移行しかない」と述べています。 この主張は 2026-07-29 以降、成立しません。 ご自身で検証できます：
| 証拠 | リンク |
|---|---|
Maven セントラルリポジトリに com.alibaba:fastjson:1.2.84 があり、jar は 2026-07-29 にアップロード | repo1 |
GitHub release 1.2.84、公開日時 2026-07-29T08:24:51Z | release |
重要なコミット fix: strengthen autoType type name validation and whitelist verification | 2026-07-29T07:02:55Z |
1.2.83 は 2022年5月に公開され、その後 1.x ブランチは4年間コミットなし —— 1.2.84 は今回の脆弱性のために特別に例外として公開されたものです。
その release タイトルにはセキュリティ修正の記載がありません：1.2.83 のタイトルには「（セキュリティ修正）」と書かれていますが、1.2.84 には
「1.2.84版本发布」とだけ書かれています。しかし本文には書かれています —— 完全な Security Fixes セクションがあり、4項目の AutoType
強化が逐条列挙されており、しかも公開当日（2026-07-29）からその状態でした（Wayback のアーカイブ 20260729094935 で確認可能）。
なぜパッチ公開後もセキュリティアドバイザリやスキャナの多くが追随していないのかについては、私は調査しきれていないため、ここでは推測しません。
📌 2026-08-14 訂正：ここには元々「全文にセキュリティの記載がなく、そのため追随されなかった」と書かれていました。前半は release 本文と Wayback の当日アーカイブを実測した結果誤りであり（タイトルのみ記載なし）、後半もそれにより根拠を失うため、併せて削除しました。
👉 1.x ユーザーへの実際の影響：1.2.84 へのアップグレードが最も低コストな対応です（同一ブランチのマイナーバージョンで、通常コード変更は不要）。 fastjson2 への大規模なバージョン移行を直ちに強いられる必要はありません。本ツールはこれに基づいた推奨を提示します。
⚠️ 前提は JDK 8 以上（2026-10-14 実測）：1.2.84 の 274 個の class はすべて Java 8 バイトコード（major 52）で、 1.2.83 は Java 5（major 49）です。JDK 7（Zulu 7u352）では
javacは警告のみで終了コード 0 ですが、実行時には直接UnsupportedClassVersionError: com/alibaba/fastjson/JSON : Unsupported major.minor version 52.0をスローします。 また、1.2.84 内のJSON.VERSION定数は依然として"1.2.83"であり、これでバージョンを判定すると誤ります。本ツールはpom.propertiesを読むため、影響を受けません。
そして最も厄介な点は：
fastjson は通常推移的依存です —— 誰も積極的にインストールしたわけではなく、他のライブラリに付随して入り込んでいます。 多くのチームは自分が使っていることすら知りません。
mvn dependency:tree は依存関係を一覧できますが、2つのケースには対応できません：
本ツールはこの2つのケースのために書かれました。
Releases から fastjson-check.jar をダウンロードし、次に：
# 扫一个 jar（Spring Boot fat-JAR 会自动逐层展开）
java -jar fastjson-check.jar ./myapp.jar
# 扫一整个目录（递归查找所有 jar/war）
java -jar fastjson-check.jar /opt/apps
# 输出 JSON，接入流水线
java -jar fastjson-check.jar /opt/apps --json
インストール不要、アカウント不要、ネットワーク接続不要、データのアップロードも一切不要です。
同じアーティファクトが CLI と Maven プラグインの両方として機能します。この使い方では事前に jar をダウンロードする必要はありません：
# 在你的项目目录下直接跑，扫的是 Maven 解析后的依赖
mvn io.github.xiaoqimikko:fastjson-check:0.3.1:check
またはビルドライフサイクル（verify フェーズ）にバインドします：
<plugin>
<groupId>io.github.xiaoqimikko</groupId>
<artifactId>fastjson-check</artifactId>
<version>0.3.1</version>
<executions>
<execution>
<goals><goal>check</goal></goals>
</execution>
</executions>
</plugin>
pom.xml をスキャンさせるより正確なのかCLI が pom.xml をスキャンするときに読むのはテキストであり、実際のプロジェクトでは fastjson のバージョンがそのテキストの中にないことがよくあります：
<version>${fastjson.version}</version><parent> から継承しており、自分の pom にはこの行がないプラグインが取得するのは Maven が解決を完了した後の依存集合であり、各依存はローカルリポジトリ内の実際の jar パスを伴っています。
したがって通るのはまさにこのツールが最も得意とする道です：実際の jar 内の com/alibaba/fastjson(2)/JSON.class をスキャンするのであり、
pom に何が書かれているかを信じるのではありません。
⚠️ ただし識別の境界はこれによって変わりません：判定キーは依然としてその class パスであるため、 relocate / パッケージ名変更で再パッケージされた依存は依然として識別できません（下記「それが何ではないか」を参照）。 プラグインが解決するのは「バージョンがどこに書かれているか」であり、「パッケージ名が変更されたか」ではありません。
| パラメータ | デフォルト | 説明 |
|---|---|---|
-Dfastjson-check.failOnFound | false | CRITICAL / HIGH が見つかった場合にビルドを失敗させる |
-Dfastjson-check.path | 未設定 | 依存関係ツリーをスキャンせず、このパス（ディレクトリ / jar / war / fat-jar）をスキャンする |
-Dfastjson-check.skip | false | 実行をスキップする |
🔴 デフォルトではビルドを失敗させません。これは意図的なものであり、CLI の終了コードの意味とは異なります：
コマンドラインは自分で叩くものなので、終了コード 1 はまさに望むところです。一方プラグインはパイプラインに組み込まれるものであり、
自己チェックツールが何の準備もないときにビルドを赤くするべきではありません。CI ゲートとして使うには、明示的に
-Dfastjson-check.failOnFound=true を追加してください。
💡 Windows でレポートが文字化けする場合は、コンソールを GBK に戻してください（
chcp 936）—— プラグインモードの出力エンコーディングは Maven が決定するため、CLI の--utf8/--gbkスイッチはここでは届きません。
fastjson-check 0.1.0 —— fastjson 应急排查（离线，不外传任何数据）
扫描目标：myapp.jar
已展开归档：3 个
发现 2 处 fastjson：
[CRITICAL] fastjson 1.2.83
位置 ：myapp.jar!/BOOT-INF/lib/fastjson-1.2.83.jar
版本来源：pom.properties
场景 ：Spring Boot fat-JAR ← CVE-2026-16723 的主要在野利用场景
结论 ：命中 CVE-2026-16723（CVSS 9.0 远程代码执行），默认配置即可利用
处置 ：1.x 已停止维护，不会有修复版本。应急处置二选一：①（推荐）迁移至
fastjson2 2.0.63 或更高版本；② 无法立即迁移时，先启用 SafeMode
彻底关闭 AutoType 以缓解，但这不是长期方案。
[UNKNOWN] fastjson 版本未知
位置 ：myapp.jar!/BOOT-INF/lib/some-sdk-3.1.0.jar
版本来源：未知
场景 ：Spring Boot fat-JAR ← CVE-2026-16723 的主要在野利用场景
注意 ：疑似被 shade 进宿主 jar（有 class 但无 Maven 元数据），mvn dependency:tree 查不到它
结论 ：无法确定 fastjson 版本
汇总：CRITICAL 1 UNKNOWN 1
注意点2 —— その some-sdk-3.1.0.jar は fastjson を自身の内部にパッケージ化しており、依存関係ツリー上では全く見えません。
| バージョン | 判定 | 説明 |
|---|---|---|
| fastjson 1.2.68 ~ 1.2.83 | 🔴 CRITICAL | CVE-2026-16723 に該当、1.2.84 にアップグレードすれば修正可能 |
| fastjson ≥ 1.2.84 | 🟢 OK | 公式修正を含む（2026-07-29 リリース） |
| fastjson < 1.2.68 | 🟠 HIGH | 今回の CVE には該当しないが、過去の AutoType RCE 系脆弱性あり |
| fastjson2 ≤ 2.0.62 | 🔴 CRITICAL | ポリモーフィックデシリアライズ RCE（seeAlso パス）、デフォルト設定で発動可能 |
| fastjson2 ≥ 2.0.63 | 🟢 OK | 現在推奨バージョン |
⚠️ 特に注意：公式推奨の移行先である fastjson2 自体も ≤2.0.62 では RCE が存在します。 「すでに fastjson2 に移行済み」は安全ではありません。バージョン番号も同時に確認する必要があります。
--json 输出 JSON，便于接入流水线（恒为 UTF-8）
--utf8 强制以 UTF-8 输出（控制台中文乱码时用）
--gbk 强制以 GBK 输出（控制台中文乱码时用）
--no-color 关闭彩色输出
-h, --help 显示帮助
-v, --version 显示版本
終了コード：0 = 対応が必要な項目は未検出（かつ各ファイルが実際に読み込まれた）；1 = CRITICAL/HIGH を検出；2 = 使用方法の誤り；4 = 読み込めないファイルがある（末尾の「終了コード」セクションを参照）。
CI ゲートとしてそのまま利用可能：
java -jar fastjson-check.jar ./build/libs --json || echo "发现高危依赖，阻断发布"
誤解を避けるため、境界を正直に説明します：
com/alibaba/fastjson(2)/JSON.class というパスで識別しています。あるライブラリが shade 時にパッケージ名を com.foo.shaded.fastjson に変更している場合、検出できませんmvn clean package
# 产物：target/fastjson-check.jar
コンパイルターゲットは Java 8 なので、生成された jar はそのまま JRE 8 が動いている古いマシンに置いて実行できます。 実行時の依存はゼロ —— 調査ツールが対象環境に何かを追加すべきではありません（特に JSON ライブラリを入れるべきではありません。私たちが調べているのはまさにそれです）。
誤検知や検出漏れを見つけた場合は、Issue を開いてください。 セキュリティツールで最も恐ろしいのは、安全だと誤解させることです。どんな誤判定でも報告する価値があります。
issue を提出する際に以下の情報を添えていただけると、原因特定がずっと早くなります：
java -jar fastjson-check.jar <ターゲット> --json の出力（JSON にはパス以外の機密情報は含まれません）機能提案、新しい fastjson 関連の CVE、企業での一括調査シナリオの要望も、同様に issue で議論することを歓迎します。