Fastjsonとは？脆弱性CVE-2026-16723と安全なバージョン1.2.84

Fastjsonは、中国のアリババが公開しているJava向けの部品で、JSON（システム同士がデータをやり取りするときの標準的な書式）とプログラム内部のデータとを相互に変換します。この部品の1.2.68から1.2.83までのバージョンに、細工したデータを送りつけるだけでサーバーを乗っ取られる恐れのある欠陥「CVE-2026-16723」があります。直っているのは、2026年7月29日に公開された1.2.84です。

同じ7月29日に、Fastjsonの開発場所（GitHubのリポジトリ）は読み取り専用になりました。1.2.84が1.x系の最後の版で、今後1.xに新しい版が出ることはありません。後継は別の名前で作り直された「fastjson2」で、こちらは今回の欠陥の対象外です。

Fastjsonとは何をする部品か

Fastjsonの仕事は一つで、JSONという文字の形で書かれたデータと、Javaのプログラムが内部で扱うデータとを、行き来させることです。スマホのアプリがサーバーへ注文を送るとき、社内のシステム同士が在庫の数をやり取りするとき、その中身はたいていJSONで書かれています。受け取った側は、その文字列をプログラムが扱える形に組み立て直さなければなりません。その組み立てを担当するのがFastjsonです。

この役割の部品はJavaのシステムにはほぼ必ず入っており、Fastjsonはその中でも古くからある定番の一つです。処理が速いことを売りに、業務システムからネットサービスの裏側まで長く広く使われてきました。GitHubの開発場所に付いた星（気に入った人が押す印）はおよそ2万5600、複製して手を加えた枝分かれはおよそ6400です。

直接使っていなくても入り込んでいることがあります。部品の依存関係をたどるdeps.devで見ると、1.2.83に依存している公開部品は5,050件、そのうち直接指定しているものは1,475件と出ます。残りは「使っている部品がさらにFastjsonを使っている」という形で入っているものです。自社のコードにFastjsonと書いていなくても、別の部品を通じて同梱されている場合があるということです。

Javaのプロジェクトでは、部品はMavenのpom.xmlやGradleの設定に「グループ名:部品名:バージョン」の形で書きます。Fastjsonの場合はcom.alibaba:fastjsonです。この書き方は、次の節で説明する「最新版がどれか」の話にそのまま関わってきます。

いま使うべきバージョンはどれか

1.x系を使い続けるなら、行き先は1.2.84です。1.2.83が出たのが2022年5月23日、1.2.84が出たのが2026年7月29日で、4年2か月ぶりの更新でした。この間隔からも分かるとおり通常の機能追加ではなく、後継のfastjson2で採られていた対策を1.x系へ移し替えた、安全のためだけの版です。

ここで引っかかりやすいのが、com.alibaba:fastjsonという同じ指定の「最新版」は1.2.84ではないという点です。配布元のMaven Centralに登録されている最新は2.0.64で、その中身はfastjson2側が用意した1.x互換の部品です。2.0.64の定義ファイルを開くと、名前がfastjson1-compatible、親がfastjson2、参照先がalibaba/fastjson2になっています。Maven Centralの一覧で最新版を調べると1.2.84ではなく2.0.64が出てくるため、どちらが新しいのか分からなくなりがちです。バージョンを固定せず最新を取る書き方をしている場合は、1.x系ではなく2系の互換部品が入ります。

今回の欠陥に関しては、この3つのどれを選んでも対象外になります。ただし互換部品は名前のとおり「1.xのつもりで書いたコードが動くようにした別実装」であり、そっくり同じ動きをするとは限りません。実際、2.0.64の公開時の記録には互換部品側の不具合修正が3件並んでいます。差し替えるなら試験は必要です。

自分が使っているバージョンを確かめる

確認の方法は、ビルドの定義から見る方法と、実際に動かしている成果物から見る方法の2通りです。他の部品に引きずられて入ってきている場合があるので、定義だけでなく成果物の側も見ておくと確実です。

• Mavenの場合：mvn dependency:tree -Dincludes=com.alibaba:fastjson を実行すると、どの部品を経由して入っているかまで出ます
• Gradleの場合：./gradlew dependencies --configuration runtimeClasspath の出力からfastjsonの行を探します
• できあがったjarから見る場合：jar tf アプリ名.jar | grep fastjson（unzip -lでも同じ）で、同梱されているfastjson-1.2.83.jarのようなファイル名が出ます。Spring Bootのfat-jarならBOOT-INF/lib/の下にあります

