CVE-2026-59885対策｜Azure Linux 3.0のpyasn1 OID DoSを0.4.8-3へ更新

CVE-2026-59885への最優先対応は、Azure Linux 3.0の脆弱なpython-pyasn1 0.4.8-2を、修正版の0.4.8-3以上へ更新することです。実際にインストールされるRPM名は通常python3-pyasn1なので、rpmでリリース番号まで確認し、tdnfで更新します。Azure Linuxの公式パッケージ定義では、0.4.8-3にCVE-2026-59885の修正パッチが追加されています。(Microsoft Security Response Center)

この脆弱性は、細工されたOBJECT IDENTIFIER（OID）やRELATIVE-OIDを処理すると、CPU使用時間が入力に対して二次関数的に増える問題です。外部から受け取ったASN.1データをデコードするサービスでは、比較的小さなデータでもCPUリソースを長時間占有され、応答遅延やサービス停止につながる可能性があります。更新後は、対象のPythonプロセスを再起動し、コンテナ環境では修正版を含むイメージを再ビルドして再展開することが重要です。(GitHub)

CVE-2026-59885の要点

項目	内容
脆弱性	OIDおよびRELATIVE-OID処理の二次計算量によるDoS
対象	Azure Linux 3.0の`python-pyasn1` 0.4.8-2
Azure Linux修正版	0.4.8-3以上
upstreamの修正版	pyasn1 0.6.4以上
主な影響	CPUリソースの過剰消費、応答遅延、サービス停止
深刻度	CVSS 3.1で7.5、High
攻撃条件	ネットワーク経由、低い攻撃複雑度、権限不要、利用者操作不要
MSRCの回避策	個別の回避策は掲載されていない
upstreamの暫定策	信頼できないASN.1入力のサイズをデコード前に制限する

CVE-2026-59885に割り当てられたCVSSベクトルでは、機密性と完全性への直接的な影響はなく、可用性への影響が高いと評価されています。ただし、実際の危険度は、対象アプリケーションが外部から受け取ったASN.1データを処理しているかによって大きく変わります。(GitHub)

pyasn1のOID処理でDoSが起きる仕組み

OIDとRELATIVE-OIDとは

OIDは、証明書、LDAP、SNMP、Kerberosなどで、オブジェクトやアルゴリズムを識別するために使われる番号列です。

たとえば、次のようにピリオドで区切られた値として表現されます。

1.2.840.113549

この一つひとつの数字を「arc」と呼びます。CVE-2026-59885では、1個のarcを極端に大きくするのではなく、非常に多くのarcを含むOIDを入力することで、処理時間を増加させます。

RELATIVE-OIDも同様にarcの列を表しますが、絶対的なOIDの先頭部分を持たない相対形式です。upstreamの脆弱性情報では、BER、CER、DERの各デコーダーが影響を受けるほか、攻撃者由来の値を再エンコードする処理も影響を受けるとされています。(GitHub)

処理時間が二次関数的に増える理由

修正前のpyasn1では、OIDを構築する際に、arcを追加するたびに既存のタプルを連結していました。

タプルは変更できないデータ構造であるため、arcを一つ追加するたびに、それまで蓄積した内容を新しいタプルへコピーする必要があります。arc数が増えると、コピーする要素数は次のように積み上がります。

1 + 2 + 3 + ... + n = n(n + 1) / 2

このため、arc数が2倍になると処理量はおおむね4倍になります。これが二次計算量、つまりO(n²)の原因です。

修正版では、一時的なリストへappend()でarcを追加し、処理の最後に一度だけタプルへ変換する方式へ変更されています。これにより、OIDの構築処理はarc数に比例する線形時間へ改善されました。(GitHub)

小さな入力でも無視できないCPU負荷になる

upstreamのアドバイザリでは、多数のarcを含む数十KB程度の細工されたOIDにより、1回のdecode()呼び出しで数秒単位のCPU時間を消費し得ると説明されています。

単発のリクエストだけでサービス全体が直ちに停止するとは限りません。しかし、複数のリクエストを並行して送信されると、ワーカープロセスやCPUコアが占有され、正常な利用者への応答が滞る可能性があります。(GitHub)

影響を受ける環境の判断基準

python3-pyasn1がインストールされているだけで、必ず攻撃可能になるわけではありません。次の3点を分けて確認する必要があります。

