MENU

Azure Linux 3.0のCVE-2026-57433対策｜Perl Storableを5.38.2-514へ更新

Azure

Azure Linux 3.0でazl3 perl 5.38.2-512を使用している場合は、Perlを5.38.2-514以降へ更新する必要があります。CVE-2026-57433は、PerlのStorableが細工されたSX_HOOKレコードを逆シリアル化するときに、符号付き整数オーバーフローを起こす脆弱性です。

Microsoft Security Response Center（MSRC）は修正版として5.38.2-514を示していますが、個別の回避策は掲載していません。そのため、まずOSとRPMパッケージのリリース番号を確認し、修正版への更新、関連サービスの再起動、コンテナイメージの再ビルドまで実施することが基本対応になります。(msrc.microsoft.com)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

CVE-2026-57433とは

CVE-2026-57433は、Perlのデータ永続化モジュールであるStorableに存在する整数オーバーフローの脆弱性です。Storableは、配列やハッシュ、オブジェクトなどのPerlデータ構造をバイナリ形式で保存し、後から復元するために使われます。(perldoc.perl.org)

主な情報を整理すると、次のとおりです。

項目内容
CVE番号CVE-2026-57433
対象OSAzure Linux 3.0
対象パッケージazl3 perl 5.38.2-512
対象コンポーネントPerl Storable
脆弱性の種類符号付き整数オーバーフロー、CWE-190
発生条件細工されたSX_HOOKレコードをthawまたはretrieveで逆シリアル化する
確認されている挙動負の値がav_extendに渡され、panicにより逆シリアル化処理が終了する
修正版azl3 perl 5.38.2-514
MSRCの回避策個別の回避策なし
基本対応5.38.2-514以降へ更新

上流のCVE情報では、Storable 3.41未満が影響を受けるとされています。ただし、Azure Linuxでは修正を既存のPerlパッケージへバックポートする場合があるため、Azure Linux上ではStorableの表示バージョンだけでなく、RPMのリリース番号を確認することが重要です。(GitHub)

整数オーバーフローが起きる仕組み

問題があるのは、Storableのretrieve_hook_commonという処理です。

StorableがSX_HOOKレコードを読み込む際、フックに含まれる項目数を符号付き32ビット整数として取得します。その値に1を加え、Perl内部の配列領域を確保するav_extendへ渡します。

細工されたデータによって項目数がI32_MAX、つまり符号付き32ビット整数の最大値になっていると、次の計算でオーバーフローします。

I32_MAX + 1

本来は最大値を超える正の値になるはずですが、符号付き整数では負の値へ巻き戻ります。その結果、av_extendが不正な負数を受け取り、panicによって逆シリアル化が中断されます。

上流の修正では、項目数がI32_MAXであることを事前に検出し、配列拡張処理へ進む前にエラーとして拒否するチェックが追加されています。(GitHub)

SX_HOOKは管理者が設定する機能ではない

SX_HOOKは、Storableがオブジェクト固有のシリアル化処理を扱う際に使う内部レコードです。AzureポータルやOSの設定画面で有効化する機能ではありません。

そのため、「SX_HOOKを無効にすればよい」という対応はできません。確認すべきなのは、アプリケーションがStorable形式のデータをどこから受け取り、thawやretrieveへ渡しているかです。

どの環境を優先して対応すべきか

Azure Linux 3.0にPerlが入っているだけで、直ちに外部から攻撃できるとは限りません。脆弱な処理へ細工されたStorableデータを到達させられるかどうかが、実際の危険度を左右します。

優先度利用状況の例判断
高API、アップロード、メッセージキューなどから受け取ったデータをStorableで復元している速やかに更新し、入力経路を一時停止または制限する
高外部ユーザーが書き込める共有ストレージやキャッシュをretrieveで読み込むファイル改ざん経路を含めて調査する
高細工された入力でPerlプロセスが繰り返し再起動する可能性があるサービス停止や再起動ループにつながるため優先対応する
中社内システムやバッチ処理でStorableを使用している入力元とファイル権限を確認し、保守時間内に更新する
低Perlは存在するがStorableを使用していないパッケージは更新しつつ、緊急停止までは通常不要
対象外Azure Linux 3.0ではない、または5.38.2-514以降を使用しているこのAzure Linux向け修正の対象外

特に注意したいのは、「インターネット公開していないから安全」とは限らない点です。攻撃者が直接HTTPリクエストを送れなくても、アップロードファイル、ジョブキュー、共有ディスク、セッションデータ、キャッシュなどを経由して細工されたデータが届く可能性があります。

