MENU

CVE-2026-15392対策：Azure Linux 3.0のPerl DBD::File脆弱性と更新手順

Azure

Azure Linux 3.0でperl-DBI 1.643-5を使用している場合は、MSRCが修正版として示す1.651-1以上へ更新する必要があります。CVE-2026-15392は、Perl DBIのDBD::Fileが、テーブル用ディレクトリ内に置かれたシンボリックリンクの最終的な参照先を十分に検証せず、設定されたディレクトリの外へアクセスできてしまう脆弱性です。MSRCは個別の回避策を掲載していないため、アクセス権の見直しだけで対応を完了せず、パッケージ更新を優先してください。(Microsoft Security Response Center)

ただし、パッケージがインストールされているだけで直ちに攻撃が成立するわけではありません。実際の危険度は、DBD::File系ドライバーを利用しているか、攻撃者や未信頼プロセスがテーブルディレクトリ内にシンボリックリンクを作成できるか、Perlアプリケーションがどの権限で動作しているかによって変わります。本記事では、影響判定からAzure Linux 3.0での更新、コンテナやAKSでの注意点、修正版を適用するまでのリスク低減策まで解説します。

目次

CVE-2026-15392の要点

項目内容
脆弱性DBD::Fileにおけるシンボリックリンク検証不備
対象サービスAzure Linux 3.0／Perl DBI
Azure Linuxの影響パッケージperl-DBI 1.643-5
Azure Linuxの修正版perl-DBI 1.651-1以上
Upstreamの影響範囲DBI 1.650以下
Upstreamの修正版DBI 1.651
攻撃成立の主な条件f_dir内にシンボリックリンクを作成できること
想定される影響f_dir外のファイルをDBIプロセスの権限で読み取り・変更される可能性
MSRCの評価CVSS 3.1：7.7、重要度「High」
ベンダーが示す個別回避策なし
基本対策perl-DBI 1.651-1以上への更新

Azure Linux向けの対象・修正版はMSRC、Upstream DBIの影響バージョン、攻撃条件、影響内容はDBIプロジェクトのアドバイザリで確認できます。(Microsoft Security Response Center)

MSRCはCVSS 3.1で7.7の「High」と評価しています。一方、UpstreamのGitHub Security Advisoryでは画面上の重要度が「Moderate」とされています。これは評価対象や前提条件の捉え方が異なるためと考えられます。運用上はラベルだけで判断せず、未信頼ユーザーがf_dirへ書き込めるか、Perlプロセスが重要ファイルへアクセスできるかを確認することが重要です。(Microsoft Security Response Center)

Perl DBD::Fileのシンボリックリンク検証不備とは

DBIとDBD::Fileの役割

Perl DBIは、Perlアプリケーションからデータベースへアクセスするための共通インターフェースです。実際のデータ形式やデータベースとの接続は、DBDと呼ばれるドライバーが担当します。

DBD::Fileは、ファイルをテーブルとして扱うDBDドライバーの基盤です。DBD::CSVやDBD::DBMなど、ファイルベースのデータをSQL風に操作するドライバーで利用されます。

これらのドライバーでは、テーブルファイルを保存する場所としてf_dir、検索対象となる場所としてf_dir_searchなどを指定できます。本来は、この指定ディレクトリの外にあるファイルへアクセスできないようにする必要があります。

攻撃が成立する流れ

CVE-2026-15392では、テーブルのディレクトリ自体がf_dir内にあるかは検証されても、最終的に開かれるテーブルファイルやDBMの補助ファイルがシンボリックリンクだった場合、その参照先がf_dir外であることを十分に拒否できませんでした。

概念的には、次のような状態です。

f_dir=/srv/myapp/tables

/srv/myapp/tables/customers.db
  └─ シンボリックリンク
       └─ /var/lib/another-app/important.db

攻撃は、主に次の順序で成立します。

  1. アプリケーションが/srv/myapp/tablesをf_dirとして使用する
  2. 攻撃者や未信頼プロセスが、その中にシンボリックリンクを作成する
  3. Perlアプリケーションがリンクをテーブルファイルとして開く
  4. DBD::Fileがリンク先をたどり、f_dir外のファイルへアクセスする
  5. SQL操作の種類に応じて、外部ファイルが読み取られたり変更されたりする