脆弱なパッケージが存在するか
そのパッケージをアプリケーションが実際に使用しているか
信頼できないASN.1データが処理経路へ到達するか

対応優先度は、次のように判断できます。

優先度	環境の例	判断
最優先	0.4.8-2を使用し、インターネットや外部組織からASN.1データを受信する	速やかに更新し、更新完了まで入口制限を実施
高	LDAP、SNMP、証明書、Kerberos関連データを社内ネットワークから受信する	内部利用でも不正入力や侵害端末を想定して早期更新
中	パッケージは存在するが、利用サービスや入力経路が不明	更新を進めながら依存関係と実行経路を調査
低	パッケージが未導入、または0.4.8-3以上へ更新済み	仮想環境、コンテナ、同梱コピーが残っていないか確認

特に注意したいのは、アプリケーションが直接pyasn1をインポートしていなくても、認証、監視、ディレクトリ連携などの依存ライブラリを通じて間接的に使っているケースです。

Azure Linux 3.0でパッケージを確認する方法

OSがAzure Linux 3.0か確認する

まず、対象ホストやコンテナのOS情報を確認します。

cat /etc/os-release

VERSION_IDなどの出力から、Azure Linux 3.0であることを確認してください。

ホストOSがAzure Linuxであっても、コンテナ内部がUbuntuやAlpineなど別のディストリビューションである場合、ホストとコンテナは別々に調査する必要があります。

RPMのバージョンとリリース番号を確認する

Azure Linuxのパッケージ定義上、ソースパッケージ名はpython-pyasn1ですが、実際にインストールされるPython 3向けRPMは通常python3-pyasn1です。(GitHub)

次のコマンドで、バージョンだけでなくRPMリリース番号まで表示します。

rpm -q \
  --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  python3-pyasn1

出力例は次のとおりです。

python3-pyasn1-0.4.8-2.azl3.noarch

この場合は脆弱な0.4.8-2に該当するため、更新が必要です。

修正後は、次のように0.4.8-3以上が表示されることを確認します。

python3-pyasn1-0.4.8-3.azl3.noarch

パッケージ名が分からない場合は、次のコマンドで検索できます。

rpm -qa \
  --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | grep -E '^python(3)?-pyasn1 '

`pyasn1.version`だけでは修正済みか判断できない

次のようなPythonコードでは、Azure LinuxのRPMリリース番号を確認できません。

python3 -c 'import pyasn1; print(pyasn1.__version__)'

Azure Linuxの0.4.8-3は、upstreamのバージョンを0.6.4へ上げるのではなく、0.4.8へ修正をバックポートしたパッケージです。そのため、更新後もPythonから見えるバージョンは0.4.8のままになる可能性があります。(GitHub)

修正済みかどうかは、次のように管理方式ごとに判断します。

pyasn1の導入方法	修正済みと判断する基準
Azure LinuxのRPM	`0.4.8-3`以上
pipまたはvenv	upstream版`0.6.4`以上
アプリケーションへ直接同梱	同梱版の由来とパッチ適用状況を個別確認
コンテナイメージ内のRPM	コンテナ内部で`0.4.8-3`以上
ホイールやZIPとして同梱	ビルド定義、ロックファイル、SBOMを確認

upstreamでは0.6.3以前が影響を受け、0.6.4で修正されています。一方、Azure Linuxでは0.4.8-3へ修正がバックポートされています。バージョン番号だけを比較するスキャナーでは、修正済みRPMを誤検知する可能性があるため、RPMの完全なバージョンとリリース番号を証跡として残してください。(GitHub)

pipや仮想環境のpyasn1を調べる

OSのRPMを更新しても、アプリケーションが仮想環境内のpyasn1を使用している場合、そのコピーは更新されません。

システムPythonを確認する例は次のとおりです。

python3 -m pip show pyasn1
python3 -c 'import pyasn1; print(pyasn1.__file__)'

仮想環境を利用している場合は、実際にサービスが使用するPythonで確認します。

/path/to/venv/bin/python -m pip show pyasn1
/path/to/venv/bin/python -c 'import pyasn1; print(pyasn1.__file__)'

pip管理の環境で0.6.3以前が見つかった場合は、依存関係を検証したうえで0.6.4以上へ更新します。

