CVE-2026-59884は、Azure Linux 3.0のpython-pyasn1に含まれるBER/CER/DERデコーダーが、長さを制限せずにlong-form tag IDを処理することでCPU資源を大量に消費し、サービス拒否につながる脆弱性です。
MSRCが示す影響対象は0.4.8-2、修正版は0.4.8-3です。管理者が最初に行うべき対応は、実際にインストールされるRPMパッケージpython3-pyasn1のバージョンを確認し、0.4.8-3以上へ更新することです。更新後は、pyasn1を読み込んでいる常駐プロセスの再起動、またはコンテナイメージの再ビルドと再配備も必要です。(Microsoft Security Response Center)
注意したいのは、Azure Linuxの0.4.8-3と、上流pyasn1の修正版0.6.4は、バージョン番号の比較だけでは判断できない点です。Azure Linuxでは上流の修正を0.4.8系へバックポートし、RPMのリリース番号を3へ上げています。一方、pipや仮想環境で導入したpyasn1は、上流基準で0.6.4以上への更新が必要です。(GitHub)
CVE-2026-59884の概要
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-59884 |
| 対象OS | Azure Linux 3.0 |
| 対象ソースパッケージ | python-pyasn1 |
| 実際のRPM名 | python3-pyasn1 |
| 影響を受けるAzure Linux版 | 0.4.8-2 |
| Azure Linux修正版 | 0.4.8-3以降 |
| 上流pyasn1の修正版 | 0.6.4以降 |
| 影響する処理 | BER/CER/DERのデコード |
| 主な影響 | CPU枯渇、処理遅延、ワーカー停止などのDoS |
| 深刻度 | High、CVSS 3.1で7.5 |
| MSRCの個別回避策 | 掲載なし |
上流のアドバイザリでは、攻撃条件はネットワーク経由、低い攻撃複雑性、認証不要、ユーザー操作不要と評価されています。ただし、pyasn1自体がネットワークポートを開くわけではありません。外部から受け取ったASN.1データを、アプリケーションがpyasn1のデコーダーへ渡せる構成であることが前提です。(GitHub)
このCVEで直接問題になるのは可用性です。公開情報上、機密情報の読み取りやデータ改ざん、任意コード実行を引き起こす脆弱性ではありません。ただし、認証処理や監視、通信制御などの重要サービスがpyasn1に依存している場合、サービス停止の影響は大きくなります。
long-form tag IDがDoSを引き起こす仕組み
ASN.1のデータは、概念的には「タグ」「長さ」「値」で構成されます。タグは、格納されている値の種類や意味を識別するための情報です。
小さなタグ番号は最初の1オクテット内に格納できます。一方、より大きなタグ番号では、後続オクテットを使うlong-form tag IDが使用されます。後続オクテットの継続ビットを確認しながら、デコーダーがタグ番号を組み立てていく仕組みです。
脆弱な実装では、この後続オクテット数に上限がありませんでした。攻撃者が継続ビットを持つオクテットを大量に並べると、デコーダーは次の処理を繰り返します。
- 現在のタグ番号を7ビット左へシフトする
- 次のオクテットから7ビットを取り出す
- 巨大化した整数へ値を追加する
- 継続ビットがなくなるまで処理を続ける
Pythonの整数は固定長ではないため、タグ番号は入力に応じて際限なく大きくなります。整数が大きくなるほどシフトや結合の計算量も増え、全体のCPUコストは入力サイズに対しておおむね二次的に増加します。上流アドバイザリでは、約1MBの細工された入力によって1分以上CPUを消費する例が示されています。(GitHub)
ここでいうlong-form tag IDは、ASN.1の「データ全体の長さ」や「lengthフィールド」とは別のものです。リクエスト本文が通常の上限内でも、タグ番号部分へ不自然に長いデータを配置されると問題になる可能性があります。
BERだけでなくCERとDERも影響を受ける理由
脆弱性の中心はBERデコーダーのタグ解析処理です。pyasn1のCERおよびDERデコーダーもBERのデコード処理を共有・継承しているため、同じlong-form tag IDの問題が波及します。
影響する主な処理は次のとおりです。
pyasn1.codec.ber.decoder.decode()- BERのストリーミングデコード
- BER処理を利用するCERデコーダー
- BER処理を利用するDERデコーダー
エンコード処理だけを行うコードは、このCVEの直接的な攻撃経路には該当しません。ただし、アプリケーションや間接依存ライブラリがデコード機能を使っていないか、別途確認する必要があります。(GitHub)
Python 3.11以降では例外処理にも影響する
非常に大きなタグ番号を文字列化しようとすると、Python 3.11以降の整数文字列変換制限に達し、ValueErrorが発生することがあります。
呼び出し側がPyAsn1Errorだけを捕捉している場合、このValueErrorが想定した例外処理をすり抜ける可能性があります。結果はアプリケーションの構成によって異なりますが、リクエスト処理の失敗、ワーカー終了、エラーログの大量発生などにつながり得ます。
修正では、過剰に長いtag IDを早い段階で拒否するとともに、巨大なタグ番号の文字列表現でValueErrorが発生した場合の処理も強化されています。(GitHub)
影響を受ける環境の判断基準
パッケージがインストールされているだけで、直ちに外部から攻撃できるとは限りません。実際のリスクは、次の3条件で判断します。
Azure Linux 3.0で0.4.8-2を使用している
最初の条件は、Azure Linux 3.0上で脆弱なRPMがインストールされていることです。
MSRCではソースパッケージ名としてpython-pyasn1が示されますが、Azure Linuxのspecファイルで定義されるバイナリRPM名はpython3-pyasn1です。そのため、確認時にrpm -q python-pyasn1だけを実行すると、インストール済みパッケージを見落とす可能性があります。(GitHub)
BER/CER/DERのデコーダーを使用している
次に、アプリケーションがpyasn1のデコード機能を使用しているかを確認します。
直接pyasn1.codec.ber.decoderをインポートしていなくても、別のPythonライブラリが内部でpyasn1を利用している場合があります。ASN.1は証明書、認証情報、ネットワーク管理プロトコル、ディレクトリサービス関連データなどで使われるため、アプリケーションのソースコードだけでなく、依存ライブラリも調査対象です。
信頼できない入力がデコーダーへ到達する
実際の攻撃成立には、攻撃者が制御できるデータがデコーダーへ到達する必要があります。特に優先度が高いのは次の構成です。
- インターネット公開APIがASN.1データを受け取る
- 認証前にBER、CER、DERデータを解析する
- ユーザーが証明書やDER形式ファイルをアップロードできる
- 外部機器から受信したプロトコルメッセージを自動解析する
- 複数テナントが同じPythonワーカーやCPUを共有する
- 解析処理にリクエスト数や実行時間の制限がない
社内ネットワーク限定でも、端末、利用者、連携システムのすべてを完全に信頼できるとは限りません。外部公開の有無だけで対応不要と判断せず、脆弱なパッケージは更新するのが基本です。
Azure Linux 3.0でインストール状況を確認する手順
OSのバージョンを確認する
まず、対象ホストがAzure Linux 3.0かを確認します。
cat /etc/os-releaseVERSION_IDなどに3.0が表示されることを確認してください。コンテナを利用している場合は、ホストではなく実際のコンテナ内でも実行します。
RPMのバージョンを確認する
インストール済みRPMは次のコマンドで確認できます。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' python3-pyasn1脆弱な環境では、次のような結果が想定されます。
python3-pyasn1-0.4.8-2.azl3.noarch修正済みの目安は次のとおりです。
python3-pyasn1-0.4.8-3.azl3.noarch0.4.8-3より大きいリリース番号や、今後提供される上位バージョンも修正済み候補です。ただし、独自リポジトリのパッケージを利用している場合は、その提供元の修正情報も確認してください。
パッケージが存在するか広く検索する場合は、次のコマンドも利用できます。
rpm -qa | grep -E '^python3-pyasn1-'実際に読み込まれているpyasn1を確認する
OSのRPMを更新しても、アプリケーションが仮想環境やpipで別のpyasn1を読み込んでいれば、脆弱性は残ります。
アプリケーションが使用するPython実行ファイルで、次を実行してください。
python3 - <<'PY'
import pyasn1
print("version:", getattr(pyasn1, "__version__", "unknown"))
print("path:", pyasn1.__file__)
PY仮想環境を使用している場合は、python3ではなく、その仮想環境のPythonを指定します。
/opt/app/.venv/bin/python - <<'PY'
import pyasn1
print("version:", getattr(pyasn1, "__version__", "unknown"))
print("path:", pyasn1.__file__)
PY表示されたファイルがRPM管理下かを確認するには、次のように実行します。
PYASN1_FILE=$(python3 -c 'import pyasn1; print(pyasn1.__file__)')
rpm -qf "$PYASN1_FILE"python3-pyasn1が表示されればOSのRPMです。「どのパッケージにも所有されていない」と表示される場合は、pip、仮想環境、手動配置、アプリケーションへの同梱などを疑います。
__version__だけで修正済みか判断しない
Azure Linuxの修正版は、上流バージョンを0.6.4へ変更するのではなく、0.4.8へ修正をバックポートしたRPMです。そのため、修正後もPython上では次のように表示される可能性があります。
version: 0.4.8Azure LinuxのRPMについては、pyasn1.__version__ではなく、rpm -qで表示されるVERSION-RELEASEを確認してください。
修正版0.4.8-3へ更新する手順
リポジトリ情報を更新する
最初に、リポジトリのメタデータを更新します。
sudo tdnf makecache -y更新候補を確認する場合は、次のコマンドを使用できます。
tdnf list updates | grep -i pyasn1tdnf makecache、tdnf list updates、tdnf updateは、tdnfでパッケージ情報の更新、更新候補の確認、パッケージ更新を行う標準的な操作です。(VMware)
python3-pyasn1だけを更新する
緊急対応として変更範囲を限定する場合は、対象パッケージを指定します。
sudo tdnf update -y python3-pyasn1組織のパッチ運用でOS全体を更新できる場合は、他のセキュリティ修正も含めて適用します。
sudo tdnf update -y本番環境では、依存パッケージの変更内容を検証環境で確認し、必要に応じてメンテナンス時間を確保してください。
修正版が候補に表示されない場合は、次を確認します。
tdnf repolist
sudo tdnf clean all
sudo tdnf makecache -yリポジトリやミラーへの反映直後は、環境によって確認できるタイミングに差が出る場合があります。非公式サイトから入手したRPMを安易に導入せず、MicrosoftのリポジトリとMSRCの情報を確認してください。
更新結果を確認する
更新後、再度RPMのバージョンを確認します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' python3-pyasn1次の条件を満たしていることを確認します。
VERSION: 0.4.8
RELEASE: 3.azl3以上単にコマンドが正常終了しただけで完了とせず、実際のRPMバージョンまで確認することが重要です。
pyasn1を使用するプロセスを再起動する
Pythonプロセスは、起動時に読み込んだモジュールをメモリ上で使い続けます。ディスク上のファイルを更新しても、既存プロセスが自動的に新しいコードへ切り替わるとは限りません。
対象サービスを特定し、計画的に再起動します。
sudo systemctl restart <サービス名>複数ワーカー構成の場合は、すべてのワーカーが入れ替わったことを確認してください。ローリング再起動では、一部の旧ワーカーが残っていないかにも注意が必要です。
コンテナは再ビルドと再配備が必要
ホストOSのpython3-pyasn1を更新しても、既存コンテナ内部のRPMは更新されません。
コンテナ環境では、次の一連の対応が必要です。
- 修正版が取得できる状態でイメージを再ビルドする
- ビルド中に
rpm -q python3-pyasn1で確認する - 新しいイメージをレジストリへ登録する
- Deploymentやタスク定義を更新する
- 実行中のPodやコンテナを新しいイメージへ置き換える
- 実行中コンテナ内でもRPMを再確認する
ベースイメージのタグが同じでも、中身が更新される場合があります。再現性が必要な環境では、イメージのダイジェスト、ビルド日時、SBOM、RPM一覧を記録しておくと、修正適用の証跡を残しやすくなります。
Azure Linuxの0.4.8-3と上流0.6.4の違い
| 導入方法 | 修正済みと判断する基準 | 主な確認方法 |
|---|---|---|
| Azure LinuxのRPM | 0.4.8-3以降 | rpm -q python3-pyasn1 |
| pip／PyPI | 0.6.4以降 | python -m pip show pyasn1 |
| Python仮想環境 | 0.6.4以降 | 仮想環境のPythonで確認 |
| アプリに同梱されたコピー | 修正コミット相当を含むこと | SBOM、ソース、ベンダー情報 |
| コンテナ内のRPM | コンテナ内で0.4.8-3以降 | 実行中コンテナでrpm -q |
Azure Linuxのspecでは、パッケージの上流バージョンを0.4.8に保ったまま、リリース番号を3へ上げ、CVE-2026-59884を含むパッチを追加しています。修正コードではlong-form tag IDを最大20オクテットに制限し、上限を超えた入力をPyAsn1Errorとして拒否します。(GitHub)
pip管理のアプリケーションでは、依存関係ファイルやロックファイルを更新し、上流の修正版である0.6.4以上を指定します。
pyasn1>=0.6.4その後、テスト済みのコンテナや仮想環境を再構築します。
OSのPython環境へ次のような操作を行うことは避けてください。
sudo pip install --upgrade pyasn1RPM管理下のファイルとpip管理のファイルが混在すると、将来のOS更新で上書きされたり、依存関係が壊れたりする可能性があります。アプリケーション固有の依存関係は、仮想環境またはコンテナ内で管理するのが安全です。
MSRCに個別回避策がない場合の暫定対策
MSRCにはCVE-2026-59884に対する個別の回避策が掲載されていません。したがって、基本対応は0.4.8-3以上への更新です。
一方、上流アドバイザリでは、修正版を適用できない間の暫定策として、デコーダーへ渡す信頼できない入力のサイズを制限する方法が示されています。ただし、これはAzure Linuxの修正版と同等の対策ではありません。(Microsoft Security Response Center)
| 暫定対策 | 期待できる効果 | 限界 |
|---|---|---|
| 入力サイズの上限設定 | 1回の処理で渡されるデータ量を抑える | long-form tag ID自体を検証するものではない |
| リクエスト数の制限 | 連続攻撃による負荷増幅を抑える | 1件のリクエストでもワーカーを占有し得る |
| 同時実行数の制限 | 全ワーカーの枯渇を防ぎやすくする | 一部の処理能力は失われる |
| 外部プロセスの実行時間制限 | CPUを占有したワーカーを終了できる | 再起動ループや処理中断への設計が必要 |
| CPU・メモリ制限 | 他のサービスへの影響を局所化する | 脆弱な処理自体は残る |
| ASN.1受付機能の一時停止 | 攻撃経路を閉じる | 業務影響が大きい |
| 信頼済み送信元だけに限定 | 攻撃可能な主体を減らす | 認証情報の侵害や内部攻撃には弱い |
入力サイズの上限値に、すべてのシステムで使える共通の安全値はありません。正常業務で必要な最大サイズを測定し、その値に小さな余裕を加える形で設定します。
また、HTTPの読み取りタイムアウトだけでは十分でない場合があります。データを受信し終えた後にCPU負荷の高いデコード処理が始まると、ネットワークタイムアウトでは停止できないためです。CPU時間を確実に制限したい場合は、別プロセスのワーカータイムアウトやコンテナのリソース制限を組み合わせます。
修正後に確認すべきポイント
正常なASN.1データを処理できるか
修正では20オクテットを超えるlong-form tag IDが拒否されます。通常のASN.1データがこの上限へ達するケースは一般的ではありませんが、独自仕様や特殊なタグ番号を使用しているシステムでは、回帰テストを実施してください。
最低限、次の処理を確認します。
- 正常なBERデータのデコード
- CERまたはDERデータのデコード
- 証明書や認証データを扱う処理
- 外部機器との通信
- エラー入力を受け取った場合の応答
- ワーカーの再起動や再試行の動作
過剰なtag IDが安全に拒否されるか
修正版では、上限を超えるtag IDを無制限に処理せず、PyAsn1Errorとして拒否します。アプリケーション側では、この例外を適切に処理し、内部エラーの詳細を利用者へ返さない設計にします。(GitHub)
本番環境へ攻撃用データを送信して試験するのではなく、隔離した検証環境と承認済みのテストケースを使用してください。
CPU使用率とエラーログを監視する
更新後は、少なくとも次の指標を確認します。
- PythonワーカーのCPU使用率
- リクエスト処理時間
- タイムアウト件数
- HTTP 5xxやプロトコルエラー
PyAsn1Errorの増加- ワーカー再起動回数
- キューや同時接続数
- コンテナのCPUスロットリング
修正後にPyAsn1Errorが急増した場合、攻撃または異常な送信元が存在している可能性があります。一方、正規の連携システムが不正なASN.1データを生成している可能性もあるため、送信元、時刻、入力経路を関連付けて調査します。
対応時に失敗しやすいポイント
python-pyasn1だけを検索して未導入と判断する
python-pyasn1はソースパッケージ名で、Azure Linux上のバイナリRPMはpython3-pyasn1です。
確認には次を使用します。
rpm -q python3-pyasn1Python上の0.4.8表示だけで未修正と判断する
Azure Linuxの0.4.8-3はバックポート修正版です。Pythonモジュール内部のバージョンが0.4.8でも、RPMのリリース番号が3以上であればCVE修正を含みます。
ホストだけ更新してコンテナを放置する
コンテナのファイルシステムはホストと分離されています。ホストのRPM更新だけでは、実行中コンテナや古いコンテナイメージは修正されません。
更新後にPythonプロセスを再起動しない
すでに読み込まれたモジュールは、プロセス終了までメモリ上に残る場合があります。更新とプロセス再起動を同じ作業計画へ含めます。
pipとRPMを混在させる
OSのRPMをpipで上書きすると、どのファイルが実際に使われているか分かりにくくなります。pyasn1.__file__とrpm -qfを組み合わせ、導入元を確認してください。
直接importしていないため安全と判断する
pyasn1は間接依存として導入されることがあります。アプリケーションコードだけでなく、依存パッケージ、コンテナ、プラグイン、運用ツールも対象にします。
RPMパッケージからの依存関係は、次のコマンドで参考情報を取得できます。
rpm -q --whatrequires python3-pyasn1ただし、結果が空でも、アプリケーションがPythonコードから直接利用している可能性は残ります。
入力サイズ制限だけで対応を完了する
入力制限は被害を抑える暫定策です。long-form tag IDの構造を正しく検証する修正ではなく、適切な上限もシステムごとに異なります。修正版が利用可能になった時点で、必ずパッケージ更新へ切り替えます。
対応優先度の決め方
| 優先度 | 主な条件 |
|---|---|
| 最優先 | 認証前の外部入力をBER/CER/DERデコーダーへ渡す |
| 最優先 | インターネット公開サービスでpyasn1を使用する |
| 高 | 複数テナントや複数サービスがCPUを共有している |
| 高 | ファイルアップロードや証明書登録機能がある |
| 高 | 社内利用でも多数の端末や外部機器から入力を受ける |
| 通常 | パッケージは存在するが、信頼済み固定データだけを処理する |
| 要調査 | パッケージは存在するが、利用経路が把握できていない |
優先度は、更新するかどうかではなく、どれだけ早く更新するかを決めるために使います。0.4.8-2がインストールされている場合は、公開範囲が限定されていても0.4.8-3以上へ更新してください。
CVE-2026-59884への対応を整理
CVE-2026-59884への実務対応は、次の順序で進めると判断ミスを減らせます。
rpm -q python3-pyasn1でAzure LinuxのRPMを確認するpyasn1.__file__でアプリケーションが実際に読む場所を確認する- RPMなら
0.4.8-3以上へ更新する - pipや仮想環境なら上流版
0.6.4以上へ更新する - Pythonプロセスを再起動する
- コンテナはイメージを再ビルドして再配備する
- 正常なBER/CER/DER処理を回帰テストする
- CPU使用率、タイムアウト、
PyAsn1Errorを監視する
最も重要なのは、0.4.8という上流バージョンだけを見て判断しないことです。Azure LinuxではRPMのリリース番号3が修正の境界になります。実行中のPython環境、コンテナ、仮想環境まで確認し、更新後の再起動と検証を含めて対応を完了させてください。
コメント