Upstreamの説明では、最終テーブルファイルだけでなく、DBMで使用される.pagや.dirなどの補助ファイルをシンボリックリンクにしたケースも問題になります。SELECTによる読み取りに加え、INSERT、UPDATE、DELETE、CREATE TABLEなどの操作で外部ファイルが変更される可能性があります。(GitHub)

インターネットから直接攻撃される脆弱性とは限らない

この脆弱性だけで、インターネット上の匿名ユーザーが直ちに任意ファイルへアクセスできるわけではありません。原則として、攻撃者にはf_dir内へシンボリックリンクを作成する手段が必要です。

ただし、次のような環境では外部入力から攻撃条件につながる可能性があります。

  • 複数ユーザーや複数コンテナで共有している書き込み可能なボリューム
  • 利用者がファイルを配置できるデータディレクトリ
  • シンボリックリンクを保持したままアーカイブを展開する処理
  • 外部ストレージからファイルを同期する処理
  • CI/CDやバッチ処理が生成物をf_dirへ配置する構成
  • 別サービスと同じUnixグループに書き込み権限を付与している構成

「攻撃元区分がローカルだから重要ではない」と判断するのは危険です。外部入力を起点にシンボリックリンクが配置される仕組みがあれば、ネットワーク経由の攻撃チェーンに組み込まれる可能性があります。

読み取り・変更できる範囲はプロセス権限に依存する

リンク先のファイルへ無条件にアクセスできるわけではありません。実際にアクセスできるのは、Perlアプリケーションの実行ユーザーが読み取りまたは書き込みできる範囲です。

たとえば、専用の非特権ユーザーで動作し、必要なデータディレクトリ以外へアクセスできない構成であれば、影響は限定されます。一方、アプリケーションをrootで動かしていたり、設定ファイル、認証情報、他システムのデータへ広いアクセス権を持たせていたりする場合は、機密性と完全性への影響が大きくなります。

また、実際にどのような内容を読み書きできるかは、利用しているファイル形式やDBDドライバー、実行されるSQL操作にも左右されます。「任意の内容を自由に書き込める」とは限りませんが、対象外であるはずのファイルがDBI処理に巻き込まれる点が問題です。(GitHub)

DBI 1.651では何が修正されたのか

DBI 1.648では、明示的に指定されたフォルダー外のテーブルソースを許可しないための修正が追加されていました。しかし、パスを正規化した後に最終テーブルファイルを開く処理では、シンボリックリンクの参照先がディレクトリ外かどうかを十分に確認できていませんでした。

DBI 1.651では、最終テーブルファイルの実体パスを解決し、f_dirまたはf_dir_searchの外を指している場合に拒否する処理が追加されています。リリースノートにも、CVE-2026-15392への対応として「テーブルがf_dir外へのシンボリックリンクではないことを保証する修正」が明記されています。(GitHub)

この経緯から分かる重要な点は、単にパス中の../を拒否するだけでは不十分だということです。文字列上はf_dir内に見えても、ファイルシステムがシンボリックリンクを解決した結果、別のディレクトリへ到達する場合があります。

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

CVE-2026-15392の影響は、次の4条件で判断すると整理しやすくなります。

確認項目影響が大きくなる状態
DBIのバージョンUpstream DBI 1.650以下、またはAzure Linuxの影響パッケージを使用
機能の利用状況DBD::File、DBD::CSV、DBD::DBMなどを実際に使用
シンボリックリンク作成可否未信頼ユーザーや別プロセスがf_dirへ書き込み可能
Perlプロセスの権限f_dir外の設定、認証情報、他サービスのデータへアクセス可能

優先度の目安は次のとおりです。

環境対応優先度
影響バージョンを使用し、共有書き込み可能なf_dirでDBD::File系を利用最優先で更新
ファイルアップロードや同期処理からf_dirへファイルを配置最優先で更新し、リンク混入経路も調査
DBD::File系を利用しているが、f_dirは専用ユーザーのみ書き込み可能早期に更新
パッケージは存在するが、DBD::File系を利用していない悪用可能性は低いが更新対象
OSパッケージは未導入だが、CPANやアプリ同梱のDBIを使用アプリ側のバージョンを確認
Azure Linuxパッケージと実行時DBIの双方が修正版以上本脆弱性については修正済み