/path/to/venv/bin/python -m pip install 'pyasn1>=0.6.4'

システムPythonに対して安易にsudo pip installを実行するのは避けてください。RPM管理のファイルとpip管理のファイルが混在し、将来のアップデートや脆弱性判定が難しくなるためです。

0.4.8-3以上へ更新する手順

Azure Linuxでは、パッケージ管理にTiny DNFのtdnfを使用します。Microsoftのドキュメントでも、パッケージ確認にはtdnf list、更新にはtdnf updateを使用する方法が案内されています。(Microsoft Learn)

利用可能なパッケージを確認する

tdnf list python3-pyasn1

インストール済みとリポジトリ上の候補を確認し、0.4.8-3以上が提供されていることを確認します。

パッケージを更新する

sudo tdnf update python3-pyasn1

自動化されたメンテナンス処理で実行する場合は、事前に検証環境で依存関係や終了コードを確認してください。

リポジトリ情報が古いと考えられる場合は、キャッシュを消去してから再実行します。

sudo tdnf clean all
sudo tdnf update python3-pyasn1

更新後のバージョンを確認する

rpm -q \
  --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  python3-pyasn1

0.4.8-3以上であることを確認します。Azure Linuxの0.4.8-3には、CVE-2026-59885を含む同時期の複数のpyasn1向けセキュリティパッチが収録されています。(GitHub)

対象のPythonサービスを再起動する

RPMのファイルを更新しても、既に起動しているPythonプロセスは、メモリへ読み込んだ古いモジュールを引き続き使用することがあります。

対象サービスを特定し、メンテナンス手順に従って再起動します。

sudo systemctl restart <service-name>
sudo systemctl status <service-name>

本件では、OS全体の再起動よりも、pyasn1を読み込んでいるPythonプロセスを確実に再起動することが重要です。ただし、同時にカーネルや基盤パッケージも更新した場合は、それらの要件に従ってOS再起動を判断してください。

コンテナとAKSではホスト更新だけで終わらせない

コンテナイメージ内部を確認する

Azure Linuxホスト上で動くコンテナは、ホストとは別のファイルシステムを持ちます。ホストのpython3-pyasn1を更新しても、既存のコンテナイメージに含まれるパッケージは変わりません。

Azure Linuxベースのコンテナイメージは、次のように内部のRPMを確認できます。

docker run --rm \
  --entrypoint rpm \
  <image-name> \
  -q python3-pyasn1

脆弱なバージョンが含まれている場合は、Dockerfileやビルドパイプラインで更新し、新しいイメージを作成します。

RUN tdnf update -y python3-pyasn1 \
    && rpm -q python3-pyasn1 \
    && tdnf clean all

その後、次の流れで置き換えます。

最新のベースイメージを取得して再ビルドする
修正版RPMを含むことをCIで確認する
新しいイメージダイジェストをレジストリへ登録する
ステージング環境でASN.1関連機能をテストする
本番のPodやコンテナを新しいイメージへ置き換える
稼働中コンテナのイメージダイジェストを再確認する

単に稼働中コンテナへログインして更新すると、Podの再作成時に古いイメージへ戻る可能性があります。恒久対応は、イメージの再ビルドと再展開です。

AKSノードとワークロードコンテナを分けて考える

AKSのAzure Linuxノードに対象パッケージが含まれる場合は、ノードへ個別にログインして更新するだけでなく、修正を含むノードイメージへの更新を検討します。AKSではLinuxノードイメージが継続的に更新されており、ノードイメージの手動更新やNode OS自動アップグレードを利用できます。(Microsoft Learn)

一方、ワークロードコンテナ内のpyasn1はノードイメージ更新の対象外です。

対象	必要な対応
AKSノードOS内のRPM	修正版を含むノードイメージへ更新
ワークロードコンテナ内のRPM	コンテナイメージを再ビルドして再展開
Pod内のvenvやpipパッケージ	アプリケーション依存関係を0.6.4以上へ更新
ビルド済み成果物への同梱コピー	成果物を再生成して置き換え

アプリケーションがpyasn1を使用しているか確認する

RPMの依存関係を調べるには、次のコマンドを使用できます。

rpm -q --whatrequires python3-pyasn1

ただし、「依存パッケージなし」と表示されても、未使用とは限りません。独自のPythonコードやpipで導入したライブラリから直接読み込まれている可能性があるためです。

アプリケーション側では、次の情報を確認します。

requirements.txt、pyproject.toml、poetry.lockなどの依存関係ファイル
ソースコード内のimport pyasn1やfrom pyasn1
証明書、LDAP、SNMP、Kerberos関連ライブラリの依存関係
実行中プロセスが使用するPythonインタープリター
コンテナイメージのSBOM
脆弱性スキャナーが検出したファイルパスとパッケージ管理方式

特に、スキャナーの結果に0.4.8とだけ表示されている場合は、それが脆弱なpip版なのか、修正をバックポートしたAzure Linuxの0.4.8-3なのかを区別する必要があります。

更新できない場合の暫定対策

MSRCではCVE-2026-59885に対する個別の回避策は示されていません。upstreamでは、信頼できないASN.1データをデコードする前に入力サイズを制限する方法が案内されています。(Microsoft Security Response Center)

ただし、入力制限は修正版への更新と同等ではありません。更新までのリスク低減策として、複数の対策を組み合わせてください。

暫定対策	期待できる効果	注意点
ASN.1入力の最大サイズを制限	1リクエストで投入できるarc数を抑える	正常データの最大値を調査してから設定する
リクエストレートを制限	攻撃リクエストの連続投入を抑える	単発処理のCPU負荷は解消しない
同時実行数を制限	全ワーカーが一度に占有される事態を防ぐ	待ち行列の増加を監視する必要がある
不要な外部公開を停止	攻撃経路を縮小する	内部ネットワークからの攻撃は残る
ワーカーを分離する	障害範囲を限定する	脆弱性そのものは残る
コンテナCPU上限を設定	他サービスへのCPU影響を抑える	対象サービス自体のDoSは防げない
タイムアウトを設定	長時間処理を終了しやすくする	同一プロセス内のCPU処理を即座に中断できない場合がある

入力サイズの上限に一律の推奨値はありません。実際の証明書、LDAPメッセージ、SNMPメッセージなどの最大サイズを計測し、正常処理を妨げない範囲で設定します。

対応時に失敗しやすいポイント

upstream版の0.6.4だけを修正版と考える

Azure Linuxでは、upstreamのバージョンを0.6.4へ上げず、0.4.8へ修正をバックポートしています。Azure LinuxのRPMは0.4.8-3以上、pip管理の環境は0.6.4以上というように、管理方式に応じて判断基準を変える必要があります。

Pythonから表示される0.4.8だけを見て未修正と判断する

pyasn1.__version__ではRPMの-2と-3を区別できません。Azure Linuxでは、必ずrpm -qでリリース番号まで確認します。

ホストだけを更新してコンテナを確認しない

ホストとコンテナは別のパッケージ環境です。ホストが修正済みでも、コンテナイメージに0.4.8-2や古いpip版が残っていれば影響を受けます。

システムPythonをpipで上書きする

sudo pip installでOS管理のpyasn1を上書きすると、RPMデータベース上の情報と実際に読み込まれるコードが一致しなくなる可能性があります。OSパッケージはtdnf、アプリケーションの仮想環境はその依存関係管理ツールで更新します。

更新後にサービスを再起動しない

長時間稼働しているPythonプロセスには、更新前のコードが読み込まれたまま残る可能性があります。更新作業にはサービス再起動またはコンテナ再展開まで含めます。

以前のOID制限で防げると判断する

CVE-2026-23490向けのarcサイズ制限は、1個のarcのバイト長を制限するものです。CVE-2026-59885はarcの個数を増やして計算量を高めるため、以前の制限だけでは対策になりません。(GitHub)

パッケージがあるだけで外部公開サービスを停止する

パッケージの存在と攻撃経路は別の問題です。緊急停止を判断する前に、対象サービス、入力元、デコード処理、認証の有無を確認します。ただし、調査に時間がかかる場合でも、修正版への更新は並行して進めるべきです。

更新後に確認する項目

対応完了と判断する前に、次の項目を確認します。

