CVE-2026-60081とは？Azure LinuxのPerl DBIリソース枯渇と1.651-1への更新手順

Azure Linux 3.0でperl-DBIを利用している場合、CVE-2026-60081への基本対策は、修正版のperl-DBI 1.651-1以降へ更新することです。この脆弱性では、DBI::ProfileDataがプロファイルダンプ内のパスインデックスを無制限に受け入れるため、細工された小さなファイルから大量のメモリを消費し、Perlプロセスや関連サービスが停止する可能性があります。

MSRCの対象情報ではAzure Linux 3.0のazl3 perl-DBI 1.643-5が挙げられていますが、上流のDBIでは1.651未満が影響対象です。そのため、1.650などの中間バージョンでも安全とは判断できません。MSRCには個別の回避策が掲載されていないため、実際に読み込まれているモジュールを確認し、更新後に関連プロセスやコンテナを再起動するところまで対応する必要があります。(Microsoft Security Response Center)

CVE-2026-60081とは

CVE-2026-60081は、Perlからデータベースを扱うための共通インターフェース「DBI」に含まれるDBI::ProfileDataのリソース制限不備です。

DBI::ProfileDataは、DBIの実行状況を記録したプロファイルダンプを読み込み、集計や分析を行うために使われます。通常のSQL文を実行する処理そのものではなく、保存済みのプロファイルデータを解析する部分が問題になります。

項目	内容
CVE番号	CVE-2026-60081
対象コンポーネント	Perl DBIの`DBI::ProfileData`
問題のある処理	`DBI::ProfileData::_read_body`
上流の影響バージョン	DBI 1.651未満
Azure Linux 3.0で示された対象	`azl3 perl-DBI 1.643-5`
Azure Linux 3.0の修正版	`perl-DBI 1.651-1`
脆弱性の分類	CWE-770：制限やスロットリングを行わないリソース割り当て
主な影響	メモリ枯渇、プロセス停止、サービス拒否
機密性への直接的な影響	上流情報では示されていない
任意コード実行	上流情報では示されていない
MSRCの個別回避策	掲載なし
基本対策	1.651-1以降への更新

CVEレコードでは、修正方法としてDBI 1.651以降への更新が示されています。Azure Linux側でも、パッケージのバージョンを1.651、リリース番号を1へ変更する更新が取り込まれています。(GitHub)

DBI::ProfileDataでリソース枯渇が起きる仕組み

パスインデックスが無制限に配列へ反映される

DBIのプロファイルダンプには、プロファイル情報の階層を表すパスインデックスが含まれます。脆弱なバージョンでは、ファイルから読み込んだインデックス値について、妥当な上限を確認しないままPerlの配列へ反映していました。

非常に大きなインデックスが指定されると、@path配列が巨大な疎配列として拡張されます。その後の処理では、この配列が文字列として結合されたり、別の配列へコピーされたりするため、入力ファイルの大きさに比べて大幅に多くのメモリが消費されます。

上流の修正では、$MAX_PATH_DEPTHの既定値として256を設定し、負数や上限を超えるインデックスを検出した場合は、配列を変更する前にエラーで処理を中止するよう変更されています。(GitHub)

ファイルサイズ制限だけでは防げない

この問題の重要な点は、巨大なプロファイルファイルを用意する必要がないことです。上流アドバイザリでは、非常に小さな入力でも巨大なインデックスを指定することで、メモリ使用量や警告ログを大きく増幅できる例が示されています。

そのため、アップロード可能なファイルを数MB以下に制限していても、十分な対策にはなりません。確認すべきなのはファイル容量だけではなく、信頼できないプロファイルダンプがDBI::ProfileDataやdbiprofへ渡される経路があるかです。(GitHub)

通常のデータベース接続だけで直ちに悪用されるわけではない

CVE-2026-60081は、通常のSQLクエリやデータベースから取得した行データを処理するだけで直接発生する問題ではありません。主な攻撃対象は、DBIのプロファイルダンプを解析する処理です。

上流アドバイザリでは、コマンドラインツールのdbiprofが指定されたファイルをDBI::ProfileDataへ渡すことや、次のような運用で信頼境界を越える可能性が指摘されています。

利用者から受け取ったサポート用ファイルを自動解析する
CIや監視基盤が外部生成のプロファイルダンプを処理する
Webサービスでプロファイルファイルをアップロードさせる
複数ユーザーが書き込める共有フォルダを定期処理する
別システムから収集した診断データをバッチ解析する

単にperl-DBIがインストールされているだけでは、直ちに攻撃が成立するとは限りません。ただし、利用状況を確認せず「通常のSQL処理しかしていないはず」と判断するのも危険です。(GitHub)

深刻度の表示が異なる理由

公開情報では、CVE-2026-60081の深刻度表記が一様ではありません。CVEレコードのCISAによる補足評価では、CVSS 3.1の基本値が7.5、深刻度はHighとされています。一方、上流のGitHub Security AdvisoryではLowに分類されています。(GitHub)

これは、評価時に想定する到達経路が異なるためです。

CVEの評価は、ネットワーク経由のサービスから信頼できないファイルを自動処理できる構成も含めた影響を想定できます。一方、上流アドバイザリは、入力がプロファイルダンプファイルであり、通常のデータベース入力経路ではないことや、影響が主に解析プロセスの停止であることを重視しています。

実務ではスコアだけで判断せず、次の条件を確認して優先順位を決めます。

環境	実務上の優先度	判断理由
外部ユーザーがファイルをアップロードでき、自動で解析する	最優先	認証なしでパーサーへ到達する可能性がある
サポートファイルやCI成果物を自動解析する	高	信頼境界を越えたファイルが処理される
低権限ユーザーが書き込める共有領域を定期処理する	高	ローカルユーザーからサービス停止を誘発され得る
信頼済みシステムだけが生成したファイルを処理する	中	到達可能性は低いが、誤生成や侵害時の影響が残る
`perl-DBI`はあるがプロファイル解析機能を使用していない	低め	現時点の到達可能性は低いが、将来の利用や検出漏れに注意
メモリ制限のない共有サーバーで解析する	優先度を引き上げる	解析プロセス以外へ影響が波及しやすい

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

OSとRPMパッケージを確認する

最初に、対象サーバーがAzure Linux 3.0であることと、RPM版のperl-DBIが導入されているかを確認します。

cat /etc/os-release

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' perl-DBI

脆弱な構成の例は次のような表示です。

perl-DBI-1.643-5.azl3.x86_64

ただし、1.643-5以外なら安全という意味ではありません。上流では1.651未満が影響対象なので、1.644、1.650なども更新が必要です。Azure Linuxの更新履歴でも、1.650から1.651への変更がCVE-2026-60081の修正として取り込まれています。(GitHub)

Perlが実際に読み込むDBIのバージョンを確認する

RPMの確認だけでは不十分です。CPAN、cpanm、Carton、アプリケーション同梱モジュール、PERL5LIBなどにより、RPMとは別のDBIが優先して読み込まれることがあるためです。

実行時のDBIバージョンを確認します。

perl -MDBI -e 'print "$DBI::VERSION\n"'

続けて、DBI::ProfileDataの読み込み元を確認します。

perl -MDBI::ProfileData -e 'print $INC{"DBI/ProfileData.pm"}, "\n"'

表示されたファイルがRPMに含まれるかを調べるには、次のように実行します。

module_path="$(perl -MDBI::ProfileData -e 'print $INC{"DBI/ProfileData.pm"}')"

printf '%s\n' "$module_path"
rpm -qf "$module_path"

rpm -qfで「どのパッケージにも属していない」と表示された場合は、CPANやアプリケーション固有のディレクトリから読み込まれている可能性があります。その場合、OSパッケージだけを更新しても実行時の脆弱性は解消しません。

サービス専用ユーザーで動作している場合は、そのユーザーでも確認します。

sudo -u <service-user> perl -MDBI -e 'print "$DBI::VERSION\n"'

sudo -u <service-user> \
  perl -MDBI::ProfileData \
  -e 'print $INC{"DBI/ProfileData.pm"}, "\n"'

systemdユニットでPERL5LIBなどを指定している場合は、ユニット設定も確認してください。

systemctl cat <service-name>
systemctl show <service-name> -p Environment

DBI::ProfileDataを使っている処理を探す

アプリケーション、バッチ、監視設定から、関連する文字列を検索します。

grep -RInE \
  'DBI::ProfileData|dbiprof|DBI_PROFILE' \
  /etc /opt /srv /usr/local 2>/dev/null

プロファイルファイルも、対象ディレクトリを限定して確認します。

find /var/log /opt /srv \
  -xdev \
  -type f \
  -name 'dbi.prof*' \
  -print 2>/dev/null

全ファイルシステムを無条件に検索すると、本番環境でI/O負荷が高くなることがあります。アプリケーションの配置先、ログ保存先、バッチの作業ディレクトリから確認するのが安全です。