脆弱性スキャナーがperl-DBIの存在だけで検出した場合でも、実行経路を確認する価値はあります。ただし、「現在はDBD::Fileを使っていない」という理由だけでパッチを見送ると、将来の設定変更や別アプリケーションから同じパッケージが利用された際に脆弱な状態が残ります。

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

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

最初に、対象ホストがAzure Linux 3.0であることと、RPMパッケージのバージョンを確認します。

cat /etc/os-release

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

影響パッケージでは、次のような結果が表示されます。

perl-DBI 1.643-5.azl3 x86_64

修正版では、次のように1.651-1.azl3以上になります。

perl-DBI 1.651-1.azl3 x86_64

package perl-DBI is not installedと表示された場合、RPMとしてのperl-DBIはインストールされていません。ただし、CPAN、local::lib、Carton、アプリケーションのvendorディレクトリなどからDBIを読み込んでいる可能性は残ります。MSRCのパッケージ判定だけでなく、実行時モジュールも確認してください。(Microsoft Security Response Center)

Perlが実際に読み込むDBIを確認する

次のコマンドでは、実行時のDBIバージョンと読み込み元を確認できます。

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

perl -MDBD::File -e 'printf "DBD::File.pm: %s\n", $INC{"DBD/File.pm"}'

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

DBI version: 1.643
DBI.pm: /usr/lib/perl5/vendor_perl/DBI.pm
DBD::File.pm: /usr/lib/perl5/vendor_perl/DBD/File.pm

Upstream基準ではDBI 1.650以下が影響を受け、1.651で修正されています。(GitHub)

続いて、読み込まれたDBI.pmがどのRPMに属するかを確認します。

DBI_PM="$(perl -MDBI -e 'print $INC{"DBI.pm"}')"
rpm -qf "$DBI_PM"

perl-DBIが表示されれば、OSパッケージとして管理されています。

一方、次のようなパスの場合は、OSのperl-DBIを更新しても、アプリケーションが古いDBIを読み込み続ける可能性があります。

/home/appuser/perl5/lib/perl5/DBI.pm
/opt/myapp/local/lib/perl5/DBI.pm
/opt/myapp/vendor/lib/DBI.pm

rpm -qfで「どのパッケージにも属していない」と表示された場合は、CPANやアプリケーション側の依存関係として更新します。

DBD::File系ドライバーの利用状況を確認する

ソースコード、設定ファイル、デプロイ定義から、ファイルベースのDBDドライバーを検索します。

grep -RInE 'dbi:(CSV|DBM)|DBD::File|f_dir(_search)?' \
  /opt/myapp /etc/myapp 2>/dev/null

インストール済みドライバーの参考情報は、次のコマンドでも確認できます。

perl -MDBI -e 'print "$_\n" for DBI->available_drivers'

ただし、ドライバーが一覧に表示されることは、実際にそのアプリケーションから利用されている証拠ではありません。環境変数、設定管理システム、KubernetesのConfigMapやSecret、実行時に組み立てられるDSNも確認してください。

特に、次のようなDSNや属性がないかを調査します。

dbi:CSV:
dbi:DBM:
f_dir
f_dir_search

テーブルディレクトリ内のシンボリックリンクを確認する

実際のf_dirが分かったら、シンボリックリンクを列挙します。

F_DIR=/srv/myapp/tables

find "$F_DIR" -type l -ls

ディレクトリ自体の所有者と権限も確認します。

stat -c '%A %U:%G %n' "$F_DIR"

ACLを利用している環境では、通常の所有者・グループ権限だけでなく、getfaclの結果も確認します。

getfacl -p "$F_DIR"

シンボリックリンクが見つかっても、すぐに一括削除しないでください。正規の運用で利用している可能性があるほか、侵害の痕跡である場合は調査に必要です。少なくとも、リンク元、実体の参照先、所有者、作成・変更時刻、関連するアプリケーションログを記録してから判断します。

perl-DBI 1.651-1への更新手順

Azure Linux 3.0のVMやサーバーを更新する

Azure Linux 3.0では、パッケージ管理にtdnfを使用します。Azure Linux 4.0ではDNF5へ変更されていますが、3.0向けの手順ではtdnfを基準にします。(Microsoft Learn)