気をつけたいのが、プログラムからJSON.VERSIONを読んで確かめる方法です。これは1.2.84では当てになりません。当サイトでMaven Centralから1.2.84のjarを取得して中身を確認したところ、com.alibaba.fastjson.JSONクラスのVERSIONという値は1.2.83のまま更新されていませんでした。1.2.83のjarと1.2.84のjarで、この値は同じです。更新したのに古い番号が返るため、まだ直っていないと誤解する恐れがあります。

jarの中から確実に読み取るなら、META-INF/maven/com.alibaba/fastjson/pom.propertiesを見てください。こちらは1.2.84のjarでversion=1.2.84と正しく入っています。

CVE-2026-16723で何が起きるのか

攻撃に必要なのは、細工したJSONを一度送りつけることだけです。パスワードを盗む必要も、内部に入り込む必要もありません。外から届いたデータをFastjsonが読み込む、その瞬間に問題が起きます。

Fastjsonは受け取ったデータを、プログラムが扱える部品の形に組み立て直します。その途中で「これは何という種類のデータか」を表す名前を扱う場面があり、ここに本来ありえない文字を混ぜた文字列を渡すと、Fastjsonがそれを名前ではなく取りに行く先として解釈してしまいます。Spring Bootの「fat-jar」形式は、アプリ本体と部品のjarを一つのjarに入れ子で収めて配る形式で、その入れ子を読むための専用の読み込み機構を持っています。この機構が、攻撃者の指定した外部の場所まで素直に取りに行ってしまうことで、送り込まれた命令がそのまま実行されます。開発元の注意喚起は、この流れがSpring Boot 2系・3系・4系、Java 8・11・17・21のいずれでも成立することを確認したと書いています。

受け取る側で型を指定していれば安全、という考え方は通用しません。開発元はJSON.parseObject(body, SomeDto.class)のように受け取る型を明示していても対策にならないと明記しています。指定した型の中に自由度の高い項目（ObjectやMapで受ける項目）が一つでもあれば、そこに攻撃用のデータを入れ子にして送り込めるためです。JSON.parse、JSON.parseObject(String)、JSON.parseObject(String, Class)のいずれも入口になります。

発見して報告したのは、セキュリティ企業FearsOffのKirill Firsov氏です。同氏はこの欠陥を「踏み台になる部品を必要としない遠隔操作」と表現しています。従来この種の攻撃には、システム内に都合よく置かれている踏み台の部品が必要でしたが、今回はそれが要りません。

受け取ったデータをそのまま元の形に戻す処理を悪用する攻撃は、Fastjsonに限った話ではありません。Apache MINAで見つかった同種の欠陥など、Javaの世界で繰り返し問題になってきた古くからの弱点です。

対象かどうかは3つの条件で決まる

危険度はCVSS 9.0と高いものの、評価の内訳では「攻撃の難しさ」が高めに設定されています。誰のサーバーでも即座に乗っ取れるわけではなく、前提がそろって初めて成立するためです。開発元の注意喚起によれば、次の3つがすべて当てはまるときに危険です。

• Fastjsonの1.2.68〜1.2.83を使っている。1.2.67以前、1.2.84、fastjson2は対象外です
• Spring Bootのfat-jar形式で動かしている。java -jar アプリ名.jarで起動する、最も一般的な配り方です
• 外部から届いたJSONを読み込む入口があり、サーバーから外向きの通信ができる。攻撃者の用意した命令を取りに行けてしまう状態のことです

開発元は、当てはまらない場合も表にして示しています。TomcatやJettyという土台のソフトへ載せて動かすWAR形式の場合、部品を展開して1枚にまとめたuber-jarの場合、Spring Bootを使わない普通のjarの場合は、いずれも成立条件を満たしません。設定でSafeMode（安全モード）を有効にしている場合と、AutoType（受け取ったデータの中の指定に従って、復元するデータの種類を自動で決める機能）そのものを外したnoneautotype版を使っている場合も対象外です。

3つのうち1つでも外れていれば、この欠陥で乗っ取られる心配はありません。まずは自社のシステムが上の条件に当てはまるかどうかを、開発を担当しているところに確認してもらうところから始めてください。

バージョン別の対応早見表

今回の欠陥だけでなく、そのバージョンに他の登録済みの欠陥が残っているかどうかもあわせて示します。脆弱性データベース「OSV」で1件ずつ照会した結果です（2026年8月20日確認）。

脆弱性を自動で検出する仕組みを使っている場合、1.2.84へ上げても更新先の案内が空欄のままになることがあります。検出の元になるGitHubの脆弱性データベースの登録では、対象範囲は1.2.68〜1.2.83と正しく入っている一方、「修正されたバージョン」の欄が空のままだからです。1.2.84は対象範囲から外れているため警告そのものは消えますが、道具が行き先を教えてくれない点は知っておいてください。

AutoTypeを切っていても防げない

