ログイン連携の土台『Spring Authorization Server』に緊急の脆弱性、悪用でなりすまし・情報流出の恐れ CVE-2026-22752、7.0.5などへ更新を
企業システムのログイン連携に使われるJava基盤『Spring Authorization Server』に、危険度9.6の緊急の脆弱性CVE-2026-22752が公表されました。動的クライアント登録を有効にしている場合、細工したデータでなりすまし・権限昇格・社内探索につながる恐れがあります。対策は7.0.5や1.5.7への更新、または動的登録の無効化です。
目次
企業システムのログイン連携に使われるJava基盤『Spring Authorization Server』に、危険度9.6の緊急の脆弱性CVE-2026-22752が公表されました。動的クライアント登録を有効にしている場合、細工したデータでなりすまし・権限昇格・社内探索につながる恐れがあります。対策は7.0.5や1.5.7への更新、または動的登録の無効化です。
企業システムのログイン連携(認可)の土台として広く使われる「Spring Authorization Server」に、危険度の高い脆弱性(CVE-2026-22752)が公表されました。危険度はCVSS(脆弱性の深刻度を10点満点で表す共通指標)で9.6と、最上位の「緊急(Critical)」に区分されます。
Spring Authorization Serverは、多くのWebサービスやアプリで採用されているJava向けの開発基盤「Spring」の一部で、外部サービスとの安全なログイン連携(OAuth2/OpenID Connect)を実現する認可サーバーを構築するための部品です。今回の欠陥は、この認可サーバーがある機能を有効にしているとき、攻撃者に悪用され、なりすましや情報流出につながる恐れがあります。
ただし、誰でも無条件に悪用できるわけではありません。悪用には2つの前提があり、それを満たすシステムは限られます。今実際に攻撃された報告はまだありませんが、内容が公開された以上、対象のシステムは早めの対処が必要です。何が起きるのか、自分のシステムは対象か、どう直すのかを順に説明します。オープンソースの部品を通じて気づかないうちに抱えているケースもあるため、依存関係の点検にはOSSサプライチェーンの考え方も役立ちます。
何が起きるのか
ひとことで言うと、「認可サーバーに、外部から自由にアプリを登録できる窓口(動的クライアント登録)」が開いているとき、その窓口の入力チェックが甘く、細工したデータを送り込まれてしまう、という問題です。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-22752 |
| 対象 | Spring Authorization Server (Spring Security) |
| 危険度 | CVSS 9.6(緊急) |
| 脆弱性の種類 | クライアント情報の検証不備 (なりすまし・情報流出につながる) |
| 悪用の前提 | 動的クライアント登録が有効 +有効な初期アクセストークンの保持 |
| 実際の攻撃 | 現時点で報告なし |
| 対策 | 修正版へ更新 (または動的登録を無効化) |
ここで鍵になるのが「動的クライアント登録(Dynamic Client Registration)」という機能です。通常、認可サーバーに連携するアプリ(クライアント)は管理者が事前に登録します。これに対して動的クライアント登録は、決められた手続きを踏めば外部から自動でアプリを登録できる仕組みで、多数の連携先を扱うサービスで使われます。この動的クライアント登録の仕組み(RFC 7591)をあえて有効にしている場合にのみ、今回の脆弱性の影響を受けます。既定では無効のため、有効化していないシステムは対象外です。
誰が、何のために狙うのか
この脆弱性を悪用できるのは、動的クライアント登録を利用するための「初期アクセストークン」と呼ばれる正規の引換券を持っている相手です。まったくの部外者がいきなり悪用できるわけではなく、登録手続きに入れる立場の利用者や、その引換券が漏れた場合の攻撃者が想定されます。連携先を広く受け入れているサービスほど、この引換券を持つ人の範囲が広がります。
その相手が行うのは、細工したアプリ情報を登録して、管理画面を見た人のブラウザで不正なスクリプトを動かしたり、本来の権限を超える操作をしたり、サーバーに裏で別の場所へ通信させたりすることです。認可サーバーは「誰にログインを許すか」を判断する中枢であり、ここを揺さぶられると、なりすましログインや、社内ネットワーク内部への探りといった被害に発展しかねません。
被害が認可サーバーの管理者だけにとどまらないのもこの問題の怖さです。認可サーバーはそのサービスを使う多数の利用者のログインを束ねているため、乗っ取られれば、そのサービスを使う一般の利用者のアカウントや個人情報にも危険が及びます。「認証・認可の土台」が崩れると影響範囲が広いという点で、深刻度9.6という数字がついています。
技術的に見ると
開発元のSpringが公開したセキュリティ情報によると、原因は動的クライアント登録エンドポイントが、登録時に送られてくるクライアントのメタデータ(アプリ名や連携先URLなどの付随情報)を十分に検証していなかったことにあります。
有効な初期アクセストークンを持つ攻撃者は、このメタデータに悪意ある値を仕込んだうえでクライアントを登録できます。仕込まれた値は、認可サーバーの管理画面や同意画面などで表示・利用される過程で、次の3つの被害につながり得ます。1つ目は、管理画面を開いた人のブラウザで不正なスクリプトが実行される保存型のクロスサイトスクリプティング(Stored XSS)。2つ目は、本来の権限を越えて操作できてしまう権限昇格。3つ目は、サーバーが攻撃者の指定した内部の場所へ通信させられるサーバーサイドリクエストフォージェリ(SSRF)です。
とくにSSRFは、外部から直接は届かない社内システムへの入り口になりやすく、認可サーバーが置かれるネットワークの内側を探る足がかりにされる恐れがあります。いずれも「入力を信用して処理してしまう」という古典的な弱点の組み合わせですが、それが認証・認可の中枢で起きるため影響が大きくなっています。
影響を受けるバージョンと修正版
影響範囲と修正版は次のとおりです。自分のシステムが使っているバージョン系列を確認し、右端の修正版へ更新してください。1.3系と1.4系の修正版は、商用のSpring Enterpriseサブスクリプションの利用者に提供される点に注意が必要です。
| バージョン系列 | 影響を受ける版 | 修正版 | 入手方法 |
|---|---|---|---|
| 7.0 系(Spring Security) | 7.0.0 〜 7.0.4 | 7.0.5 | OSS(無償) |
| 1.5 系 | 1.5.0 〜 1.5.6 | 1.5.7 | OSS(無償) |
| 1.4 系 | 1.4.0 〜 1.4.9 | 1.4.10 | Enterprise 契約者のみ |
| 1.3 系 | 1.3.0 〜 1.3.10 | 1.3.11 | Enterprise 契約者のみ |
OSS版を使っていて1.3系・1.4系にとどまっている場合は、修正版が無償では提供されないため、サポートが続く新しい系列(1.5系や7.0系)への移行を検討することになります。すぐに更新できない事情がある場合の当面の回避策は、次の章で触れる「動的クライアント登録の無効化」です。
いま何をすればいいのか
対応は大きく2段構えです。まず、自分のシステムがそもそも対象かを見極めます。Spring Authorization Serverを使っていて、かつ動的クライアント登録を有効にしている場合だけが、実際の危険にさらされます。多くのシステムは動的登録を使っていないため、その場合は慌てる必要はありません。
対象だった場合の最善策は、修正版(7.0.5または1.5.7、Enterprise契約者は1.4.10・1.3.11)へ更新することです。すぐに更新できない場合の当面の回避策として、運用上どうしても必要でなければ動的クライアント登録を無効にすることで、この脆弱性は事実上ふさげます。開発元も、更新以外の追加の緩和手順は不要としています。
見落としやすいのが、自分では直接使っていなくても、別のライブラリや製品の内部でSpring Authorization Serverが取り込まれているケースです。オープンソースの部品は、依存関係の奥に埋もれて気づきにくいことがあります。使っているソフトの構成に不安がある場合は、依存関係を洗い出すという観点でOSSサプライチェーンの点検もあわせて確認しておくと安心です。過去には同じSpring系のSpring AIの脆弱性も報じられており、Springを使う現場では定期的なパッチ適用が欠かせません。
まとめ
CVE-2026-22752は、Spring Authorization Serverの動的クライアント登録における入力チェックの甘さを突く脆弱性です。危険度はCVSS 9.6と高いものの、悪用には「動的クライアント登録が有効」「有効な初期アクセストークンを持つ」という2つの前提が必要で、対象となるシステムは限られます。まずは自分のシステムがこの条件に当てはまるかを確認するのが出発点です。
当てはまる場合は、修正版(7.0.5・1.5.7など)への更新が最優先です。すぐに動けないときは動的登録を一時的に無効化して急場をしのぎ、そのうえで計画的に更新を進めます。実際の攻撃はまだ確認されていませんが、認証・認可の土台に関わる欠陥だけに、対象システムは先送りせず対処するのが賢明です。新しい情報や攻撃が確認され次第、この記事に追記します。
参照元

堀川 慎
Backend Engineer / AWS / Django / Go