リポジトリのメタデータを更新し、perl-DBIを更新します。

sudo tdnf makecache
sudo tdnf update perl-DBI

更新後にRPMパッケージを確認します。

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

期待する結果は、次のいずれかです。

perl-DBI 1.651-1.azl3 x86_64

または、これより新しいバージョンです。

有効なリポジトリや社内ミラーに修正版が存在するかは、次のコマンドでも確認できます。

tdnf list perl-DBI

修正版が表示されない場合は、次の点を確認します。

  • Azure Linuxの公式リポジトリが有効になっているか
  • 社内ミラーの同期が完了しているか
  • 更新対象のアーキテクチャが正しいか
  • リポジトリの優先順位やバージョン固定が影響していないか
  • 古いスナップショットリポジトリを参照していないか

修正版が取得できない状態で、出所不明のRPMを手動導入したり、rpm --nodepsで依存関係を無視したりするのは避けてください。公式リポジトリまたは組織が管理する検証済みリポジトリから適用します。

実行中のPerlプロセスを再起動する

RPMを更新しても、長時間動作しているPerlプロセスは、メモリ上に読み込んだ古いDBIコードを使い続けます。

systemdサービスの場合は、サービスを再起動します。

SERVICE=my-perl-app.service

sudo systemctl restart "$SERVICE"
sudo systemctl is-active "$SERVICE"
sudo systemctl status "$SERVICE" --no-pager

Apacheのmod_perl、Plack、FastCGI、常駐ワーカー、ジョブ管理デーモンなどを使用している場合は、それぞれの親プロセスまたはワーカーを再起動します。

DBIはユーザー空間のライブラリであるため、このパッケージだけの更新でOS再起動が必須になるケースは通常ありません。ただし、同じ更新トランザクションでカーネルや再起動を必要とするライブラリも更新した場合は、組織のパッチ運用に従って再起動してください。

実行時のDBIバージョンを再確認する

再起動後、アプリケーションと同じユーザー、同じ環境変数で確認します。

sudo -u appuser perl -MDBI -e \
  'printf "DBI version: %s\nDBI.pm: %s\n", $DBI::VERSION, $INC{"DBI.pm"}'

appuserは実際のサービス実行ユーザーへ置き換えます。

確認すべき結果は次のとおりです。

DBI version: 1.651

バージョンが古いままの場合は、PERL5LIB、local::lib、perlbrew、plenv、Cartonの実行環境などがOSパッケージより先に読み込まれていないかを確認します。

sudo -u appuser env | grep -E '^PERL5LIB='

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

コンテナイメージでの対応

Azure Linux 3.0のコンテナでは、稼働中コンテナへ直接パッケージを追加するのではなく、Dockerfileを修正してイメージを再ビルドします。Microsoft Artifact Registryでは、Azure Linux 3.0のベースイメージとしてmcr.microsoft.com/azurelinux/base/core:3.0が提供されています。(Microsoft Artifact Registry)

RPMでDBIを管理するDockerfileの例は次のとおりです。

FROM mcr.microsoft.com/azurelinux/base/core:3.0

RUN tdnf update -y \
    && tdnf install -y perl-DBI \
    && tdnf clean all

COPY . /opt/myapp
WORKDIR /opt/myapp

キャッシュされた古いベースイメージやRPMレイヤーを使わないように、ベースイメージを再取得してビルドします。

docker build --pull --no-cache \
  -t myapp:dbi-1.651 .

完成したイメージを検査します。

docker run --rm --entrypoint rpm \
  myapp:dbi-1.651 -q perl-DBI

docker run --rm --entrypoint perl \
  myapp:dbi-1.651 -MDBI -e 'print "$DBI::VERSION\n"'

アプリケーションがCPAN経由でDBIを導入している場合、RPMの更新だけでは不十分です。cpanfileなどでDBI 1.651以上を要求し、ロックファイルを更新してから再ビルドします。

requires 'DBI', '1.651';

CartonやCarmelなどを使用している場合は、組織で定めた依存関係更新手順に従い、cpanfile.snapshotなども更新します。

対応後は、イメージをレジストリへ登録するだけでは完了しません。Deployment、Container Apps、VM上のコンテナなどを更新し、実際に新しいイメージダイジェストへ置き換わったことを確認してください。