Fastjsonの過去の欠陥では、「AutoType」と呼ばれる機能をオフにすることが定番の守り方でした。AutoTypeは、受け取ったデータから「これは何という種類のデータか」を自動で判定して復元する機能で、これが過去の乗っ取り攻撃の入口になっていたためです。ところが今回の欠陥は、AutoTypeをオフにしていても防げません。開発元の注意喚起も、AutoTypeがオフ、SafeModeもオフという何も設定していない初期状態で成立すると書いています。

従来の攻撃は、踏み台になる部品がシステム内に存在することが前提でした。だから「危険な部品を使わない」「許可する名前を絞る」といった対策が効きました。今回の手口はその踏み台を必要としないため、これまでの前提を崩しています。古い対策の常識がそのままでは通用しない、というのがこの欠陥の性質です。

対処の優先順位

開発元は、対処を優先度つきで示しています。以下はその順番をそのまま写したものです。上の3つは同じ最優先の扱いで、どれか一つを選べば足ります。

• 最優先：1.2.84へ更新する。部品の指定をcom.alibaba:fastjson:1.2.84に変えます。設定を変えずに済むため、動かしているものへの影響がいちばん小さい選択です
• 最優先：または SafeMode を有効にする。起動時に-Dfastjson.parser.safeMode=trueを付ける、設定ファイルfastjson.propertiesで指定する、プログラムからParserConfig.getGlobalInstance().setSafeMode(true)を呼ぶ、のいずれかです。部品を差し替えられない事情があるときの手です
• 最優先：または noneautotype 版に差し替える。部品の指定をcom.alibaba:fastjson:1.2.83_noneautotypeに変えると、問題になっている機能を含まない版になります
• 次点：fastjson2へ移行する。設計そのものが作り直されており、初期設定のままで安全とされています。1.x系がすでに終わっている以上、長い目で見ればここが行き先です

これに加えて、サーバーから外向きの通信を必要な相手だけに絞っておくと、攻撃者の命令を取りに行けなくなり、成立条件の一つを塞げます。今回に限らず効く備えです。自社が使っている部品にどんな欠陥が潜んでいるかを継続して洗い出したい場合は、部品の脆弱性を自動で点検する仕組みの解説もあわせて参考にしてください。

1.2.84で何が変わったのかは、配布されているjarの中身からも確かめられます。当サイトで1.2.83と1.2.84のjarを展開して比べたところ、1.2.84には型名に使えない文字が混ざっていないかを調べる処理（hasIllegalTypeNameChars）、許可した名前を文字として照合し直す処理（normalizeAcceptName）、拒否対象の判定（isAutoTypeDenyClass）が新しく入っており、javax/sql/DataSourceとjavax/sql/RowSetという踏み台になりやすい種類への言及も加わっていました。公開時の記録に挙げられている4点の修正と対応しています。

攻撃の試作コード（PoC）は出回っているのか

出回っています。GitHubで「CVE-2026-16723」を名前か説明に含む公開リポジトリを数えると、2026年8月20日時点で9件ありました。最も新しいものは8月19日に作られています。番号を含まないものまで含めると、Fastjson 1.2.83の遠隔操作を扱うリポジトリはさらに多く、7月20日に作られた検証環境付きのものには星が200を超えています。

そして、この欠陥を狙う通信はすでに観測されています。防御製品を提供するImpervaは2026年7月24日に、金融・医療・小売など米国の組織を中心にこの欠陥を狙う通信が届いていると自社の記録から報告しました。中国のThreatBookも7月22日に同様の観測を公表しています（The Hacker Newsによる）。ただしどちらも、乗っ取りに成功した事例や被害を受けた組織の名前は出していません。公表されているのは攻撃の試みが届いたという記録であって、被害が起きたという確認ではありません。

公的な扱いはこれと食い違っています。米政府機関CISAが公開している「実際に攻撃が確認された欠陥の一覧」に、この欠陥は収録されていません（2026年8月19日版・全1,671件を照合）。CISAの評価も、悪用の観測は「なし」、自動化のしやすさは「しにくい」のままです。今後30日以内に悪用が観測される確率の推定値（EPSS）は0.413％で、全体の中では低いほうから3割強の位置です（2026年8月19日時点）。

公的な一覧に載っていないことを「まだ安全」と読むのは危険です。試作コードは公開の直後から出回り、それを使ったとみられる通信は翌週には届き始めています。対象に当てはまるシステムは、収録を待たずに先に手を打ってください。最新の収録状況はCISAの攻撃確認リストの日本語まとめで確認できます。

fastjson2に乗り換えれば安全か

