Azure SDKのパストラバーサル脆弱性対応でまず確認すべきことは、Azure SDK for Pythonのうち、Azure Machine Learning向けパッケージ azure-ai-ml を使っているか、そしてArtifact ToolのZIP展開処理を含むバージョンやコミットを利用しているかです。
2026年5月5日に公開されたGitHub PRでは、Artifact ToolのZIPアーカイブを展開する前に、ZIP内の各ファイルパスが展開先ディレクトリの外へ出ないかを検証する変更が追加されています。これはZipSlipとも呼ばれるパストラバーサル対策で、悪意あるZIPに含まれる ../ や絶対パスによって、意図しない場所へファイルを書き込まれるリスクを下げるための修正です。(GitHub)
ただし、本件は「Azure SDK全体が同じ影響を受ける」と読むべきではありません。PR上の変更箇所は sdk/ml/azure-ai-ml/azure/ai/ml/_utils/_artifact_utils.py であり、主に azure-ai-ml を使う開発者、MLOps担当者、CI/CD環境の管理者が優先して確認すべき内容です。(GitHub)
Azure SDKのArtifact Tool ZIP展開修正で何が変わったのか
今回の変更は、Artifact ToolのZIPファイルを展開する内部処理に、展開先ディレクトリから外へ出ないことを確認する検証を追加するものです。
PRの内容では、_artifact_utils.py の _redirect_artifacts_tool_path() において、ZIPファイルを extractall() で展開する前に、ZIP内の各メンバーの解決済みパスをチェックするようになっています。展開先の一時ディレクトリを resolve() で正規化し、各ZIPメンバーのパスも同様に解決したうえで、展開先配下に収まらない場合は RuntimeError を発生させる流れです。(GitHub)
| 確認項目 | 変更前の考え方 | 変更後の考え方 |
|---|---|---|
| ZIP展開前のパス検証 | 明示的なメンバー単位の検証なし | 各ZIPメンバーの解決済みパスを確認 |
| 危険なパス | ../ や絶対パスが含まれるZIPで展開先外へ出る可能性 | 展開先外へ出るパスを拒否 |
| 展開先ディレクトリ | 一時ディレクトリを作成して展開 | 一時ディレクトリを Path として扱い、解決済みパスを利用 |
| 異常時の挙動 | 不正なZIPでも展開処理に進む可能性 | パストラバーサルを検出すると例外で停止 |
| 環境変数 | Artifact Toolの上書きパスを設定 | 解決済みの安全な展開先パスを設定 |
PRでは、通常のネストされたディレクトリを含むZIPは展開できる一方、../../、subdir/../../escaped.txt、絶対パスを含むエントリは拒否されることが確認されています。(GitHub)
なぜZipSlip対策が重要なのか
ZipSlipは、ZIPやtarなどのアーカイブ内に ../ のような相対パスを含め、展開処理時に意図したディレクトリの外へファイルを書き込ませる攻撃手法です。MITREのCWE-23では、Zip Slipを「ファイルアーカイブ内のパストラバーサルを利用して、期待された展開先ディレクトリの外にファイルを書き込ませる攻撃」と説明しています。([CWE][3])
パストラバーサルはCWE-22にも分類されます。CWE-22は、制限された親ディレクトリ配下にあるはずのパスが、適切に無害化されないことで外部の場所へ解決されてしまう弱点です。結果として、ファイルの作成、上書き、読み取り、場合によっては不正なコード実行につながる可能性があります。([CWE][4])
今回のケースで重要なのは、単に「ZIPファイルを扱っているから危険」という話ではありません。問題の本質は、信頼境界の外から取得したアーカイブを展開するときに、アーカイブ内のファイル名をそのまま信用してはいけないという点です。
たとえば、次のようなZIPエントリが含まれていた場合、展開先が /tmp/artifact-tool のつもりでも、処理の実装によっては別の場所へ書き込まれる可能性があります。
../../malicious.txt
subdir/../../escaped.txt
/absolute/path/file.txt安全な実装では、これらを「展開先ディレクトリから外へ出るパス」として拒否します。今回のAzure SDK for Pythonの修正も、この考え方に沿ったものです。
影響を受ける可能性が高いユーザー
今回のPRから読み取れる影響範囲は、Azure SDK for Python全体ではなく、azure-ai-ml 配下のArtifact Tool関連処理です。Microsoft Learnでは、azure-ai-ml はAzure Machine Learning Python SDK v2のクライアントライブラリであり、ジョブ、パイプライン、コンポーネント、モデル、データストアなどの管理に使われると説明されています。(Microsoft Learn)
| 対象者・環境 | 対応優先度 | 理由 |
|---|---|---|
azure-ai-ml を使ってAzure Machine Learningのジョブやパイプラインを実行している | 高 | 変更対象のパッケージ配下に該当するため |
| CI/CDでAzure ML SDKを使い、モデル登録・ジョブ投入・アセット操作を自動化している | 高 | 自動実行環境では異常なZIP展開の影響が見えにくい |
| GitHubのAzure SDK for Pythonリポジトリから直接ビルドしている | 高 | PRのマージ状況や取り込みコミットの確認が必要 |
社内で azure-ai-ml をvendoring、fork、カスタムビルドしている | 高 | 公式リリースを待たず、手元のコード差分確認が必要 |
| Azure Storage、Azure Key Vaultなど、ML以外のAzure SDKだけを使っている | 低〜中 | PR上の変更箇所からは直接影響が読み取りにくいが、依存関係確認は有用 |
| Azure PortalだけでAzure Machine Learningを操作している | 低 | SDK内部のArtifact Tool展開処理を直接使っていない可能性が高い |
注意したいのは、azure-ai-ml をアプリケーション本体で使っていなくても、運用スクリプト、GitHub Actions、Azure Pipelines、社内のMLOpsツールで利用しているケースです。特にMLOpsでは、開発者のローカル環境ではなくCI/CD上でSDKが使われることが多いため、requirements.txt、pyproject.toml、poetry.lock、pip freeze の結果を確認してください。
現時点で断定してはいけないこと
本件を調査するときは、セキュリティ対応として重要な情報と、まだ確認できない情報を分けて扱う必要があります。
PRページでは、2026年5月5日時点で「Fix path traversal vulnerability in artifact tool zip extraction」というPRが作成され、1コミットで +14 -4 の変更が加えられていることが確認できます。一方で、PR画面上では Open と表示されており、少なくともPRページの情報だけでは、正式リリース済みのパッケージバージョンやCVE番号までは確認できません。(GitHub)
| 判断してよいこと | まだ断定しないこと |
|---|---|
azure-ai-ml 配下のArtifact Tool ZIP展開処理にパストラバーサル対策が追加された | すべてのAzure SDK利用者が同じ影響を受ける |
../、ネストされたトラバーサル、絶対パスを含むZIPエントリが拒否対象になった | 特定のPyPIバージョンに必ず修正が入っている |
| 異常なZIPでは例外により展開が止まる可能性がある | 既に悪用が確認されている |
| CI/CDやMLOps環境で依存関係の確認が必要 | Azure Portal側の設定変更で解決できる |
セキュリティ記事や社内通知を書く場合も、「修正済みバージョンは○○です」と断定する前に、公式のリリースノート、PyPI、GitHubのマージ状況を確認するべきです。
利用中の環境で確認すべきポイント
まずは、対象パッケージを使っているかを確認します。Python環境で次のコマンドを実行してください。
python -m pip show azure-ai-mlazure-ai-ml が表示されない場合、少なくともそのPython環境では該当パッケージを直接インストールしていません。ただし、CI/CDや別の仮想環境、Dockerイメージ内で使われている可能性があるため、実際にジョブを実行している環境でも確認してください。
インストール済みの場合は、該当モジュールの場所を確認します。
python - <<'PY'
import inspect
from azure.ai.ml._utils import _artifact_utils
print(inspect.getfile(_artifact_utils))
PY次に、手元のコードにZIPメンバー単位の検証が入っているかを簡易確認します。
python - <<'PY'
import inspect
from azure.ai.ml._utils import _artifact_utils
src = inspect.getsource(_artifact_utils)
checks = [
"namelist()" in src,
"resolve()" in src,
"path traversal" in src.lower(),
"extractall" in src,
]
print({
"has_zip_member_iteration": checks[0],
"has_resolved_path_check": checks[1],
"mentions_path_traversal": checks[2],
"uses_extractall": checks[3],
})
PYこの確認はあくまで簡易チェックです。True が出ても完全な安全性を保証するものではありません。最終的には、利用中のパッケージバージョン、公式リリースノート、該当PRのマージ状況、実際のソースコード差分を照合してください。
CI/CD環境での確認手順
MLOpsやAzure Machine Learningの運用環境では、開発者PCよりもCI/CDの確認が重要です。特に、モデルの登録、データアセットの作成、ジョブ送信、パイプライン実行を自動化している環境では、SDKがバックグラウンドでArtifact Toolを扱う可能性があります。
| 手順 | 確認内容 | 具体例 |
|---|---|---|
| 依存関係の棚卸し | azure-ai-ml の有無とバージョン | pip freeze, pip show azure-ai-ml |
| ロックファイル確認 | 古いバージョンに固定されていないか | requirements.txt, poetry.lock, uv.lock |
| Dockerイメージ確認 | ビルド済みイメージ内のSDK状態 | docker run --rm image python -m pip show azure-ai-ml |
| 環境変数確認 | Artifact Toolの上書きパスが設定されていないか | AZURE_DEVOPS_EXT_ARTIFACTTOOL_OVERRIDE_PATH |
| ログ確認 | Artifact Toolダウンロードや展開時の異常 | CIログ、Azure Pipelinesログ、GitHub Actionsログ |
| ソース確認 | _artifact_utils.py に安全な展開処理が入っているか | inspect.getfile() でパスを特定 |
環境変数の確認は次のように行えます。
printenv | grep AZURE_DEVOPS_EXT_ARTIFACTTOOL_OVERRIDE_PATHこの環境変数が明示的に設定されている場合、SDKの標準処理ではなく、特定のArtifact Toolパスを使う構成になっている可能性があります。社内で独自に配置したツールを参照している場合は、その配布元、更新手順、アクセス権、改ざん検知の有無も確認してください。
移行・更新時に注意すべきこと
正式に修正を含むバージョンが利用可能になった場合、基本方針は azure-ai-ml を更新することです。ただし、セキュリティ対応では「上げれば終わり」ではなく、実行環境ごとに反映状況を確認する必要があります。
python -m pip install --upgrade azure-ai-ml更新後は、次の確認を行います。
python -m pip show azure-ai-ml
python -m pip checkpip check では依存関係の不整合を確認できます。Azure SDK系パッケージは複数のAzureライブラリや認証ライブラリと一緒に使われることが多いため、更新によって依存関係の競合が起きていないかを確認してください。
ロックファイルを使っている場合
Poetry、uv、pip-toolsなどで依存関係を固定している場合、単に pip install --upgrade を実行しても、本番やCI/CDには反映されません。ロックファイルを更新し、レビュー対象に含めてください。
# pip-toolsの例
pip-compile --upgrade-package azure-ai-ml
# Poetryの例
poetry update azure-ai-ml
# uvの例
uv lock --upgrade-package azure-ai-ml更新後は、CI/CDで実際に使われる環境と同じ条件でテストします。ローカルだけで確認しても、Dockerイメージやビルドキャッシュに古いパッケージが残ることがあります。
例外発生を「不具合」として握りつぶさない
今回の変更では、危険なZIPエントリを検出した場合に展開を止める挙動になります。つまり、これまで通っていた処理が、更新後に例外で止まる可能性があります。
このとき、例外を単に握りつぶして再実行するのは避けてください。パストラバーサル検出は、セキュリティ上の異常を示すシグナルです。CI/CDログに次の観点で記録を残すと、原因調査がしやすくなります。
- 使用している
azure-ai-mlのバージョン - Artifact Toolを取得したURLや取得元の種類
- 例外発生時のジョブ名、パイプライン名、実行者
- 対象のワークスペース、リソースグループ
- 直前に変更した依存関係、ネットワーク設定、プロキシ設定
自社コードにも同じ観点を入れる
今回のAzure SDKの変更は、SDK利用者だけでなく、社内ツールを作っている開発者にも参考になります。ZIPやtarを展開する処理では、展開先ディレクトリを決めるだけでは不十分です。展開される各ファイルの最終的なパスが、必ず展開先配下に収まるかを確認する必要があります。
PythonでZIPを安全に展開する場合の基本形は次のようになります。
from pathlib import Path
import zipfile
def safe_extract_zip(zip_path: str, dest_dir: str) -> None:
dest = Path(dest_dir).resolve()
with zipfile.ZipFile(zip_path) as zf:
for info in zf.infolist():
target = (dest / info.filename).resolve()
try:
target.relative_to(dest)
except ValueError as exc:
raise ValueError(f"Unsafe zip entry: {info.filename}") from exc
zf.extractall(dest)このコードでは、各エントリの展開先パスを resolve() で正規化し、relative_to() で展開先ディレクトリ配下にあるかを確認しています。実務では、さらに次の対策も検討してください。
| 対策 | 理由 |
|---|---|
| アーカイブ内の総サイズを制限する | ZIP爆弾によるディスク枯渇を防ぐ |
| ファイル数を制限する | 大量ファイルによる処理遅延を防ぐ |
| シンボリックリンクを拒否または厳格に検証する | リンク経由の展開先外アクセスを防ぐ |
| 実行権限付きファイルを制限する | 展開後の不正実行リスクを下げる |
| 展開先を専用の一時ディレクトリに限定する | 既存ファイルの上書きを防ぐ |
| 展開後に必要なファイルだけを移動する | 不要なファイルの混入を防ぐ |
特にCI/CDでは、展開処理がビルド、テスト、デプロイの前段に置かれることがあります。ここで任意ファイルの書き込みが可能になると、設定ファイル、スクリプト、依存パッケージ、認証関連ファイルが改ざんされるリスクがあります。
よくある誤解と判断基準
「Azure SDKを使っているなら全員すぐ対応が必要」は正確ではない
今回のPRで確認できる変更箇所は azure-ai-ml 配下です。Azure Storage、Azure Key Vault、Azure Cosmos DBなど、別のAzure SDKを使っているだけの環境まで同じ影響があるとは断定できません。
ただし、社内プロジェクトでは「アプリケーション本体はStorage SDKだけだが、CI/CDではAzure ML SDKを使っている」という構成もあります。アプリの依存関係だけでなく、運用スクリプトやビルドイメージも確認してください。
「ZIPを扱っていないから関係ない」とは限らない
自分でZIPをアップロードしていなくても、SDK内部でツールの取得や展開が行われる場合があります。今回のPRも、Artifact ToolのZIPアーカイブ展開処理が対象です。extractall() をアプリケーションコードで直接呼んでいないからといって、必ず無関係とは言えません。
「最新版にすれば必ず解決」はリリース確認が必要
PRが作成された段階と、PyPIやCondaに修正済みパッケージが公開される段階は別です。実際に修正済みかどうかは、公式リリースノート、パッケージバージョン、インストール済みコードを照合して判断してください。
「例外が出たから古い挙動に戻す」は危険
更新後にArtifact Toolの展開で例外が出る場合、それは不正または想定外のZIPエントリが検出された可能性があります。業務影響を避けるために古いバージョンへ戻す場合でも、原因が安全に説明できるまで一時対応として扱い、恒久対応にはしないでください。
セキュリティ担当者が確認すべきチェックリスト
本件を社内で扱う場合は、次の順に確認すると抜け漏れを減らせます。
| チェック | 確認内容 | 完了基準 |
|---|---|---|
| 対象環境の特定 | azure-ai-ml を使うローカル、CI/CD、Docker、運用スクリプトを洗い出す | 対象環境一覧がある |
| バージョン確認 | 各環境で pip show azure-ai-ml を実行する | 実行環境ごとのバージョンが分かる |
| コード確認 | _artifact_utils.py にパス検証があるか確認する | ZIPメンバー単位の検証有無が分かる |
| リリース確認 | 公式リリースノートやPRのマージ状況を確認する | 修正済みバージョンを根拠付きで判断できる |
| 更新計画 | ロックファイル、Dockerイメージ、CI/CDキャッシュを更新する | 本番相当環境で反映済み |
| 監視 | 例外、Artifact Tool取得失敗、不審なファイル作成を確認する | ログ確認手順がある |
| 社内展開 | MLOps担当、開発者、基盤チームへ共有する | 対象者が次の作業を理解している |
まず取るべき行動
今回のAzure SDKのパストラバーサル脆弱性対応では、過度に不安を広げるよりも、対象を絞って確認することが重要です。
最初に、azure-ai-ml を使っている環境を洗い出してください。次に、利用中のパッケージバージョンと _artifact_utils.py の実装を確認します。そのうえで、該当PRが正式にマージされ、修正済みリリースが公開されているかを確認し、CI/CDやDockerイメージまで含めて更新します。
特にMLOps環境では、SDKがアプリケーション本体ではなくビルドや運用の裏側で使われていることがあります。requirements.txt だけでなく、パイプライン定義、コンテナイメージ、社内スクリプトまで含めて確認するのが、今回のようなSDK内部修正に対する実務的な対応です。
[3]: https://cwe.mitre.org/data/definitions/23.html “CWE –
CWE-23: Relative Path Traversal (4.20)
"[4]: https://cwe.mitre.org/data/definitions/22.html “CWE –
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (4.20)
"
コメント