Fastjsonに乗っ取りの穴 CVE-2026-16723、Javaの定番部品は今すぐ対処を

Javaのシステムで広く使われているデータ変換部品「Fastjson」の古いバージョンに、細工したデータを送り込むだけでサーバーを乗っ取られる恐れのある欠陥が見つかりました。管理番号はCVE-2026-16723で、危険度は最高ランクに近い「CVSS 9.0（緊急）」と評価されています。

ただし、危険度の数字だけを見て慌てる必要はありません。この欠陥が突かれるには、いくつかの条件がそろっている必要があります。逆に言えば、その条件を確認すれば「自分のシステムが対象かどうか」がはっきり分かります。この記事では、何が起きるのか、誰が対象なのか、そして対象だった場合に今すぐ何をすべきかを順番に整理します。

Fastjsonとはどんな部品で、なぜ影響が大きいのか

Fastjsonは、中国のアリババ（Alibaba Group）が公開している、Javaのプログラム向けの部品です。役割はシンプルで、「JSON」と呼ばれる文字の形式でやり取りされるデータと、プログラム内部で扱うデータとを、相互に変換します。スマホアプリとサーバーがやり取りするときや、システム同士がデータを受け渡すときに、裏側でこの変換が絶えず動いています。

この手の変換部品はどのJavaシステムにも必ず入っており、Fastjsonはその中でも定番の一つです。処理が速いことで知られ、企業の業務システムからネットサービスの裏側まで、世界中で長く使われてきました。今回問題になっているのは、その1.x系の最後のバージョンにあたる「1.2.83」を含む古い系列です。

つまり、聞いたことがない人からすれば無名の部品でも、実際にはあなたが毎日使っているサービスの裏で動いている可能性が十分にあります。中国のセキュリティ企業Qi'anxin（奇安信）は、今回の欠陥にさらされている状態のシステムが世界に「数百万規模」で存在すると見積もっています。

何が起きるのか——届いたデータだけでサーバーが乗っ取られる

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

仕組みを平たく言うと、こうです。Fastjsonは受け取ったデータを、プログラムが扱える「部品（オブジェクト）」の形に組み立て直します。この組み立ての過程で、攻撃者はデータの中に「この住所にある命令を取りに行って実行せよ」という指示を紛れ込ませることができます。サーバーはその指示に従い、攻撃者が用意した命令をインターネット越しに取りに行き、そのまま実行してしまいます。これが、外部から任意の命令を実行される「遠隔コード実行」と呼ばれる状態です。

技術的には、Fastjsonがデータの型を見分ける処理と、Spring Bootというアプリの土台が持つプログラム読み込みの仕組みが、悪いかたちでかみ合うことで成立します。攻撃者は、対象が受け取るデータの「Object」や「Map」といった自由度の高い項目の中に攻撃用のデータを入れ子にして送り込みます。セキュリティメディアの解説によれば、この一連の流れが標準の設定のまま成立してしまうことが、今回の欠陥の特徴です。

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

攻撃者は誰を狙い、何をするのか

この欠陥を狙うのは、インターネットに公開された企業やサービスのサーバーを片っ端から調べ、Fastjsonの古い版が使われている入口を探し回る攻撃者です。特定の誰かを狙い撃ちにするというより、「攻撃できる相手を機械的に見つけて回る」タイプの攻撃と相性が良い欠陥です。試作コードがすでに出回っているため、専門知識の浅い攻撃者でも同じ手口を真似しやすくなっています。

見つけた相手に対して攻撃者がすることは、細工したデータを送り込んでサーバーの上で好きな命令を実行し、そのサーバーを内側から乗っ取ることです。いったん命令を実行できてしまえば、あとはやりたい放題になります。保存されている顧客データを抜き取る、身代金要求ウイルス（ランサムウェア）を仕込む、そのサーバーを踏み台にして社内の別のシステムへ入り込む、といった動きにつながります。

被害の向く先は二方向です。サービスを使っているエンドユーザーからすれば、預けていた個人情報や決済情報が流出する恐れがあります。システムを運用する企業からすれば、サーバーの制御を奪われ、事業の停止や信用の失墜に直結します。だからこそ、次の章で「自分のシステムがそもそも対象なのか」をはっきりさせることが重要になります。

あなたのシステムは対象か——3つの条件で判定する

危険度はCVSS 9.0と高い一方で、評価の内訳を見ると「攻撃の難しさ（AC）」は高めに設定されています。これは、誰のサーバーでも即座に乗っ取れるわけではなく、いくつかの前提がそろって初めて成立するためです。公式の注意喚起とセキュリティ報道を踏まえると、次の3つがすべて当てはまる場合に危険です。

• Fastjsonの1.2.68〜1.2.83を使っている——それより古い1.2.60以前や、後継の「fastjson2」を使っている場合は、この欠陥の対象外です。
• Spring Bootの「fat-jar」形式で動かしている——「java -jar アプリ名.jar」で起動する、最も一般的な配り方です。古い「WAR」形式で動かしている場合は対象外とされています。
• 外部から届いたJSONデータを読み込む入口があり、サーバーから外向きのHTTP通信ができる——攻撃者の用意した命令を取りに行けてしまう状態のことです。

3つのうち1つでも外れていれば、この欠陥で乗っ取られる心配はありません。特に、すでにfastjson2へ移行済みの環境や、Fastjsonをそもそも使っていないシステムは、今回の件では手を打つ必要がありません。まずは自社のシステムが上の3条件に当てはまるかどうかを、開発チームに確認してもらうところから始めてください。

影響を受けるバージョン早見表

