CVE-2026-59886対策：Azure Linux 3.0のpyasn1を0.4.8-3へ更新する手順

CVE-2026-59886への基本対応は明確です。Azure Linux 3.0でpython-pyasn1 0.4.8-2を使用している場合は、修正版の0.4.8-3以上へ更新してください。 実際にインストールされるRPM名は、通常python3-pyasn1です。

この脆弱性では、外部から受け取ったASN.1のREAL値をデコードした後、文字列化、ログ出力、比較、算術演算などを行うと、CPUやメモリが大量に消費され、Pythonプロセスが停止状態になる可能性があります。デコード処理だけでは発生しませんが、エラー調査用のログ出力など、通常のアプリケーション処理が引き金になる点に注意が必要です。上流のセキュリティアドバイザリでは重要度「High」、CVSS基本値7.5と評価されています。(GitHub)

CVE-2026-59886の結論：0.4.8-3以上へ更新する

CVE-2026-59886は、Python向けASN.1ライブラリであるpyasn1のuniv.Real型において、デコード済みREAL値をPythonの数値へ変換する際に、制御不能なリソース消費が起きる脆弱性です。

Azure Linux 3.0における対応内容は次のとおりです。

項目	内容
CVE番号	CVE-2026-59886
対象	Azure Linux 3.0のpython-pyasn1
影響を受けるパッケージ	0.4.8-2
Azure Linuxの修正版	0.4.8-3以上
実際のRPM名	python3-pyasn1
上流pyasn1の影響範囲	0.6.3以前
上流pyasn1の修正版	0.6.4
主な影響	CPU・メモリ枯渇によるサービス拒否
発生条件	デコード済みREAL値の文字列化、比較、演算、数値変換など
MSRCの個別回避策	掲載なし

Azure Linuxの修正版は、上流バージョンを0.6.4へ変更する方式ではなく、0.4.8へ修正パッチをバックポートしたものです。Azure LinuxのRPM定義では、Version: 0.4.8、Release: 3となっており、CVE-2026-59886用パッチが組み込まれています。(GitHub)

MicrosoftのAzure Linuxリポジトリでも、CVE-2026-59886を含むpyasn1のセキュリティ修正がAzure Linux 3.0向けにマージされています。レビューでは上流パッチとの一致が確認され、テストとビルドも完了しています。(GitHub)

pyasn1のREAL値変換でリソース枯渇が起きる仕組み

数バイトのREAL値から巨大な計算が発生する

ASN.1のREAL値は、仮数、基数、指数の組み合わせで数値を表現できます。問題のあるバージョンのpyasn1では、この値をPythonの浮動小数点数へ変換する際に、正確な多倍長整数の累乗計算を行っていました。

BER、CER、DERでエンコードされたREAL値には、入力データ自体が数バイトしかなくても、非常に大きな指数を格納できます。その結果、変換処理で現実的に保持できないほど巨大な整数を生成しようとして、CPU時間とメモリが大量に消費されます。(GitHub)

典型的な発生の流れは次のとおりです。

アプリケーションが外部からBER、CER、DER形式のASN.1データを受信する
pyasn1がREAL値をuniv.Realオブジェクトとしてデコードする
アプリケーションがデコード結果をログへ出力する
str()やprettyPrint()が内部で数値変換を実行する
CPU使用率とメモリ使用量が急増する
ワーカープロセスが応答不能になるか、OOMによって終了する

入力サイズが小さくても問題が起きるため、単純なアップロードサイズ制限だけでは防げません。

デコードしただけでは脆弱性は発現しない

CVE-2026-59886は、ASN.1 REAL値をデコードした時点では直ちに発現しません。次のような処理によって数値変換が行われたときに問題が起きます。

prettyPrint()による表示
str()による文字列化
ログへのオブジェクト出力
大小比較や等価比較
加算や乗算などの算術演算
int()による整数化
float()による浮動小数点数化

特に見落としやすいのがログ出力です。アプリケーション本体ではREAL値を計算に使っていなくても、受信内容やエラー内容をログに記録する過程で文字列変換が発生する可能性があります。

一方、ASN.1 REAL値をまったく扱わないアプリケーションや、該当する変換処理を実行しないアプリケーションは、公開されている発生条件には該当しません。エンコーダーとpyasn1のnative codecも、この脆弱性の対象外とされています。(GitHub)

Azure Linux 3.0が影響を受けるか確認する方法

OSのバージョンを確認する

最初に、対象サーバーやコンテナがAzure Linux 3.0で動作しているか確認します。

cat /etc/os-release

VMだけでなく、次の環境も確認対象に含めてください。

Azure Linuxをベースにしたコンテナイメージ
AKSなどで稼働するアプリケーションコンテナ
CI/CDで作成している独自ベースイメージ
オフライン処理用のバッチサーバー
開発環境や検証環境から複製した本番イメージ

ホストOSを更新しても、コンテナイメージ内のRPMは自動的に更新されません。

インストール済みRPMを確認する

Azure Linuxのソースパッケージ名はpython-pyasn1ですが、インストールされるPython 3向けRPM名はpython3-pyasn1です。

次のコマンドでバージョンとリリース番号を確認します。

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

表示例は次のとおりです。

python3-pyasn1 0.4.8-2.azl3.noarch

この場合は影響を受けるため、更新が必要です。

修正後は、次のようにReleaseが3以上になっていることを確認します。

python3-pyasn1 0.4.8-3.azl3.noarch

パッケージがインストールされていない場合は、次のように表示されます。

package python3-pyasn1 is not installed

ただし、RPMが存在しなくても、仮想環境やアプリケーションディレクトリへpipでpyasn1が導入されている可能性があります。

実際に読み込まれるpyasn1を確認する

RPMを更新しても、古いpip版や仮想環境内のpyasn1が優先されていると、脆弱なコードが引き続き使用されます。

アプリケーションが使用するPython環境で次を実行してください。

python3 - <<'PY'
import os
import sys
import pyasn1

print("Python:", sys.executable)
print("pyasn1 version:", pyasn1.__version__)
print("pyasn1 path:", os.path.realpath(pyasn1.__file__))
PY

表示されたパスがRPMで管理されているかは、次のコマンドで確認できます。

rpm -qf /表示された/pyasn1/__init__.py

RPM管理外と表示された場合は、pip、仮想環境、アプリケーションへの同梱など、別の方法で導入されています。

なお、Azure Linuxの0.4.8-3はバックポート修正版です。そのため、Python上で確認したpyasn1.__version__は、修正後も0.4.8と表示されます。Azure LinuxではPythonモジュールのバージョンだけでなく、RPMのRelease番号まで確認することが重要です。

対応優先度を判断する

すべての環境で更新は必要ですが、緊急度はデータの受信経路とREAL値の扱い方によって異なります。

利用状況	対応優先度	判断理由
インターネットからASN.1データを受信する	最優先	認証なしで攻撃可能な経路が存在する可能性がある
利用者が任意のASN.1ファイルをアップロードできる	最優先	悪意のあるREAL値を直接投入される可能性がある
外部組織から受け取ったASN.1をバッチ処理する	高	ファイル経由でもリソース枯渇が起きる
社内システムだが複数利用者が入力できる	高	内部利用であっても入力を信頼できるとは限らない
REAL値をログ出力、比較、計算している	高	脆弱性のトリガーとなる処理が存在する
REAL値を使用しないことをスキーマとコードの両方で確認済み	通常	現時点の到達可能性は低いが、パッケージ更新は必要
パッケージは存在するが利用するプロセスがない	通常	直接的な露出は低いが、将来の利用や間接依存に備える

上流評価では攻撃経路がネットワーク、攻撃の複雑さが低、権限不要、利用者操作不要となっています。ただし、実際にネットワーク経由で攻撃できるかどうかは、対象アプリケーションが信頼できないASN.1データを受け付けているかで決まります。公表評価上の影響は可用性に集中しており、機密性と完全性への直接的な影響は示されていません。(GitHub)

Azure Linux 3.0で0.4.8-3へ更新する手順

更新候補を確認する

Azure Linux 3.0では、パッケージ管理にTiny DNFのtdnfを使用します。(Microsoft Learn)

最初に、リポジトリで提供されているバージョンを確認します。

tdnf list python3-pyasn1

更新前の状態も記録しておきます。

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