特に、次の流れが存在しないかを追跡します。

外部または低信頼のファイル
        ↓
アップロード領域・共有フォルダ・サポートバンドル
        ↓
バッチ、CI、監視ツール、dbiprof
        ↓
DBI::ProfileData

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

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

リポジトリ情報を更新し、perl-DBI 1.651-1以降が候補に表示されるか確認します。

sudo dnf --refresh makecache

dnf --showduplicates list perl-DBI

候補に修正版が表示されない場合は、すぐにCPAN版をシステム領域へ上書きするのではなく、先に次を確認します。

sudo dnf clean all
sudo dnf makecache

dnf repolist
dnf --showduplicates list perl-DBI

確認すべき項目は次のとおりです。

Azure Linux 3.0用の正しいリポジトリが有効か
社内ミラーの同期が完了しているか
プロキシやリポジトリキャッシュが古くないか
更新を固定するversionlockが設定されていないか
コンテナビルド時に古いリポジトリスナップショットを参照していないか

perl-DBIを更新する

perl-DBIだけを対象に更新する場合は、次のコマンドを使用します。

sudo dnf update -y perl-DBI

組織の運用方針でセキュリティ更新をまとめて適用する場合は、Azure Linuxの一般的な更新手順に従います。

sudo dnf update -y

MicrosoftのAzure Linux向け資料では、汎用Azure LinuxのCVE修正はパッケージ更新として配信され、dnf updateで適用するよう案内されています。(Microsoft Learn)

更新結果を確認する

RPMのバージョンと、Perlが実際に読み込むモジュールの両方を再確認します。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' perl-DBI

perl -MDBI -e 'print "$DBI::VERSION\n"'

perl -MDBI::ProfileData \
  -e 'print $INC{"DBI/ProfileData.pm"}, "\n"'

期待する結果は次のとおりです。

RPMパッケージ：perl-DBI-1.651-1.azl3.<architecture>
Perlモジュール：1.651

Azure Linuxの修正コミットでは、x86_64とaarch64の両方についてperl-DBI-1.651-1.azl3へ更新されています。(GitHub)

RPMは1.651-1になっているのに、Perlモジュールの表示が1.650以下の場合は、別のディレクトリにあるDBIが優先されています。次のコマンドでPerlの検索パスも確認します。

perl -e 'print "$_\n" for @INC'

古いモジュールが/usr/local/lib、アプリケーション配下のlocal/lib、Cartonのlocalディレクトリなどに残っていないかを確認してください。

サービスやコンテナを再起動する

更新前から起動している長時間稼働のPerlプロセスは、すでに古いモジュールをメモリへ読み込んでいる可能性があります。パッケージ更新だけで対応完了とせず、DBIを利用するサービスを再起動します。

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

定期バッチの場合は、実行中のジョブが終了していることを確認し、次回実行前に更新後のバージョンが読み込まれることを確認します。

コンテナ内にperl-DBIが含まれている場合、ホストOSのRPMを更新しても既存のコンテナイメージは変わりません。次の対応が必要です。

コンテナイメージを修正版パッケージで再ビルドする
イメージ内でrpm -q perl-DBIと$DBI::VERSIONを確認する
新しいイメージをレジストリへ登録する
Podやコンテナを再デプロイする
実行中のコンテナ内でもバージョンを確認する

配置形態によって更新方法が異なる

Azure Linux関連環境では、配置形態によってCVE修正の受け取り方が異なります。

配置形態	対応方法
Azure Linux 3.0のVM、VM Scale Sets、カスタムイメージ	`dnf`でパッケージを更新
Azure Linuxをベースにしたアプリケーションコンテナ	イメージを再ビルドして再デプロイ
Azure Linux Container Host for AKS	ノードイメージの更新状況を確認し、必要に応じてノード更新
イミュータブルなAzure Container Linux for AKS	個別RPMを更新せず、`NodeImage`チャネルでノードイメージを更新

Microsoftは、一般用途のAzure Linuxではパッケージ更新、Azure Linux Container Hostではノードイメージ、イミュータブルなAzure Container LinuxではNodeImageチャネルを利用するよう説明しています。(Microsoft Learn)

更新後に実施する動作確認

アプリケーションの基本動作を確認する

DBI 1.651への更新後は、少なくとも次の処理を確認します。

データベースへの接続
SQLの実行
トランザクションの開始、コミット、ロールバック
バッチ処理
DBIプロファイリングを利用している場合はプロファイル出力
正常なプロファイルダンプの解析
監視ツールやレポート生成処理

DBI 1.651にはCVE-2026-60081以外の複数のセキュリティ修正も含まれています。リリースノートでは、DBI::SQL::Nano、DBD::File、ステートメントハンドル処理などの変更も示されているため、データベース関連の主要機能を確認してから本番展開するのが安全です。(MetaCPAN)

OOMや異常終了が発生していないか確認する

更新前後のログを確認します。

journalctl -u <service-name> --since "-30 min"

journalctl -k --since "-30 min" |
  grep -Ei 'out of memory|oom|killed process'

次の兆候がある場合は、CVE-2026-60081以外の問題も含めて調査します。

Perlプロセスの急激なメモリ増加
OOM Killerによるプロセス終了
Invalid path indexエラー
プロファイル解析の大量警告
サービスの再起動ループ
コンテナのOOMKilled
レポート生成処理のタイムアウト

修正版では、上限を超えるパスインデックスを含むファイルに対して、メモリを大量消費する前にエラーを返す動作が追加されています。したがって、更新後にInvalid path indexが記録された場合は、単なるアプリケーション障害として消すのではなく、入力元やファイル生成処理も確認してください。(GitHub)

すぐに更新できない場合の一時的なリスク低減策

MSRCにはCVE-2026-60081専用の回避策が掲載されていません。以下は正式な修正の代わりではなく、更新までの間に影響を抑えるための補完策です。(Microsoft Security Response Center)

信頼できないプロファイルファイルを処理しない

最も優先すべき対応は、外部や低信頼の利用者が用意したプロファイルダンプをDBI::ProfileDataへ渡さないことです。

外部アップロード後の自動解析を停止する
サポートバンドルの自動処理を一時停止する
共有フォルダからの自動取り込みを停止する
CIで外部Pull Request由来の成果物を解析しない
メール添付やチケット添付を自動でdbiprofへ渡さない

ファイルサイズの制限だけでは、今回のメモリ増幅を十分に防げません。

ファイルとディレクトリの権限を見直す

プロファイルダンプの保存先を、解析プロセスと信頼済み生成プロセスだけが書き込める状態にします。

確認例は次のとおりです。

namei -l /path/to/dbi.prof
ls -ld /path/to/profile-directory
ls -l /path/to/dbi.prof

特に、次の設定は見直しが必要です。

全ユーザーが書き込めるディレクトリ
共有グループに過剰な書き込み権限がある
/tmpからファイル名だけを指定して読み込む
シンボリックリンクを考慮していない
アップロード領域と解析領域が同じ
解析プロセスがroot権限で動作している

解析処理へメモリ制限を設ける

systemdやコンテナランタイムでメモリ上限を設定すると、ホスト全体のメモリ枯渇を抑えられます。ただし、攻撃者による解析プロセスの停止そのものは防げません。

systemdサービスでは、ワークロードで検証した値をMemoryMaxへ設定できます。

sudo systemctl edit <service-name>

[Service]
MemoryMax=<workload-tested-limit>

設定後は反映と再起動を行います。

sudo systemctl daemon-reload
sudo systemctl restart <service-name>

制限値を小さくしすぎると正常な集計処理まで停止するため、通常時の最大メモリ使用量を測定して設定してください。

解析処理を分離する

プロファイル解析を、Webサーバーやデータベース連携サービスと同じ長時間稼働プロセス内で実行しないことも有効です。

一時的には、次のような分離が考えられます。

専用の低権限ユーザーで実行する
使い捨てコンテナやジョブとして実行する
タイムアウトを設定する
メモリ上限付きのワーカーへ移す
解析失敗時に自動再試行を繰り返さない

これらは被害範囲を限定する対策であり、perl-DBI 1.651-1への更新を不要にするものではありません。

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

MSRCに記載された1.643-5だけを対象にする

上流の影響範囲は1.651未満です。1.644や1.650でも影響を受けるため、バージョン番号が1.643-5と一致しないことを理由に対象外としないでください。(GitHub)

RPMだけ更新して実行時のモジュールを確認しない

CPAN版やアプリケーション同梱版が優先されていると、RPMを1.651-1へ更新しても古いDBIが読み込まれます。$DBI::VERSIONと$INC{"DBI/ProfileData.pm"}を必ず確認します。

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

ホストのperl-DBIと、コンテナイメージ内のperl-DBIは別管理です。脆弱なイメージを再デプロイすれば問題が再発します。

パッケージ更新後にサービスを再起動しない

既存のPerlプロセスは、更新前に読み込んだコードを使い続ける可能性があります。関連サービス、ワーカー、Pod、常駐バッチを再起動または再デプロイします。

ファイルサイズ制限だけで対策済みとする

今回の脆弱性は、小さなファイルから大きなメモリ消費を発生させられる点が問題です。容量制限は補助対策にしかなりません。(GitHub)

システムRPMの上へCPAN版を直接インストールする

緊急対応としてcpanやcpanmでグローバル領域へDBIを上書きすると、RPM管理とPerlモジュール管理が分離し、将来の更新や脆弱性スキャンが不正確になることがあります。

アプリケーションがCPANモジュールを独自管理している場合は、cpanfileやロックファイルでDBI 1.651以降を明示し、ビルドパイプラインから再構築してください。システム標準のDBIはRPMで管理するのが基本です。

CVE-2026-60081に関するよくある疑問

DBIを使ってデータベースへ接続しているだけでも危険ですか

通常のデータベース接続やSQL実行だけで、直ちにこの脆弱性が発生するわけではありません。主な問題は、DBI::ProfileDataがプロファイルダンプを解析する処理です。

ただし、DBIプロファイリングが環境変数や設定ファイルで有効化されている場合や、運用ツールがdbiprofを呼び出している場合があります。コード検索だけでなく、バッチ、CI、監視、サポート運用も確認してください。(GitHub)

DBI 1.650は安全ですか

安全ではありません。上流の影響範囲は1.651未満であり、修正版は1.651です。Azure LinuxではRPMの修正版として1.651-1が用意されています。(GitHub)

1.651と1.651-1の違いは何ですか

1.651は上流Perlモジュールのバージョンです。1.651-1はAzure LinuxのRPMで使われる「バージョン1.651、リリース1」という表記です。

そのため、確認結果は次のように異なります。

perl -MDBI -e 'print "$DBI::VERSION\n"'
→ 1.651

rpm -q perl-DBI
→ perl-DBI-1.651-1.azl3.<architecture>

OSの再起動は必要ですか

perl-DBIだけを更新した場合、重要なのはDBIを読み込んでいるプロセスやコンテナの再起動です。OS全体の再起動が常に必要とは限りません。

ただし、同時に実施したシステム全体の更新でカーネルや低レベルライブラリも更新された場合は、組織の再起動判定ルールに従ってください。

WAFで防げますか

CVE-2026-60081はファイルパーサーの問題なので、WAFは基本的な修正手段にはなりません。Webアプリケーションがファイルアップロード機能を通じてプロファイルダンプを受け取る場合、アップロード経路の制限には役立つ可能性がありますが、内部共有フォルダ、CI、バッチ、サポートファイルなどの経路は保護できません。

修正版のMAX_PATH_DEPTHを大きくしてもよいですか

DBI 1.651では、既定の最大パス深度として256が設定され、必要に応じて変更できるようになっています。正当なプロファイルで上限に達する場合は調整できますが、根拠なく極端に大きな値へ変更すると、修正による保護効果を弱めます。

変更前に、正常なプロファイルで実際に必要な最大階層を測定してください。(GitHub)

CVE-2026-60081対応の最終チェック

CVE-2026-60081への対応では、次の状態を確認して完了とします。

Azure Linux 3.0の対象ホストとコンテナを洗い出した
RPM版perl-DBIの導入状況を確認した
Perlが実際に読み込むDBIのバージョンとパスを確認した
DBI::ProfileDataやdbiprofの利用箇所を調査した
信頼できないプロファイルダンプが到達する経路を確認した
perl-DBI 1.651-1以降へ更新した
CPAN版やアプリケーション同梱版も1.651以降へ更新した
関連サービス、ワーカー、コンテナ、Podを再起動した
更新後のRPMと実行時モジュールを再確認した
データベース接続とプロファイル解析の動作確認を行った
OOM、異常終了、大量警告が発生していないことを確認した

最初に行うべき作業は、rpm -q perl-DBIだけではありません。$DBI::VERSIONと$INC{"DBI/ProfileData.pm"}を確認し、実際に動作中のアプリケーションがどのDBIを読み込んでいるかを特定してください。そのうえで1.651-1以降へ更新し、プロセスやコンテナの再起動まで完了させることが、CVE-2026-60081に対する確実な対応です。(GitHub)

この記事を書いた人

佐藤健司

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