自分の使っているバージョンがどの位置にあるかを、下の表で確認できます。バージョンは、プログラムの部品一覧（Mavenのpom.xmlやGradleの設定）に書かれている「com.alibaba:fastjson」の番号で分かります。

重要なのは、1.x系にはこの欠陥をふさぐ修正版が出ないという点です。1.2.83はもともと1.x系の最後のバージョンであり、開発の主軸はすでにfastjson2へ移っています。そのため「新しい1.xに上げれば直る」という通常の手が使えず、後述する別の方法で守る必要があります。

なぜこれまでの防御策が効かないのか

Fastjsonの過去の欠陥では、「AutoType」と呼ばれる機能をオフにすることが定番の守り方でした。AutoTypeは、受け取ったデータからその種類（クラス）を自動で判定して復元する機能で、これが過去の乗っ取り攻撃の入口になっていたためです。ところが今回の欠陥は、AutoTypeをオフにしても防げません。

従来の攻撃は、攻撃に使える「踏み台になる部品（ガジェット）」がシステム内に存在することが前提でした。だから「危険な部品を使わない」「許可リストで絞る」といった対策が有効でした。しかし今回の手口は、そうした踏み台になる部品を必要としません。発見者のKirill Firsov氏は、この点を「ガジェット不要の遠隔コード実行」と表現しています。つまり、これまでの前提を崩す新しいタイプの攻撃であり、古い対策の常識がそのままでは通用しません。

この「標準設定のまま」「踏み台部品なしで」成立するという性質が、危険度を押し上げている理由です。だからこそ、次に挙げる対処は場当たり的な設定変更ではなく、根本から攻撃の成立条件を断つ方向で行う必要があります。

今すぐやるべき対処

前章の3条件に当てはまった場合、対処は次の順で検討します。上から順に優先度が高い対応です。

• まずSafeMode（安全モード）を有効にする——起動時に-Dfastjson.parser.safeMode=trueを付ける、設定ファイル（fastjson.properties）で指定する、プログラムから指定する、のいずれかで有効化できます。最も早く攻撃の成立を止められる応急処置です。
• AutoTypeを完全に外した版に差し替える——部品の指定をcom.alibaba:fastjson:1.2.83_noneautotypeに変えると、危険な自動判定の機能そのものを含まない版に切り替わります。
• 後継のfastjson2へ移行する——fastjson2は設計そのものが作り直されており、今回の欠陥の影響を受けません。根本的な解決策であり、長期的にはこの移行が本命です。
• サーバーからの外向きHTTP通信を遮断する——攻撃者の命令を取りに行けなくすることで、成立条件の一つを塞ぐ多層防御になります。

応急処置としてはSafeModeの有効化が最も手早く、まずここから着手するのが現実的です。そのうえで、時間をかけてfastjson2への移行を進めるのが望ましい流れです。自社が使っている部品にどんな脆弱性が潜んでいるかを継続的に洗い出したい場合は、部品（OSS）の脆弱性を自動で点検する仕組みの解説もあわせて参考にしてください。

すでに攻撃は始まっているのか

記事公開の時点では、この欠陥が実際の攻撃に使われたという確認された報告はありません。ただし油断はできません。発見者による公表のあと、第三者による攻撃の試作コード（PoC）がすでに公開されており、誰でも手口を再現しやすい状態になっています。試作コードが出回ってから実際の攻撃が始まるまでの時間は年々短くなっており、「まだ攻撃されていないから大丈夫」とは言い切れません。

米政府機関のCISAが公開する「実際に攻撃が確認された欠陥のリスト（KEV）」にも、現時点でこの欠陥は載っていません。とはいえ、これは「まだ載っていない」だけであり、状況が変われば追加される可能性があります。最新の掲載状況はCISAの攻撃確認リストの日本語まとめで確認できます。対象に当てはまるシステムは、KEVへの掲載を待たずに先手で対処しておくのが安全です。

発見者はこう警告している

今回の欠陥を発見・報告したのは、セキュリティ企業FearsOffのKirill Firsov氏です。同氏は自身のXへの投稿で、この欠陥の性質を次のように説明しています。

発見者本人が「最も広く使われている部品の一つ」と指摘している通り、影響が及ぶ範囲の広さがこの欠陥の本当の怖さです。数字上の危険度だけでなく、「どこにでも入っている部品だからこそ、気づかないうちに対象になっている」という点に注意が必要です。

これから何に注意すべきか

ここまでを整理すると、今回の欠陥は危険度こそ緊急レベルですが、慌てて全システムを止めるような話ではありません。まず「Fastjsonの1.2.68〜1.2.83を、Spring Bootのfat-jar形式で、外部データを読み込む入口とともに使っているか」を確認し、当てはまらなければ今回は対処不要です。当てはまった場合は、SafeModeの有効化を応急処置として最優先で行い、そのうえでfastjson2への移行を計画します。

今後の注目点は、実際の攻撃が観測され始めるかどうか、そしてCISAの攻撃確認リスト（KEV）に追加されるかどうかです。修正版が出ない性質上、対象システムはいずれfastjson2への移行が避けられません。続報や掲載状況の変化があれば、この記事に追記していきます。CVE-2026-16723の公式情報も、あわせて確認しておくと安心です。

参照元

• ▸ NVD - CVE-2026-16723 Detail
• ▸ Alibaba - Security Advisory: Remote Code Execution in fastjson 1.2.68–1.2.83（2026年7月21日）
• ▸ SC Media - Fastjson library affected by high-severity RCE bug
• ▸ SecurityOnline - Public PoC Exploit Released for fastjson 1.2.83 Remote Code Execution Flaw
• ▸ Kirill Firsov（FearsOff）- X投稿（2026年7月19日）
• ▸ GitHub - alibaba/fastjson2（後継版・移行先）