一方、公開されている技術説明で具体的に確認されているのは、整数オーバーフロー後のpanicと逆シリアル化処理の終了です。整数オーバーフローという分類だけを根拠に、リモートコード実行が確認された脆弱性として扱うのは適切ではありません。実務上は、サービス停止やジョブ失敗を引き起こす可用性リスクを中心に評価しつつ、修正版を適用してください。

Azure Linux 3.0で影響を確認する手順

OSがAzure Linux 3.0か確認する

最初に、対象サーバーやコンテナのOSを確認します。

cat /etc/os-release

次のようにAzure Linux 3.0であることを示す情報が表示される環境が対象です。

NAME="Microsoft Azure Linux"
VERSION_ID="3.0"

Azure上で動作していても、OSがUbuntu、Red Hat Enterprise Linux、SUSE Linux Enterprise Serverなどであれば、MSRCが示すazl3 perl 5.38.2-514という修正版は適用できません。他のLinuxディストリビューションでは、それぞれのベンダーが公開するパッケージ情報を確認します。

Perl関連RPMのリリース番号を確認する

次のコマンドで、インストール済みのPerl関連パッケージとソースRPMを確認します。

rpm -q --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{SOURCERPM}\n' \
  perl perl-Storable perl-interpreter perl-libs

確認するポイントは、SOURCERPMに表示されるPerlパッケージのリリース番号です。

perl-5.38.2-512...

このように5.38.2-512が表示される場合は、修正前のパッケージです。更新後は次のように5.38.2-514以降になっていることを確認します。

perl-5.38.2-514...

Azure LinuxではStorableがPerlのサブパッケージとして分割されており、perl-Storable自体には3.32-512のような別のバージョン表記が表示される場合があります。そのため、perl-Storableの先頭のバージョンだけを見るのではなく、SOURCERPMと末尾のリリース番号を確認してください。Azure Linux 3.0のパッケージ定義でも、StorableはPerlソースパッケージから生成される構成になっています。(GitHub)

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

OS標準パッケージを更新しても、CPANから /usr/local 配下へ別のStorableをインストールしていると、そちらが優先して読み込まれることがあります。

実際に使用されるバージョンとファイルパスを確認します。

perl -MStorable -e \
  'printf "version=%s\npath=%s\n", $Storable::VERSION, $INC{"Storable.pm"}'

続いて、そのファイルがどのRPMに属しているかを確認します。

STORABLE_PM=$(perl -MStorable -e 'print $INC{"Storable.pm"}')
rpm -qf "$STORABLE_PM"

次のような場合は注意が必要です。

  • パスが/usr/local/libやユーザーのホームディレクトリを指している
  • rpm -qfで「どのパッケージにも属していない」と表示される
  • アプリケーション専用のPerl環境や独自ビルドを使用している
  • コンテナ内とホスト側で異なるStorableが読み込まれている

この場合、Azure LinuxのRPMを更新するだけでは、アプリケーションが実際に使用するStorableが修正されない可能性があります。独自のPerl環境では、Storable 3.41以降への更新または上流修正の取り込みを、使用しているビルド方法に合わせて実施します。

ただし、Azure Linuxのベンダーパッケージについてはバックポート修正があり得るため、$Storable::VERSIONが3.41未満という理由だけで脆弱と断定してはいけません。OS標準環境ではMSRCが示すRPMリリース番号を優先し、独自環境では実際に読み込まれるモジュールを確認するという切り分けが必要です。

アプリケーション内の利用箇所を検索する

アプリケーションのソースコードや運用スクリプトから、Storableの利用箇所を探します。

grep -RInE \
  'use[[:space:]]+Storable|Storable::(thaw|retrieve)|(thaw|retrieve)[[:space:]]*\(' \
  /opt /srv /app 2>/dev/null

検索結果が見つかったら、関数名だけで判断せず、次の点を確認します。

  • thawやretrieveへ渡すデータの作成者
  • 外部ユーザーがデータを書き換えられるか
  • APIやアップロード機能を経由するか
  • メッセージキューや共有ストレージを経由するか
  • ファイル所有者と書き込み権限が適切か
  • 失敗時にプロセスやジョブが自動再実行されるか

単純な文字列検索には誤検出や見落としがあります。共通ライブラリやフレームワークから間接的に呼び出している場合もあるため、実際の入力経路まで追跡してください。

Perlを5.38.2-514へ更新する方法

Azure Linux 3.0では、tdnfを使用してパッケージを更新します。最初にリポジトリ情報を更新します。

sudo tdnf makecache

利用可能な更新を確認します。

tdnf list updates | grep -E 'perl|Storable'

更新内容を確認したうえで、PerlとStorableを更新します。

sudo tdnf upgrade perl perl-Storable --refresh

環境によってはperl-interpreterやperl-libsなどの関連パッケージもインストールされています。依存関係によって同時に更新されるパッケージを、実行前のトランザクション表示で確認してください。tdnf upgradeは、指定したパッケージを利用可能な上位バージョンへ更新するコマンドです。(VMware)

更新後、再度RPM情報を確認します。

rpm -q --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{SOURCERPM}\n' \
  perl perl-Storable perl-interpreter perl-libs

少なくとも、Storableを含むPerlのソースRPMが5.38.2-514以降になっていることを確認します。

5.38.2-514が表示されない場合

リポジトリに修正版が表示されない場合は、次の順で確認します。

tdnf repolist
tdnf info perl
tdnf info perl-Storable

主な原因として、次のものが考えられます。

  • 社内RPMミラーの同期が遅れている
  • 古いリポジトリスナップショットへ固定されている
  • tdnf.confやリポジトリ設定でパッケージが除外されている
  • コンテナビルド時に古いキャッシュを再利用している
  • Azure Linux 3.0ではないリポジトリを参照している
  • 独自イメージ内でリポジトリが無効化されている

この状態でtdnfが「Nothing to do」と表示しても、5.38.2-512のままであれば対策完了ではありません。社内ミラーを最新化するか、修正版を取得できる正式なAzure Linux 3.0リポジトリへ接続できるようにします。

出所不明のRPMを手動で導入したり、他のLinuxディストリビューション向けRPMを混在させたりすると、依存関係やサポート性を損ないます。Microsoftが提供するAzure Linux用パッケージを使用してください。

更新後にサービスとコンテナを入れ替える

RPMを更新しただけでは、更新前のStorableコードを読み込んだまま動作している長時間稼働プロセスが残る可能性があります。

更新後は、次の対応を行います。

  • Storableを利用するPerlサービスやワーカーを再起動する
  • バッチ処理やジョブ実行基盤を再起動する
  • コンテナイメージを再ビルドする
  • 更新後のイメージをレジストリへ登録する
  • 既存コンテナやPodを更新後のイメージへ置き換える
  • 通常のStorableデータを使った復元処理をテストする
  • エラーログや再起動回数を監視する

ホストOSを更新しても、コンテナ内部のRPMは更新されません。反対に、コンテナイメージを修正しても、Azure Linuxホスト側でPerlを使っている場合はホストのパッケージが残ります。

VM、コンテナ、CI/CDランナー、カスタムイメージを別々の資産として確認することが重要です。

コンテナでは再起動だけでは不十分

脆弱なコンテナを単に再起動すると、同じ古いイメージから再作成されます。

次の流れで対応してください。

  1. Dockerfileやイメージビルド定義でパッケージ情報を更新する
  2. Perl関連パッケージを5.38.2-514以降へ更新する
  3. キャッシュを使わずに再ビルドする
  4. イメージ内でRPMリリース番号を検証する
  5. 新しいイメージをデプロイする
  6. 古いイメージや稼働中の旧コンテナが残っていないか確認する

SBOMやコンテナスキャナーが古いイメージを検出し続ける場合は、レジストリ内に残っている未使用イメージと、実際に稼働中のイメージを分けて確認します。

修正版をすぐ適用できない場合の暫定措置

MSRCはCVE-2026-57433に対する個別の回避策を掲載していません。したがって、以下は正式な回避策ではなく、修正版を適用するまでの補完的な露出低減策です。(msrc.microsoft.com)

信頼できないStorableデータを受け付けない

次のような入力をthawやretrieveへ渡す処理は、一時停止または別形式へ切り替えます。

  • ユーザーがアップロードしたバイナリデータ
  • APIリクエストに含まれるシリアル化データ
  • 外部システムから届くキューメッセージ
  • 複数テナントが書き込める共有ファイル
  • 出所を確認できないキャッシュやセッションファイル

Perlのセキュリティポリシーでも、Storableは高速なシリアル化形式として設計されており、信頼できない入力を安全に逆シリアル化するための形式ではないと説明されています。この注意点はCVE-2026-57433を修正した後も変わりません。(perldoc.perl.org)

