本文へ移動
English version →
高 9.1 急ぎ度: 早めに

python-joseにJWT偽造の脆弱性、修正版は未確認

python-jose 3.5.0以下に、空のHMAC鍵を受け入れてJWTを偽造される脆弱性が公表されました。HS256系で検証しているPythonアプリの開発・運用者は、版と鍵の中身を確認し、修正版の有無を告知で調べてください。

CVE-2026-120459 公開 更新 執筆・監修: 佐々木 航 人が監修しながらAIを活用して執筆
画像は生成 AI で作成したイメージです

急ぎ度: 早めに

CVSS v3は7.4、v4は9.1で、認証なしに偽造トークンが通る脆弱性ですが、KEVへの掲載は確認できず、鍵が空になる構成でなければ成立しないため、至急ではなく早めの確認としています。

関係があるか

PythonアプリでJWTの検証にpython-joseを使い、HS256・HS384・HS512で署名を確認している組織が対象です。鍵を設定ファイルやJWKから読み込む構成では、鍵が空になる経路がないかが分かれ目になります。

製品影響を受ける版修正版
python-jose 3.5.0以下 修正版の版番号は、プロジェクトの課題管理(issue 398)とVulnCheckの告知で確認してください

確かめ方

  1. 1pip show python-jose で導入されている版を確認します。アプリが直接依存していなくても、他のパッケージ経由で入っていることがあります。
  2. 2コードで jwt.decode を呼んでいる箇所を探し、algorithmsにHS256・HS384・HS512が含まれるかを確認します。
  3. 3検証に渡す鍵の出どころ(環境変数、設定ファイル、シークレット管理、JWKのkなど)を追い、空文字や未設定のときに空のまま渡らないかを調べます。
  4. 4複数サービスで共通の認証基盤を使っている場合は、基盤側とアプリ側の両方で同じ確認をします。

何が起きたか

python-joseは、JWTの署名検証で長さ0のHMAC鍵をそのまま受け入れてしまいます。鍵が空だと署名の確認は意味を失い、攻撃者が好きな内容で作ったJWTを、アプリが正規のトークンとして通してしまいます。

問題があるのは、HMAC鍵を扱うHMACKeyとCryptographyHMACKeyの2つのクラスです。長さ0の鍵を拒否せず、HS256・HS384・HS512の検証が空の鍵のまま進みます。たとえば、oct形式のJWKでkが空の場合です。この状態で jwt.decode に偽造トークンが渡ると、任意のクレームを持つトークンが受理されます。

CWEの分類は署名検証の不備(CWE-347)です。ライブラリ自体が鍵の健全性を確かめないため、アプリ側の設定ミスや読み込み失敗が、そのまま認証の突破につながります。

攻撃の流れ

  1. 1

    鍵が空になる

    アプリのHMAC検証鍵が、設定やJWKの内容によって空として解決される。

  2. 2

    空鍵を受理

    python-joseが長さ0の鍵を拒否せず、そのまま検証に使う。

  3. 3

    トークンを偽造

    攻撃者が任意のクレームを入れたJWTを、空の鍵で署名して作る。

  4. 4

    検証を通過

    jwt.decodeが偽造トークンを正規のものとして受理する。

  5. 5

    なりすまし

    他のユーザーや管理者として、保護されたAPIや画面にアクセスされる。

公開されている情報をもとにした流れの例です。

どう悪用されるか

認証は不要で、ネットワーク越しに実行できます。利用者の操作も要りません。ただし、アプリの検証鍵が空になっていることが前提です。CVSS v3で攻撃の複雑さが高いと評価されているのは、この前提があるためです。

成立すると、トークンに書かれたユーザーIDや権限などのクレームを自由に決められます。保護されたAPIの情報が読まれ、操作が実行され、データが書き換えられるおそれがあります。可用性への影響は評価されていません。

今すぐやること

  1. 1

    使用中の版を洗い出す

    本番・検証を問わず、python-joseを使うサービスを一覧にします。ロックファイルやコンテナイメージまで見て、間接的な依存も拾います。

    pip show python-jose
  2. 2

    修正版の有無を確認して更新する

    プロジェクトの課題管理(issue 398)とVulnCheckの告知で、修正版の公開状況を確認します。修正版が出ていれば、その版へ更新します。

  3. 3

    検証鍵が空にならないか点検する

    鍵の読み込み元ごとに、未設定・空文字・読み込み失敗のときの挙動を確認します。空のまま検証に渡る経路があれば、起動時にエラーで止まるようにします。

  4. 4

    不審なトークンの利用跡を調べる

    鍵が空になり得た構成だった場合は、認証ログで、普段使われないユーザーIDや権限を持つリクエストがないかを確認します。

修正版がないあいだのつなぎ

修正版を当てられない間は、アプリ側で jwt.decode に鍵を渡す前に、鍵が空でないことを必ず確認し、空なら処理を中断します。許可するアルゴリズムは呼び出し側で明示して固定します。HMAC系を使う必要がなければ、公開鍵方式のアルゴリズムに切り替える方法もあります。いずれも修正版が出るまでのつなぎです。

背景

python-joseは、JWT・JWS・JWKといったJOSE関連の仕様をPythonで扱うライブラリです。ログイン後に発行するトークンの署名を検証する役目を持ち、ここが破られると、アプリは誰が何の権限で来たのかを判断できなくなります。FastAPIのドキュメントのJWT認証の例で使われてきたこともあり、Web APIの認証処理に組み込まれているケースは少なくありません。

JWTのライブラリでは、署名検証を素通りさせてしまう不具合がこれまでも報告されてきました。今回の特徴は、暗号の仕組みそのものではなく、空の鍵を拒否しないという入力の検査漏れにあることです。そのため、ライブラリを入れていても、アプリの鍵管理が正しければ影響を受けない構成があります。

よくある質問

Q.RS256など公開鍵方式で検証していれば影響しませんか。
A.影響が説明されているのは、HS256・HS384・HS512の検証です。ただし、許可するアルゴリズムを呼び出し側で明示していない場合は、実際にどの方式で検証されるかを確認してください。
Q.CVSS v3が7.4で、v4が9.1と差があるのはなぜですか。
A.ベクトルを見ると、v3は攻撃の複雑さを高とし、v4では低としたうえで、攻撃の前提条件を別の項目で評価しています。自社の対応では、点数の高低より、検証鍵が空になる経路があるかを優先して確認してください。

この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。

影響パッケージ

種類パッケージ影響を受ける版修正版
mpdavis python-jose
3.5.0 以前
—

ディストリビューション別の修正状況

各ディストリビューションが公開している、この CVE の修正パッケージ修正版は配布版ごとに違うので、リンク先で確かめてください。

原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

python-jose through 3.5.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge JWTs because HMACKey and CryptographyHMACKey accept zero-length HMAC secrets. When an application's HS256/HS384/HS512 verification key resolves to empty, such as an oct JWK with empty k, attackers can forge tokens with arbitrary claims that jwt.decode accepts.

出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく