MENU

CVE-2026-60082とは？Azure Linux 3.0のPerl DBI脆弱性と修正版1.651-1

Azure

Azure Linux 3.0でperl-DBI 1.643-5を利用している場合は、修正版の1.651-1以降へ更新する必要があります。CVE-2026-60082は、Perl DBIがステートメントハンドルの列情報と取得行の要素数の整合性を適切に検証せず、配列の範囲外を読み取る可能性がある脆弱性です。

通常のSQL実行だけで直ちに悪用されるとは限りません。しかし、外部から不整合な列メタデータと行データを渡せる構成では、Perlプロセスの異常終了やメモリ情報への影響が生じる可能性があります。MSRCは個別の回避策を示していないため、まず実際に読み込まれているDBIのバージョンを確認し、更新後にサービスやコンテナを再起動することが重要です。(msrc.microsoft.com)

目次

CVE-2026-60082とは

CVE-2026-60082は、Perlからデータベースへアクセスするための共通インターフェース「DBI」に存在する、境界外読み取りの脆弱性です。

概要は次のとおりです。

項目内容
CVE番号CVE-2026-60082
対象Perl DBI
Azure Linux 3.0の対象パッケージperl-DBI 1.643-5
上流で影響を受けるバージョンDBI 1.651未満
Azure Linux 3.0の修正版perl-DBI 1.651-1以降
脆弱性の種類CWE-125：境界外読み取り
主な影響Perlプロセスのクラッシュ、意図しないメモリ領域の読み取り
MSRCの回避策個別の回避策なし
基本対応修正版への更新

CVEの公式レコードでは、DBI 1.651未満が影響を受けるとされています。Azure Linux側では、perl-DBIを1.651へ更新する修正が取り込まれ、1.651-1としてパッケージ化されています。(GitHub)

ステートメントハンドルと取得行の整合性とは

Perl DBIでは、SQLの実行結果を扱うオブジェクトとして「ステートメントハンドル」が使われます。ステートメントハンドルには、結果セットの列数や列名などの情報が保持されます。

通常は、次のように列情報と取得行が対応します。

列情報：3列
取得行：[値1, 値2, 値3]

CVE-2026-60082では、次のような不整合が問題になります。

列情報：0列
取得行：[値1]

内部関数_set_fbavは、取得した行をステートメントハンドル側の行バッファへコピーします。しかし、修正前の実装では、ステートメントハンドルの列数が0で取得行が空でない場合、配列インデックスが-1から始まり、配列の直前にあるメモリを参照する可能性がありました。

上流のセキュリティアドバイザリでは、通常のメモリアロケータを使った環境では不正なポインタを読み取ってプロセスがクラッシュし、AddressSanitizerを有効にしたビルドではヒープバッファーオーバーフローの読み取りとして検出されると説明されています。(GitHub)

修正版では、列数0の行バッファに空でない行を設定しようとした時点で処理を拒否し、境界外アクセスへ進まないように変更されています。(GitHub)

どのような環境で影響が大きくなるのか

この脆弱性は、単にWebアプリケーションがPerl DBIで通常のSQLを実行しているだけでは、直ちに攻撃可能になるとは限りません。

上流のアドバイザリでは、攻撃や異常終了を引き起こすには、呼び出し側が次の両方を制御できる必要があると説明されています。

  • ステートメントハンドルへ渡される列メタデータ
  • 実際に取得行として渡される配列の要素

具体的には、次のような構成を優先的に調査します。

構成対応優先度判断理由
DBI::GoferやProxyServerを外部・非信頼ネットワークから利用できる高不正なメタデータと行をリモート側から渡される可能性がある
DBD::Spongeへ外部入力を基にした列情報・行データを渡している高公開されている再現条件に近い
独自のPerl DBDドライバーを使用している中～高列情報と行データの整合性が実装に依存する
内部システムだけでDBI::GoferやDBD::Spongeを使用している中ネットワーク境界内でも侵害済み端末から到達される可能性がある
一般的なDBD::mysqlやDBD::Pgで固定SQLのみを実行している相対的に低い通常のSQLだけでは問題の条件に到達しにくい
DBIがインストールされているだけで、アプリケーションから使われていない低実行経路がなければ直接の悪用可能性は低い

上流のアドバイザリは、通常のSQL処理では問題の箇所へ到達しない一方、悪意あるDBI::GoferまたはProxyServerの接続先が、不整合なメタデータと行を返すケースを到達可能な経路として挙げています。(GitHub)

ただし、「通常のSQLしか使っていないため更新不要」と判断するべきではありません。DBI 1.651にはCVE-2026-60082以外の修正も含まれており、更新そのものが可能な環境では、到達可能性の調査より先に修正版を検証する方が効率的です。DBI 1.651の変更履歴には、CVE-2026-60082を含む複数のセキュリティ修正が記録されています。(MetaCPAN)

深刻度が「Critical」と「Moderate」に分かれている理由

CVE-2026-60082は、公開情報によって深刻度の表示が異なります。

CVE公式レコードのCISA ADPによる補足評価では、CVSS 3.1の基本値が9.1、Criticalとされています。ベクターは次のとおりです。

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

これは、ネットワーク経由、低い攻撃複雑性、認証不要、利用者操作不要という条件を想定した評価です。一方、Perl DBIの上流GitHub Security Advisoryは、攻撃者が列メタデータと取得行の両方を制御する必要があり、通常のSQLでは到達しないことから、深刻度をModerateとしています。Azure Linuxの修正プルリクエストにはCRITICALラベルが付けられています。(GitHub)

この違いを踏まえると、実務上は次のように判断します。

インターネット公開の有無だけで判断せず、不整合なDBIメタデータと行データを非信頼側から渡せるかを確認することが重要です。

DBI::GoferやProxyServerを使用している環境、独自DBDを実装している環境、外部入力からDBD::Spongeの行を生成している環境では、優先度を上げて対応します。

なお、CISA ADPのSSVC情報では、2026年7月15日時点でExploitation: noneと記録されています。これは既知の悪用を示す情報が確認されていないという意味であり、今後も悪用されないことを保証するものではありません。(GitHub)

Azure Linux 3.0で影響を確認する方法

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

まず、対象サーバーやコンテナがAzure Linux 3.0であることを確認します。

cat /etc/os-release

VERSION_IDなどに3.0が表示されるか確認してください。

表示例は環境やイメージのリビジョンによって異なりますが、少なくともOS名とメジャーバージョンを確認します。

RPMパッケージのバージョンを確認する

Azure LinuxのRPMとしてインストールされたperl-DBIは、次のコマンドで確認できます。

rpm -q perl-DBI

影響を受ける表示例は次のとおりです。

perl-DBI-1.643-5.azl3.x86_64

ARM64環境では、末尾が次のようになる場合があります。

perl-DBI-1.643-5.azl3.aarch64

更新後は、次のように1.651-1以降が表示されることを確認します。

perl-DBI-1.651-1.azl3.x86_64

または、

perl-DBI-1.651-1.azl3.aarch64

MicrosoftのAzure Linux 3.0向けパッケージリポジトリには、1.643-5、1.650-1、修正版の1.651-1が掲載されています。(packages.microsoft.com)

実際にPerlが読み込んでいるDBIを確認する

RPMの確認だけでは不十分です。アプリケーションがCPAN、cpanm、local::lib、perlbrewなどで別のDBIを読み込んでいる可能性があるためです。

次のコマンドで、実際に読み込まれるDBIのバージョンとファイルパスを確認します。

perl -MDBI -e 'printf "DBI=%s\nPATH=%s\n", $DBI::VERSION, $INC{"DBI.pm"}'

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

DBI=1.643
PATH=/usr/lib/perl5/vendor_perl/DBI.pm

DBIが1.651未満なら影響対象です。

特に注意したいのは、RPMが更新済みでも次のようなパスが表示されるケースです。

/usr/local/lib/perl5/DBI.pm
/opt/app/local/lib/perl5/DBI.pm
/home/app/perl5/lib/perl5/DBI.pm

この場合、OSのRPMよりもCPANなどで導入した古いDBIが優先されている可能性があります。アプリケーションが使用するPerl実行ファイルを明示して確認してください。

/path/to/application/perl -MDBI -e 'printf "DBI=%s\nPATH=%s\n", $DBI::VERSION, $INC{"DBI.pm"}'

問題のある機能を使用していないか確認する

ソースコードや設定ファイルから、関連するモジュールの利用状況を検索します。

grep -RInE \
  'DBD::Sponge|DBI::Gofer|ProxyServer|use[[:space:]]+DBI|DBI->connect' \
  /path/to/application

use DBIやDBI->connectが見つかっただけでは、脆弱な処理へ到達できるとは限りません。

優先して確認するのは、次の処理です。

  • DBD::Spongeで列名や行を動的に生成している
  • 外部入力からNAMEやrowsを構築している
  • DBI::Goferをリモート接続に使っている
  • ProxyServerを公開している
  • 独自DBDドライバーが行バッファを操作している

perl-DBIを1.651-1へ更新する手順

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

利用可能なバージョンを確認する

sudo tdnf makecache
tdnf list perl-DBI

リポジトリ側に1.651-1以降が表示されることを確認します。

perl-DBIを更新する

sudo tdnf update perl-DBI -y

キャッシュが古く、修正版が表示されない場合は、キャッシュを削除してから再取得します。

sudo tdnf clean all
sudo tdnf makecache
sudo tdnf update perl-DBI -y

更新結果を確認する

rpm -q perl-DBI
perl -MDBI -e 'printf "DBI=%s\nPATH=%s\n", $DBI::VERSION, $INC{"DBI.pm"}'

次の2点を確認してください。

  • RPMパッケージが1.651-1以降
  • 実際に読み込まれるDBIモジュールが1.651以降

1.650-1ではCVE-2026-60082は修正されていません。 DBI 1.650では別の脆弱性が修正されていますが、今回の修正は1.651に含まれています。(MetaCPAN)

関連サービスを再起動する

更新後は、DBIを使用する長時間稼働中のPerlプロセスを再起動します。

対象となるサービスを確認したうえで、個別に再起動してください。

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

コンテナ環境では、RPMを更新しただけの一時的なコンテナを使い続けるのではなく、イメージを再ビルドして再デプロイします。

コンテナイメージにperl-DBIが含まれる場合

Azure Linux 3.0をベースにしたコンテナでは、ホスト側のperl-DBIを更新しても、コンテナ内のパッケージは更新されません。

Dockerfileなどのビルド定義で更新します。

RUN tdnf -y update perl-DBI \
    && rpm -q perl-DBI \
    && tdnf clean all

その後、次の順序で対応します。

  1. コンテナイメージを再ビルドする
  2. ビルドログでperl-DBI-1.651-1以降を確認する
  3. イメージスキャンを再実行する
  4. 新しいイメージをデプロイする
  5. 古いPodやコンテナが残っていないことを確認する

CPAN経由でDBIを導入しているイメージでは、RPMの更新ではなく、依存関係ファイルやビルド処理でDBIを1.651以降へ更新する必要があります。

AKSのAzure Linuxノードで検出された場合

AKSのAzure LinuxノードOSで脆弱なパッケージが検出された場合は、個々のノードへSSH接続して恒久的に変更するのではなく、最新のノードイメージへ更新する方法を優先します。

Microsoftは、AKSのノードイメージ更新について、自動アップグレードチャネルまたは手動のノードイメージアップグレードを利用する方法を案内しています。(Microsoft Learn)

ただし、次の2つは分けて対応してください。

検出場所対応
AKSノードOSノードイメージを更新する
Podのコンテナイメージアプリケーションイメージを再ビルドして再デプロイする

ノードイメージだけを更新しても、Pod内に古いperl-DBIが含まれていれば解消しません。逆に、アプリケーションイメージだけを更新しても、ノードOS側の検出は残る可能性があります。

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

MSRCは、CVE-2026-60082に対する個別の回避策を掲載していません。そのため、以下は修正版の代わりではなく、更新までの一時的なリスク低減策です。(msrc.microsoft.com)

  • DBI::GoferやProxyServerを外部ネットワークへ公開しない
  • 接続元をファイアウォールやネットワークポリシーで制限する
  • 非信頼データからDBD::SpongeのNAMEやrowsを生成しない
  • 列数0のメタデータに空でない行を組み合わせないよう、アプリケーション側で検証する
  • 独自DBDが返す列数と行要素数の一致を確認する
  • 影響する機能を一時停止できる場合は停止する
  • Perlプロセスの異常終了や再起動回数を監視する

とくに、外部からメタデータと行を受け取る経路を遮断できない環境では、暫定対応だけで長期間運用せず、修正版の適用を優先してください。

対応時に起こりやすい見落とし

見落とし問題点正しい対応
perl本体だけを更新する脆弱性はDBIモジュールにあるperl-DBIを更新する
1.650-1で安全と判断するCVE-2026-60082の修正は1.6511.651-1以降を確認する
rpm -qだけで確認するCPAN版DBIが優先される可能性がある$DBI::VERSIONと$INC{"DBI.pm"}も確認する
ホストOSだけを更新するコンテナ内のパッケージは変わらないイメージを再ビルドする
実行中サービスを再起動しない更新前に読み込んだコードが使われ続ける可能性があるサービス再起動または再デプロイを行う
CVSSだけで優先度を決める実際の到達可能性を見落とすGofer、ProxyServer、Sponge、独自DBDを確認する
既知の悪用なしを安全と解釈する将来の悪用可能性は否定できない修正版の適用を進める

Azure Linux 3.0管理者が今すぐ行うこと

CVE-2026-60082への対応は、次の順序で進めます。

  1. rpm -q perl-DBIでRPMの導入状況を確認する
  2. アプリケーションが実際に読み込むDBIのバージョンとパスを確認する
  3. DBI 1.651未満ならperl-DBI 1.651-1以降へ更新する
  4. DBIを使用するサービス、コンテナ、Podを再起動または再デプロイする
  5. 更新後にRPMと実行時モジュールの両方を再確認する
  6. DBI::Gofer、ProxyServer、DBD::Sponge、独自DBDの利用箇所を調査する

CVE-2026-60082は、通常のSQL処理だけで簡単に到達する脆弱性ではない一方、条件を満たすとメモリ境界外の読み取りやプロセス停止につながります。公式の個別回避策がないため、到達可能性の評価だけで対応を止めず、perl-DBI 1.651-1以降への更新を完了させることが最も確実な対策です。

Azure
セキュリティ更新 脆弱性 Azure Linux Perl DBI CVE-2026-60082

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次