外部システムとのデータ交換には、必要な項目だけをJSONなどで受け取り、スキーマやデータ型を検証する方式が適しています。

Storableファイルの書き込み権限を制限する

retrieveで読み込むファイルについて、次を確認します。

  • Webサーバーの公開ディレクトリへ置かれていないか
  • 一般ユーザーや別サービスが書き込めないか
  • 一時ディレクトリで安全でないファイル名を使っていないか
  • シンボリックリンクによる差し替えが可能ではないか
  • 共有ストレージのアクセス権が広すぎないか

ファイルを作成するプロセスと読み込むプロセスを特定し、必要最小限の権限に限定します。

バイナリ内容を独自に書き換えない

SX_HOOKを文字列検索して除去する、特定のバイト列だけを拒否するといった独自フィルターは推奨できません。

Storableはバイナリ形式であり、表現方法やレコード位置によって単純なパターン照合を回避される可能性があります。また、今回の問題は項目数フィールドの整数処理にあるため、ファイルサイズの上限だけでは十分な防御になりません。

暫定対応では、バイナリ内部を部分的に検査するよりも、信頼できないデータをStorableの逆シリアル化処理へ到達させないことを優先してください。

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

perl -vだけで判断する

修正前も修正後も、Perl本体の表示は5.38.2のままになる可能性があります。

perl -v

このコマンドではRPMの-512と-514を区別できません。必ずrpm -qでリリース番号を確認します。

Storableのバージョンだけで判断する

perl -MStorable -e 'print "$Storable::VERSION\n"'

上流ではStorable 3.41が修正版ですが、Linuxディストリビューションは修正コードだけを古いバージョンへバックポートすることがあります。

Azure Linux標準パッケージの判定では、MSRCが示すperl 5.38.2-514というRPMリリースを基準にしてください。

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

コンテナ内部のPerlは、ホスト側のtdnf upgradeでは更新されません。コンテナイメージの再ビルドと再デプロイが必要です。

更新したが常駐プロセスを再起動しない

既に読み込まれたStorableのネイティブコードは、プロセス内に残る可能性があります。サービス、ワーカー、ジョブ実行環境を再起動し、更新後のコードを読み込ませます。

CPAN版を安易に上書きする

OS標準のPerlへ管理者権限でCPAN版Storableを追加すると、/usr/local配下のモジュールがRPM版を上書きすることがあります。

短期的にバージョンが上がっても、次の問題が発生しやすくなります。

  • RPMデータベースから構成を追跡できない
  • OS更新後もCPAN版が優先される
  • XSモジュールとPerl本体の互換性が崩れる
  • 脆弱性スキャナーの判定と実際の読み込み状態が一致しない
  • ベンダーサポート時の切り分けが難しくなる

Azure Linux標準環境では、MSRCが示すRPM更新を第一選択にします。

対応完了の確認項目

CVE-2026-57433への対応は、パッケージを更新した時点ではなく、実際の稼働環境から修正前のコードがなくなった時点で完了です。

  • Azure Linux 3.0の全VMとイメージを洗い出した
  • perlまたはperl-Storableの有無を確認した
  • ソースRPMがperl-5.38.2-514以降であることを確認した
  • 実際に読み込まれるStorable.pmのパスを確認した
  • /usr/localなどに古いCPAN版が残っていないことを確認した
  • thawとretrieveへ渡るデータの入力元を確認した
  • 関連する常駐サービスやワーカーを再起動した
  • コンテナイメージを再ビルドして再デプロイした
  • 正常なStorableデータで回帰テストを実施した
  • 古いVMイメージ、スナップショット、コンテナイメージにも更新を反映した

まとめ

CVE-2026-57433の基本対応は、Azure Linux 3.0のPerlを5.38.2-512から5.38.2-514以降へ更新することです。MSRCに個別の回避策は掲載されていないため、入力チェックだけで済ませず、ベンダー提供パッケージを適用してください。

確認時はperl -vや$Storable::VERSIONだけを見ず、rpm -qのリリース番号とSOURCERPMを確認します。独自のPerl環境やコンテナを使用している場合は、実際に読み込まれるStorableのパスまで調査が必要です。

最初に全環境で次のコマンドを実行し、5.38.2-512が残っているホストやコンテナを更新対象として管理してください。

rpm -q --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{SOURCERPM}\n' \
  perl perl-Storable perl-interpreter perl-libs
Azure
Perl 脆弱性対策 Azure Linux CVE-2026-57433 Storable

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次