Azure Linux 3.0の全ホストを調査した
python3-pyasn1が0.4.8-3以上になっている
pipおよびvenvのpyasn1が0.6.4以上になっている
コンテナイメージ内のパッケージを確認した
稼働中Podが修正版イメージへ置き換わっている
対象のPythonサービスを再起動した
証明書、LDAP、SNMP、Kerberosなどの正常系テストを実施した
更新後のCPU使用率、応答時間、エラー率を監視した
RPMの完全なバージョンとリリース番号を対応記録へ残した
脆弱性スキャナーの再評価を実施した

CVE-2026-59885への対応まとめ

CVE-2026-59885は、pyasn1のOBJECT IDENTIFIERおよびRELATIVE-OID処理における二次計算量を利用し、CPUリソースを枯渇させるDoS脆弱性です。Azure Linux 3.0では、脆弱な0.4.8-2を0.4.8-3以上へ更新することが基本対策です。(GitHub)

最初にrpm -q python3-pyasn1で完全なRPMリリースを確認し、tdnf update python3-pyasn1を実行してください。その後、Pythonサービスの再起動、仮想環境の確認、コンテナイメージの再ビルドまで実施します。

すぐに更新できない場合は、ASN.1入力サイズ、レート、同時実行数を制限して影響を抑えます。ただし、これらは暫定策です。最終的には修正版の適用と、実行中の全環境で修正が有効になっていることの確認が必要です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

CVE-2026-59885対策｜Azure Linux 3.0のpyasn1 OID DoSを0.4.8-3へ更新

CVE-2026-59885の要点

pyasn1のOID処理でDoSが起きる仕組み

OIDとRELATIVE-OIDとは

処理時間が二次関数的に増える理由

小さな入力でも無視できないCPU負荷になる

影響を受ける環境の判断基準

Azure Linux 3.0でパッケージを確認する方法

OSがAzure Linux 3.0か確認する

RPMのバージョンとリリース番号を確認する

`pyasn1.version`だけでは修正済みか判断できない

pipや仮想環境のpyasn1を調べる

0.4.8-3以上へ更新する手順

利用可能なパッケージを確認する

パッケージを更新する

更新後のバージョンを確認する

対象のPythonサービスを再起動する

コンテナとAKSではホスト更新だけで終わらせない

コンテナイメージ内部を確認する

AKSノードとワークロードコンテナを分けて考える

アプリケーションがpyasn1を使用しているか確認する

更新できない場合の暫定対策

対応時に失敗しやすいポイント

upstream版の0.6.4だけを修正版と考える

Pythonから表示される0.4.8だけを見て未修正と判断する

ホストだけを更新してコンテナを確認しない

システムPythonをpipで上書きする

更新後にサービスを再起動しない

以前のOID制限で防げると判断する

パッケージがあるだけで外部公開サービスを停止する

更新後に確認する項目

CVE-2026-59885への対応まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

CVE-2026-59885対策｜Azure Linux 3.0のpyasn1 OID DoSを0.4.8-3へ更新

CVE-2026-59885の要点

pyasn1のOID処理でDoSが起きる仕組み

OIDとRELATIVE-OIDとは

処理時間が二次関数的に増える理由

小さな入力でも無視できないCPU負荷になる

影響を受ける環境の判断基準

Azure Linux 3.0でパッケージを確認する方法

OSがAzure Linux 3.0か確認する

RPMのバージョンとリリース番号を確認する

pyasn1.__version__だけでは修正済みか判断できない

pipや仮想環境のpyasn1を調べる

0.4.8-3以上へ更新する手順

利用可能なパッケージを確認する

パッケージを更新する

更新後のバージョンを確認する

対象のPythonサービスを再起動する

コンテナとAKSではホスト更新だけで終わらせない

コンテナイメージ内部を確認する

AKSノードとワークロードコンテナを分けて考える

アプリケーションがpyasn1を使用しているか確認する

更新できない場合の暫定対策

対応時に失敗しやすいポイント

upstream版の0.6.4だけを修正版と考える

Pythonから表示される0.4.8だけを見て未修正と判断する

ホストだけを更新してコンテナを確認しない

システムPythonをpipで上書きする

更新後にサービスを再起動しない

以前のOID制限で防げると判断する

パッケージがあるだけで外部公開サービスを停止する

更新後に確認する項目

CVE-2026-59885への対応まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

`pyasn1.version`だけでは修正済みか判断できない

コメントするコメントをキャンセル