本番環境では、事前に検証環境で次の項目を確認してください。

pyasn1を利用するサービスが正常に起動するか
通常のASN.1データをデコードできるか
ログ出力や比較処理で例外が増えていないか
依存アプリケーションの自動テストが成功するか
ロールバック用のイメージやスナップショットがあるか

パッケージを更新する

メタデータを更新したうえで、python3-pyasn1を更新します。

sudo tdnf clean all
sudo tdnf makecache
sudo tdnf update -y python3-pyasn1

組織の更新方針でシステム全体の更新が認められている場合は、関連するセキュリティ修正もまとめて適用できます。

sudo tdnf update -y

Azure Linuxの修正パッケージには、CVE-2026-59886だけでなく、同時期に公開されたpyasn1の関連脆弱性に対するパッチも含まれています。(GitHub)

リポジトリに0.4.8-3が表示されない場合

tdnf listで0.4.8-2しか表示されない場合は、次の順序で確認します。

sudo tdnf clean all
sudo tdnf makecache
tdnf repolist
tdnf list python3-pyasn1

それでも修正版が表示されない場合は、次の点を確認してください。

Azure Linux 3.0の公式リポジトリが有効になっているか
固定された社内ミラーが古い状態になっていないか
リポジトリのスナップショット日が修正公開前ではないか
パッケージバージョンを固定する設定がないか
CI/CDで古いキャッシュやベースイメージを再利用していないか

出所が確認できないRPMを外部サイトから直接ダウンロードして置き換える方法は避けてください。正式なリポジトリや組織で承認された更新経路を使用します。

Pythonサービスを再起動する

RPMを更新しただけでは、実行中のPythonプロセスが読み込み済みのpyasn1コードは置き換わりません。対象サービスを再起動してください。

sudo systemctl restart アプリケーション名.service
sudo systemctl status アプリケーション名.service --no-pager

複数のワーカープロセスを使用している場合は、一部の旧プロセスが残っていないかも確認します。

ローリング更新を行う場合は、各インスタンスについて次の順序で進めると安全です。

ロードバランサーから対象インスタンスを切り離す
パッケージを更新する
サービスを再起動する
バージョンと正常性を確認する
ロードバランサーへ戻す
次のインスタンスを更新する

コンテナは再ビルドして再デプロイする

コンテナ内にpython3-pyasn1が含まれている場合、ホストOSの更新だけでは修正されません。

Dockerfileまたはコンテナビルド定義でパッケージを更新し、新しいイメージを作成します。

RUN tdnf clean all \
    && tdnf makecache \
    && tdnf update -y python3-pyasn1 \
    && tdnf clean all

作成したイメージ内のバージョンを確認します。

docker run --rm イメージ名:タグ \
  rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' python3-pyasn1

既存コンテナへ一時的にパッケージを導入するだけでは、再作成時に元へ戻ります。修正済みイメージをレジストリへ登録し、ワークロードを再デプロイしてください。

pipや仮想環境でpyasn1を使用している場合

pipで導入したpyasn1については、0.6.3以前が影響を受け、上流の修正版は0.6.4です。(GitHub)

仮想環境を有効にした状態、またはアプリケーションが使用するPythonを明示して、バージョンを確認します。

python -m pip show pyasn1

影響を受けるバージョンであれば、依存関係を確認したうえで更新します。

python -m pip install --upgrade "pyasn1>=0.6.4"

requirements.txt、poetry.lock、Pipfile.lockなどを使用している場合は、実行環境だけでなく依存関係ファイルも更新してください。実行環境だけを手作業で更新すると、次回のデプロイで古いバージョンへ戻る可能性があります。

また、Azure LinuxのシステムPythonへsudo pip installを実行し、RPM版を上書きする方法は避けるべきです。RPMとpipが同じPython環境に混在すると、次の問題が起きやすくなります。

脆弱性スキャナーの判定と実際のコードが一致しない
RPM更新後もpip版が優先される
パッケージ削除時にファイルの所有関係が崩れる
ベンダーサポートで構成を説明しにくくなる

RPM管理のシステム環境は0.4.8-3以上へ更新し、pip管理のアプリケーション環境は0.6.4以上へ更新する、と分けて考えてください。

更新後に確認すべき項目

RPMのRelease番号を再確認する

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

Azure Linux 3.0では、少なくとも次の条件を満たしている必要があります。

VERSION-RELEASEが0.4.8-3以上

実行中のPythonが読み込む場所を確認する

python3 - <<'PY'
import os
import sys
import pyasn1

print("Python:", sys.executable)
print("pyasn1 version:", pyasn1.__version__)
print("pyasn1 path:", os.path.realpath(pyasn1.__file__))
PY

更新したRPMとは別の仮想環境やアプリケーション同梱版が表示された場合は、その環境も個別に確認します。

アプリケーションの正常性を確認する

更新後は、単にサービスが起動したことだけでなく、次の動作を確認してください。

正常なASN.1データを処理できる
想定外データを受け取った際に適切なエラーを返す
ログ出力が正常に行われる
ワーカープロセスが繰り返し再起動していない
CPU使用率とメモリ使用量が通常範囲に戻っている
応答時間やキュー滞留時間が悪化していない

更新前に不審な高負荷が発生していた場合は、OOM、プロセス再起動、タイムアウト、異常なリクエストの記録も確認します。

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

MSRCではAzure Linux 3.0向けの個別回避策は掲載されていません。上流のpyasn1アドバイザリでは、信頼できない入力からデコードしたREAL値を変換、表示、比較せず、元の仮数・基数・指数の組を確認する方法が示されています。ただし、これはアプリケーションコードを変更する暫定策であり、0.4.8-3への更新を置き換えるものではありません。(GitHub)

暫定対策	期待できる効果	限界
外部入力のASN.1 REAL値を受け付けない	脆弱な処理への到達を防げる	プロトコル上REALが必要な場合は実施できない
REAL値の文字列化やログ出力を停止する	`str()`や`prettyPrint()`経由の発現を減らせる	比較や演算など別の変換経路が残る
デコード処理を別プロセスへ隔離する	アプリケーション全体への影響を抑えられる	隔離したプロセス自体は停止する
CPU・メモリ・実行時間を制限する	リソース枯渇の範囲を限定できる	正常な処理も強制終了される可能性がある
レート制限や認証を追加する	攻撃の反復や大量送信を抑えられる	1件の入力だけで高負荷になる可能性がある
入力サイズを制限する	大容量データによる一般的なDoSを減らせる	本脆弱性は数バイトのREAL値でも発生し得る

一時的にコード側で回避する場合は、REAL値が次の処理へ流れていないか、アプリケーション全体を調査する必要があります。

デバッグログ
例外メッセージ
オブジェクトのダンプ
JSONなど別形式への変換
ソートや重複判定
数値範囲の検証
メトリクスや監査ログへの記録

変換経路を完全に洗い出すのは難しいため、最終的には修正版パッケージの適用が必要です。

対応時によくある失敗

pyasn1の表示が0.4.8なので未修正と判断する

Azure Linuxの0.4.8-3はバックポート修正版です。pyasn1.__version__だけを見ると、修正後も0.4.8と表示されます。

Azure Linuxでは次の両方を確認してください。

Pythonが読み込むpyasn1のパス
RPMのVERSION-RELEASE

すべての0.4.8-3が修正版だと思い込む

ディストリビューションのRelease番号は、ベンダーごとに意味が異なります。Azure Linuxの0.4.8-3には修正パッチが含まれますが、別のLinuxディストリビューションに同じような番号があっても、同じ修正内容とは限りません。

実際にDebianのセキュリティトラッカーでは、Debian独自の0.4.8-3+deb12u2がCVE-2026-59886について脆弱と判定されています。バージョン文字列を他ディストリビューションと横断比較せず、各ベンダーのアドバイザリで確認してください。(セキュリティトラッカー)

ホストだけを更新してコンテナを放置する

ホストOSとコンテナのファイルシステムは別です。コンテナ内に脆弱なRPMやpipパッケージが含まれている場合は、コンテナイメージを再ビルドして再デプロイする必要があります。

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

実行中のPythonプロセスは、更新前に読み込んだコードをメモリ上で使い続けます。RPM更新後は、対象サービス、ワーカー、バッチプロセスを再起動してください。

入力サイズ制限だけで対策したと考える