今回の欠陥については対象外です。開発元は、fastjson2には問題の原因になっている処理そのものが無いと説明しています。名前から取りに行く処理を持たない、種類の判定は許可した一覧に載っているものだけを通す、AutoTypeは初期状態で無効、といった点が理由に挙げられています。OSVでcom.alibaba.fastjson2:fastjson2を照会しても、2.0.62・2.0.63・2.0.64のいずれにも登録された欠陥はありませんでした（2026年8月20日確認）。

ただし、fastjson2を使っているなら2.0.63以降にしてください。今回とは根本原因の異なるAutoTypeまわりの問題が、中国のセキュリティ企業・長亭科技からの報告を受けて2.0.63で直っています。細工したデータで処理を止められる問題も同じ版で直っています。桁数の多い数値を送りつけられると計算が急に重くなる不具合と、実際より大きなデータの長さを宣言されるとメモリを使い果たす不具合の2種類です。これらには、2026年8月20日時点でCVE番号が付いていません。

移行のしかたは2通りあります。部品の指定をcom.alibaba:fastjson:2.0.64にすると、指定を書き換えずに中身だけがfastjson2の互換部品へ入れ替わります。com.alibaba.fastjson2:fastjson2:2.0.64へ書き換えれば本体をそのまま使えますが、呼び出し方の書き直しが要ります。どちらにしても互換部品は別実装なので、動作の確認は省けません。

Fastjsonのこれまでの脆弱性

Fastjson本体の欠陥として登録されているのは、GitHubの脆弱性データベースで数えて4件です（2026年8月20日確認）。1.2.84はこの4件すべての対象範囲から外れています。

この4件と、世の中で「Fastjsonの脆弱性」として語られる件数は一致しません。米国の脆弱性データベースNVDで「fastjson」を検索すると19件出ますが、そのうち16件はFastjsonを組み込んだ他社の製品の側に付けられた番号です。業務システムや監視ツールが古いFastjsonを同梱したまま外部からのデータを受け取っていた、という形の登録が並びます。残る3件だけが本体のもので、上の表の4件のうちCVE-2022-25845は、説明文がcom.alibaba:fastjsonという部品の指定の形で書かれているため、この検索には出てきません。数え方によって件数が動くということです。自社が使っているのがFastjsonそのものなのか、Fastjsonを内包した製品なのかで、見るべき番号が変わります。

参照元

• ▸ Alibaba - Security Advisory: Remote Code Execution in fastjson 1.2.68–1.2.83（2026年7月21日公開・7月29日更新）
• ▸ GitHub - fastjson 1.2.84 リリースノート（2026年7月29日）
• ▸ GitHub - alibaba/fastjson（読み取り専用）／alibaba/fastjson2（後継）
• ▸ GitHub - fastjson2 2.0.63 リリースノート（別件のAutoType対策）／2.0.64
• ▸ NVD - CVE-2026-16723 Detail
• ▸ GitHub Advisory Database - GHSA-crf3-v9rr-v7hj
• ▸ Maven Central - com.alibaba:fastjson の配布一覧／deps.dev の依存状況
• ▸ CISA - Known Exploited Vulnerabilities Catalog（2026年8月19日版で未収録を確認）
• ▸ SecurityOnline - Public PoC Exploit Released for fastjson 1.2.83（2026年7月22日・試作コードの公開）
• ▸ Imperva - Imperva Customers Protected Against CVE-2026-16723（2026年7月24日・攻撃の観測）／The Hacker News - Fastjson 1.x RCE Vulnerability Targeted in Attacks（2026年7月25日）／SecurityWeek - Unpatched Fastjson Vulnerability Exploited in Attacks（2026年7月28日）
• ▸ SC Media - Fastjson library affected by high-severity RCE bug（2022年6月17日・今回とは別のCVE-2022-25845についての記事）
• ▸ Kirill Firsov（FearsOff）- X投稿（2026年7月19日）

更新履歴

• 2026年8月20日：バージョンの確かめ方、fastjson2側の状況、Fastjson本体のこれまでの脆弱性一覧を追加。1.2.84のjarを展開してJSON.VERSIONが1.2.83のままであることと、公開時の記録にある修正がクラスに入っていることを確認して追記。攻撃コードの公開状況、CISAの攻撃確認リスト、EPSSの値を取り直し。あわせて訂正。「実際の攻撃は確認されていない」と書いていましたが、7月22日以降、この欠陥を狙う通信を観測したという報告が防御製品の提供元から複数出ています。被害の確認例は公表されていないという点だけが正しく、攻撃の試み自体は届いています。
• 2026年8月7日：訂正。公開時（7月27日）の本文で「1.x系にこの欠陥をふさぐ修正版は出ない」「fastjson2への移行が避けられない」と書きましたが、誤りでした。その2日後の7月29日に1.2.84が公開されています。あわせて、同じ日にFastjsonの開発場所が読み取り専用になったことを確認しました。
• 2026年7月27日：公開。