AKS上のAzure Linux 3.0での対応

AKSで検出された場合は、脆弱なパッケージが次のどちらに存在するかを切り分けます。

  • AKSノードのOSイメージ内
  • Podで実行しているアプリケーションコンテナ内

ノードOS側に存在する場合は、利用可能なノードイメージを確認します。

az aks nodepool get-upgrades \
  --nodepool-name "$AKS_NODEPOOL" \
  --cluster-name "$AKS_CLUSTER" \
  --resource-group "$AKS_RESOURCE_GROUP"

特定のノードプールをOSイメージのみ更新する場合は、次のコマンドを使用します。

az aks nodepool upgrade \
  --resource-group "$AKS_RESOURCE_GROUP" \
  --cluster-name "$AKS_CLUSTER" \
  --name "$AKS_NODEPOOL" \
  --node-image-only

AKSではLinuxノードイメージが定期的に更新されますが、リージョンごとに利用可能になる時期が異なる場合があります。実際に利用可能なlatestNodeImageVersionを確認してから更新します。(Microsoft Learn)

重要なのは、ノードイメージを更新しても、Pod内の古いコンテナイメージに含まれるDBIは更新されないことです。脆弱性がアプリケーションコンテナ内で検出された場合は、前述の手順でコンテナを再ビルドし、DeploymentやStatefulSetを更新する必要があります。

稼働中Podが使用しているイメージとダイジェストは、次のように確認できます。

kubectl get pods -A \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,IMAGE:.spec.containers[*].image,IMAGEID:.status.containerStatuses[*].imageID'

タグ名だけでなく、IMAGEIDに表示される実際のダイジェストまで確認すると、古いイメージのPodが残っている状態を見逃しにくくなります。

修正版を適用するまでの一時的なリスク低減策

MSRCはCVE-2026-15392に対する個別の回避策を掲載していません。以下はパッチの代替ではなく、修正版を適用するまで攻撃成立条件を減らすための一時的な対策です。(Microsoft Security Response Center)

対策実施内容限界
f_dirを専用化アップロード、同期、共有作業用ディレクトリと分離する既存リンクの除去にはならない
書き込み権限を限定アプリの専用ユーザー以外から書き込めないようにするアプリ自身がリンクを作れる経路には効かない
シンボリックリンクを検査find -type lなどで定期的に確認する検査後に再作成される可能性がある
アーカイブ展開を制限リンクを含むアーカイブや同期データを直接f_dirへ展開しない展開ツールごとの設定確認が必要
最小権限で実行Perlサービスから不要な設定・秘密情報・他サービスのデータへアクセスさせない検証不備そのものは残る
読み取り専用化書き込み不要なテーブル領域を読み取り専用にする更新処理が必要なアプリには適用できない
不要なドライバーを無効化DBD::CSVやDBD::DBMを利用していなければ読み込み経路を削減するDBIパッケージ自体の更新は別途必要
コンテナの権限を制限非root実行、読み取り専用ルートFS、必要最小限のボリュームマウントにする書き込み可能ボリューム内の問題は残る

標準的なUnixパーミッションでは、「通常ファイルは作成できるがシンボリックリンクだけは禁止する」といった細かな制御は簡単ではありません。ディレクトリへ書き込める主体そのものを限定することが基本です。

不審なシンボリックリンクが見つかった場合の対応

f_dir内に意図しないシンボリックリンクがあった場合は、単なる設定ミスとは限りません。次の情報を残してから、隔離または削除を判断します。

LINK=/srv/myapp/tables/suspicious-file

ls -ld "$LINK"
stat "$LINK"
readlink "$LINK"
readlink -f "$LINK"

調査では、次の点を確認します。

  • リンクの所有者とグループ
  • リンクが指していた実体ファイル
  • 実体ファイルの更新時刻と内容
  • アプリケーションがリンクを参照した記録
  • SELECT、INSERT、UPDATE、DELETEなどの実行履歴
  • リンク作成時刻付近のログイン、ファイル転送、バッチ、コンテナイベント
  • リンク先に認証情報、秘密鍵、トークン、設定ファイルが含まれていなかったか

認証情報が読み取られた可能性を否定できない場合は、パスワードやトークンのローテーションも検討します。外部ファイルが変更された可能性がある場合は、正常なバックアップや構成管理データと比較し、完全性を確認してください。

更新後に確認すべき項目

更新作業は、パッケージをインストールした時点では完了しません。次の状態まで確認します。

  • perl-DBIが1.651-1.azl3以上になっている
  • 実行時の$DBI::VERSIONが1.651以上になっている
  • DBI.pmの読み込み元が想定したパスになっている
  • RPM管理の場合、rpm -qfでperl-DBIの所有ファイルと確認できる
  • 常駐するPerlプロセスを再起動している
  • コンテナの場合、新しいイメージダイジェストへ置き換わっている
  • f_dir内に意図しないシンボリックリンクがない
  • f_dirへ書き込めるユーザーやプロセスが限定されている
  • DBD::CSVやDBD::DBMの読み取り・更新処理が正常に動く
  • 脆弱性スキャンを再実行し、検出が解消している

DBI 1.651にはCVE-2026-15392以外の修正も含まれます。特にファイルベースのテーブルを使用しているアプリケーションでは、読み取りだけでなく、テーブル作成、追加、更新、削除、複数ディレクトリ検索を含む回帰テストを実施してください。(MetaCPAN)

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

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

OSのperl-DBIを更新しても、PERL5LIBやアプリケーションのvendorディレクトリに古いDBIがあれば、そちらが優先されます。

パッケージバージョンと、次の実行結果を必ずセットで確認します。

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

CPANでシステム領域へ上書きしてしまう

早く修正しようとして、OS管理下のPerlへ直接cpan DBIやcpanm DBIを実行すると、RPMデータベースと実ファイルの状態が一致しなくなる可能性があります。

OSパッケージで管理している環境はtdnfで更新し、CPAN管理のアプリケーションはcpanfileやロックファイルを更新するなど、管理方式を混在させないことが重要です。

シンボリックリンクを削除しただけで完了とする

既存リンクを削除しても、脆弱なDBD::Fileが残っていれば再びリンクを作成される可能性があります。リンク削除は調査・封じ込めであり、恒久対策はDBIの更新です。

AKSノードだけを更新する

脆弱なDBIがアプリケーションコンテナに含まれている場合、AKSノードイメージの更新だけでは解消しません。スキャン結果が示すファイルパスやイメージ名を確認し、ノードとコンテナを分けて対応します。

イメージを再ビルドしただけで再デプロイしない

新しいコンテナイメージがレジストリに存在しても、Podやサービスが古いダイジェストを実行していれば脆弱なままです。ロールアウトの完了と、実際のimageIDを確認します。

パッケージ更新後にプロセスを再起動しない

常駐型のPerlプロセスは、更新前のモジュールをメモリ上に保持します。RPM更新後は、該当サービス、ワーカー、Webサーバー、Podを再起動または置き換えます。

CVE-2026-15392対応のまとめ

CVE-2026-15392では、Perl DBIのDBD::Fileが最終テーブルファイルやDBMの補助ファイルに設定されたシンボリックリンクをたどり、f_dir外へアクセスする可能性があります。攻撃にはf_dir内へリンクを作成できることが必要ですが、共有ボリューム、アップロード、アーカイブ展開、同期処理がある環境では優先的な確認が必要です。(GitHub)

対応は、次の順序で進めます。

  1. Azure Linux 3.0上のperl-DBIバージョンを確認する
  2. Perlが実際に読み込んでいるDBIのバージョンとパスを確認する
  3. DBD::File、DBD::CSV、DBD::DBMの利用状況を調査する
  4. f_dir内のシンボリックリンクと書き込み権限を確認する
  5. perl-DBI 1.651-1以上へ更新する
  6. 常駐プロセス、コンテナ、Podを再起動または再デプロイする
  7. 実行時バージョン、リンク、アプリ動作、スキャン結果を再確認する

MSRCが個別の回避策を示していない以上、権限制限やリンク検査は一時的なリスク低減策です。最終的には、Azure Linuxの修正版perl-DBI 1.651-1以上、またはUpstream DBI 1.651以上が実際のアプリケーションから読み込まれている状態を確認してください。(Microsoft Security Response Center)

Azure
Azure Linux Perl DBI CVE-2026-15392 DBD::File

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次