この脆弱性では、数バイトのREAL値でも非常に大きな指数を指定できます。HTTPリクエストやファイルの最大サイズを制限するだけでは、根本的な防止策になりません。

直接依存だけを調査する

アプリケーション自身がpyasn1を明示的に使用していなくても、別のPythonパッケージから間接的に利用されている場合があります。SBOM、ロックファイル、コンテナスキャン結果に加え、実際のimportパスまで確認することが重要です。

CVE-2026-59886への対応を完了するチェックリスト

CVE-2026-59886への対応では、次の順序で作業を進めます。

Azure Linux 3.0を使用するVM、コンテナ、バッチ環境を洗い出す
python3-pyasn1のRPMバージョンを確認する
0.4.8-2であれば0.4.8-3以上へ更新する
pipや仮想環境のpyasn1も調査する
pip版が0.6.3以前なら0.6.4以上へ更新する
コンテナイメージを再ビルドして再デプロイする
Pythonサービスとワーカープロセスを再起動する
RPMのRelease番号と実際のimportパスを再確認する
正常系テストとCPU・メモリ監視を実施する
更新を遅らせる場合は入力経路の遮断やプロセス隔離を行う

最も重要なのは、Python上で表示される0.4.8だけを見て判断しないことです。Azure Linux 3.0では、python3-pyasn1のRPM Releaseが3以上であることを確認し、実際にアプリケーションが読み込むモジュールまで追跡してください。

この記事を書いた人

佐藤健司

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

CVE-2026-59886対策：Azure Linux 3.0のpyasn1を0.4.8-3へ更新する手順

CVE-2026-59886の結論：0.4.8-3以上へ更新する

pyasn1のREAL値変換でリソース枯渇が起きる仕組み

数バイトのREAL値から巨大な計算が発生する

デコードしただけでは脆弱性は発現しない

Azure Linux 3.0が影響を受けるか確認する方法

OSのバージョンを確認する

インストール済みRPMを確認する

実際に読み込まれるpyasn1を確認する

対応優先度を判断する

Azure Linux 3.0で0.4.8-3へ更新する手順

更新候補を確認する

パッケージを更新する

リポジトリに0.4.8-3が表示されない場合

Pythonサービスを再起動する

コンテナは再ビルドして再デプロイする

pipや仮想環境でpyasn1を使用している場合

更新後に確認すべき項目

RPMのRelease番号を再確認する

実行中のPythonが読み込む場所を確認する

アプリケーションの正常性を確認する

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

対応時によくある失敗

pyasn1の表示が0.4.8なので未修正と判断する

すべての0.4.8-3が修正版だと思い込む

ホストだけを更新してコンテナを放置する

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

入力サイズ制限だけで対策したと考える

直接依存だけを調査する

CVE-2026-59886への対応を完了するチェックリスト

この記事を書いた人

コメント

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

CVE-2026-59886対策：Azure Linux 3.0のpyasn1を0.4.8-3へ更新する手順

CVE-2026-59886の結論：0.4.8-3以上へ更新する

pyasn1のREAL値変換でリソース枯渇が起きる仕組み

数バイトのREAL値から巨大な計算が発生する

デコードしただけでは脆弱性は発現しない

Azure Linux 3.0が影響を受けるか確認する方法

OSのバージョンを確認する

インストール済みRPMを確認する

実際に読み込まれるpyasn1を確認する

対応優先度を判断する

Azure Linux 3.0で0.4.8-3へ更新する手順

更新候補を確認する

パッケージを更新する

リポジトリに0.4.8-3が表示されない場合

Pythonサービスを再起動する

コンテナは再ビルドして再デプロイする

pipや仮想環境でpyasn1を使用している場合

更新後に確認すべき項目

RPMのRelease番号を再確認する

実行中のPythonが読み込む場所を確認する

アプリケーションの正常性を確認する

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

対応時によくある失敗

pyasn1の表示が0.4.8なので未修正と判断する

すべての0.4.8-3が修正版だと思い込む

ホストだけを更新してコンテナを放置する

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

入力サイズ制限だけで対策したと考える

直接依存だけを調査する

CVE-2026-59886への対応を完了するチェックリスト

この記事を書いた人

関連記事

コメント

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

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