企業の API（システム同士の窓口）をまとめて管理する WSO2 API Manager などに、偽造したトークンで管理者になりすませる脆弱性 CVE-2026-5430 があり、悪用の試みが観測されている。CVSS は報道では 9.8、WSO2 の CVE レコードでは 10.0[1][2][3]。
PART 1解説
3行でわかる要点
- 何が起きるか：JWT による認証が、サポートしていないアルゴリズムで署名されたトークンを受け入れ、そのまま承認してしまう[1][3]。
- 影響：管理者アカウントを含むアカウントの乗っ取り。API Manager 4.1.0〜4.6.0、API Control Plane、Traffic Manager、Universal Gateway が対象[1][3]。
- 悪用：watchTowr のおとりのサーバー（ハニーポット）に、2026年9月13日、管理者権限を書き込んだ偽造トークンが届いた[3]。
前提：API ゲートウェイと JWT
多くの企業システムは、機能を API として公開し、アプリ同士がそれを呼び合って動いています。API ゲートウェイは、その呼び出しを受け付ける共通の入口で、相手が誰かを確かめ（認証）、使ってよい API かを判断して（認可）から内部のシステムに中継します。WSO2 API Manager はこの入口を担う製品です。
認証の手段としてよく使われるのが JWT で、ログイン後に発行された通行証を毎回の呼び出しに添えます。入口が通行証の確認を誤ると、その奥にあるすべての API が危険にさらされます。
まず押さえる用語
| 用語 | ひとことで | もっと詳しく |
|---|---|---|
| CVE / CVSS | 脆弱性の世界共通の番号と、深刻度を 0.0〜10.0 で表す指標。 | IPA「共通脆弱性評価システムCVSS概説」 |
| API ゲートウェイ | 外部からの API 呼び出しを受け付け、認証してから内部のシステムに中継する入口。 | — |
| JWT | 「誰がどんな権限を持つか」を JSON で書き、電子署名を付けた通行証。受け取った側は署名を確かめて本物かを判断する。 | RFC 7519（IETF） |
| 署名アルゴリズム | 署名の作り方の種類（RS256 など）。受け取る側は、決めた方式以外の署名を拒否するのが原則。 | — |
| 署名検証の不備 | 電子署名を正しく確かめないために、偽物を本物として受け入れてしまう欠陥。 | CWE-347（MITRE） |
本来の仕組みと、どこが破られたか
JWT は「この人は管理者」といった情報に電子署名を付けた通行証です。受け取る側は、まず署名の方式が自分の決めたものかを確かめ、次に正規の鍵で署名を検証します。
WSO2 の製品は、サポートしていない方式で署名されたトークンを拒否せず、承認していました[1][3]。図1の赤い破線が、抜けていた「署名方式の確認」です。そこを通ってしまえば、攻撃者は自分で書いた「管理者」の通行証を使えます。
攻撃の流れ
sequenceDiagram
autonumber
participant A as 攻撃者
participant W as WSO2 API Manager
participant B as 内部のAPI
A->>A: 管理者権限を書いたJWTを自作
A->>W: 偽造トークンを送信
W->>W: サポート外の署名方式でも承認
W-->>A: 管理者としてアクセスを許可
A->>B: 登録済みアプリの鍵や秘密情報を取得
- 1〜4：JWT の中身は誰でも書けるため、署名の確認が甘いと「管理者です」と書いただけの通行証が通る[1][3]。
- 5：watchTowr は、偽造トークンで全 API の接続先とその認証情報、登録アプリの鍵や秘密情報が狙われたとみている[3]。
なぜ「古い穴」がまた出てくるのか（考察）
- JWT の
alg: none（署名なし）問題やアルゴリズムの取り違えを狙う攻撃は、以前から知られている。 - それでも繰り返すのは、ライブラリと呼び出し側の責任の境目にある。ライブラリが内部で安全でも、呼び出し側が「受け入れる方式」を指定しなければ穴になる。
- API ゲートウェイは内部へのリクエストの通り道なので、乗っ取られると通信の盗み見や内部サービスへのアクセスに使える。watchTowr はこれを「横移動のためのサービス」と表現した[3]。
いま確認すること
- 【WSO2 を使っている】アドバイザリの更新レベル（API Manager 4.5.0 は Update level 57 など）を適用する。コミュニティ版は公開された修正を取り込む[1][3]。
- 【全員】自分のコードで JWT を検証するとき、受け入れるアルゴリズムを明示して固定しているか確かめる。
# 危険：アルゴリズムを指定していない
payload = jwt.decode(token, public_key, options={"verify_exp": True})
# 安全：受け入れるアルゴリズムを明示して固定する
payload = jwt.decode(token, public_key, algorithms=["RS256"])- 【全員】kid（鍵の ID）を見て、正規の鍵の一覧から検証に使う鍵を選んでいるか確かめる。
- 【全員】使っている JWT ライブラリが
alg: noneを受け入れないことを、ドキュメントか単体テストで実際に確かめる。
出典・参考リンク
一次情報
報道・解説
PART 2問題（情報処理安全確保支援士 試験形式）
問1 午前II形式（4択）
JWT を検証するサーバ側の実装として、WSO2 API Manager の CVE-2026-5430 と同種の署名バイパスを防ぐのに最も有効なものはどれか。
- ア トークンのペイロードを Base64 でデコードできるかを確認する
- イ 署名部が空でないことを確認してから受け入れる
- ウ 受け入れる署名アルゴリズムを固定し、kid に対応する正規の鍵で署名を検証する
- エ トークンの有効期限（exp）を短く設定する
解答・解説を表示
解答：ウ
WSO2 は、サポートしていない方式で署名されたトークンも承認していた。algorithms=["RS256"] のように受け入れる方式を明示し、kid から正規の鍵を引いて検証する。イは署名が「ある」ことしか見ておらず、偽造を防げない。アはデコードできるだけで改ざんを検知できない。エは偽造トークンが通る時間を短くするだけで、期限内なら通ってしまう。
問2 午後形式（記述）
A社は、自社 API の認可に JWT を使っている。開発者の C さんは、JWT ライブラリの decode 関数に公開鍵と有効期限チェックのオプションだけを渡しており、①受け入れる署名アルゴリズムを指定していなかった。WSO2 API Manager の CVE-2026-5430 の報道を受けて、A社はこのコードを見直すことにした。
設問 本文中の下線①の状態で運用を続けた場合に起こりうる問題を、50字以内で述べよ。
解答・解説を表示
解答例：ライブラリによっては alg: none の署名なしトークンを受け入れ、偽造トークンが通る（45字）
アルゴリズムを指定しないと、ライブラリによっては alg: none（署名なし）を黙って受け入れる。ライブラリ自体が安全でも、呼び出し側が一手間を省くと穴になる。「有効期限切れのトークンが通る」は、有効期限のチェックを指定しているので誤り。