MENU

CVE-2026-16493対策：Azure Linux 3.0のAnsible Galaxy脆弱性と修正版の確認方法

Linux

Azure Linux 3.0でCVE-2026-16493に対応する場合は、まずAnsibleを実行しているコントロールノードやCI/CDランナーを特定し、Gitからコレクションをインストールする処理を一時的に止めてください。脆弱なansible-galaxy collection installが細工されたGit URIを処理すると、URIの一部がgit cloneのオプションとして解釈され、Ansibleを実行したユーザーの権限で任意のコマンドが実行される可能性があります。CVSS 3.1は7.8の「High」、脆弱性分類はCWE-88です。(NVD)

修正版の判定には注意が必要です。MSRCでazl3 ansible 2.17.11-1 on Azure Linux 3.0という文字列が表示されても、これをそのまま「2.17.11-1以上なら修正済み」と解釈してはいけません。Azure Linuxの公式リポジトリでは、2.17.11-1は2025年7月8日、2.17.11-2は2026年6月13日に公開されています。しかし、2.17.11-2の変更履歴で明示されているのは、先行するCVE-2026-11332の修正です。一方、CVE-2026-16493は2026年7月21日時点のstable-2.17にも存在すると報告されています。実務では、MSRCまたはAzure Linuxのパッケージ変更履歴で、CVE-2026-16493への対応が明示されたRPMを導入した時点で修正完了と判断してください。(Microsoft Security Response Center)

目次

CVE-2026-16493の要点

CVE-2026-16493は、Ansible GalaxyがGitリポジトリからコレクションを取得するときに発生するGit引数インジェクションの脆弱性です。

項目内容
CVE番号CVE-2026-16493
対象Microsoft Azure Linux 3.0のansibleパッケージ
影響する機能GitからのAnsible Collectionインストール
主なコマンドansible-galaxy collection install
脆弱性の種類Git引数インジェクション
CWECWE-88
CVSS 3.17.8、High
CVSSベクターCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
想定される影響Ansible実行ユーザー権限での任意コマンド実行
攻撃成立の条件悪意あるGit URIをユーザーまたは自動処理がインストールする
関連する脆弱性CVE-2026-11332の不完全な修正
暫定対策信頼できないGitソースからのCollection導入を停止する
恒久対策CVE-2026-16493の修正が明示されたRPMへ更新する

この脆弱性は、インターネットに公開されたAzure Linuxサーバーが、外部からの通信だけで直ちに侵害されるタイプではありません。悪意あるURIを含むインストール処理を、ユーザーやCI/CDパイプラインが実行する必要があります。

ただし、CI/CDでは依存Collectionのインストールが自動実行されることがあります。そのため、CVSSベクターにユーザー操作を示すUI:Rが含まれていても、必ずしも人が手動でコマンドを入力する必要はありません。外部から変更可能なrequirements.ymlをパイプラインが自動処理する構成では、実質的に無人で脆弱な処理が実行される可能性があります。(NVD)

Git引数インジェクションが発生する仕組み

Ansibleは、GitリポジトリからCollectionをインストールするとき、内部でgit cloneを実行します。

安全にコマンドを組み立てる場合は、次のように--を置き、これより後ろをオプションではなく位置引数として扱わせます。

git clone -- <リポジトリURI> <保存先>

CVE-2026-16493では、Collectionを取得する処理の一部で、この--が不足していました。

その結果、リポジトリURIとして渡された文字列が特定の記号から始まっていると、Gitが単なるURIではなくコマンドラインオプションとして解釈する可能性があります。Gitには動作やSSHコマンドを変更するための設定オプションがあるため、細工された値を受け入れると任意コマンド実行につながります。

攻撃の流れは次のとおりです。

  1. 攻撃者が、細工したGit URIをCollectionの取得元として指定します。
  2. URIがrequirements.yml、CI設定、インストールスクリプトなどに取り込まれます。
  3. 管理者またはパイプラインがansible-galaxy collection installを実行します。
  4. URIの一部がgit cloneのオプションとして処理されます。
  5. Ansibleを実行したユーザーの権限で、攻撃者が指定したコマンドが動作します。

実行ユーザーがrootであれば、ホスト全体への影響が想定されます。一般ユーザーであっても、そのアカウントが読み取れるSSH秘密鍵、Azureの認証情報、CI/CD変数、Vaultトークン、インベントリ内の接続情報などが危険にさらされます。(NVD)

CVE-2026-11332との違い

CVE-2026-16493は、CVE-2026-11332に対する修正が不完全だったことによって残った脆弱性です。

CVE-2026-11332では、Ansible RoleをGitからインストールする経路に--を追加する修正が行われました。しかし、Ansible Collectionをインストールする別の処理経路には、同じ保護が適用されていませんでした。(NVD)

操作関連する脆弱性状況
GitからRoleをインストールCVE-2026-11332Role側の処理に--を追加
GitからCollectionをインストールCVE-2026-16493Collection側の同等処理が未修正だった
通常のPlaybook実行直接の対象ではない依存Collectionを同時に取得する場合は要確認
CI/CD開始時のCollection導入CVE-2026-16493の優先調査対象自動処理でも攻撃が成立する可能性がある

Azure Linuxのansible-2.17.11-2に追加されたパッチは、Roleのインストール処理を変更するCVE-2026-11332向けです。パッチ内容でも、lib/ansible/utils/galaxy.pyのRole側処理に--を追加していることが確認できます。Collection側のconcrete_artifact_manager.pyを対象とするCVE-2026-16493とは、修正箇所が異なります。(GitHub)

MSRCの2.17.11-1表記を修正版と断定してはいけない理由

重要: azl3 ansible 2.17.11-1 on Azure Linux 3.0という文字列だけを根拠に、「2.17.11-1以上は修正済み」という脆弱性判定ルールを作成しないでください。

2026年8月2日時点の公開情報を時系列で並べると、次のようになります。

日付公開内容
2025年7月8日ansible-2.17.11-1.azl3.noarch.rpmが公開
2026年6月13日ansible-2.17.11-2.azl3.noarch.rpmが公開
2026年7月21日CVE-2026-16493がNVDに公開
2026年7月21日時点stable-2.17を含む有効な上流ブランチで脆弱性が確認された

さらに、Azure Linuxの公開変更履歴では、次の内容が明示されています。

  • 2.17.11-1はCVE-2024-8775とCVE-2024-9902への対応を含む更新
  • 2.17.11-2はCVE-2026-11332への対応を含む更新
  • 公開されている2.17.11-2の変更履歴には、CVE-2026-16493の記載がない

したがって、少なくともバージョン番号だけを比較して2.17.11-1や2.17.11-2をCVE-2026-16493の修正版と判定することはできません。(Microsoft Packages)

インストール結果は次の基準で判断します。

確認結果判断
ansible-2.17.11-1.azl3CVE-2026-16493の修正版とは判断しない
ansible-2.17.11-2.azl3CVE-2026-11332の修正は確認できるが、CVE-2026-16493の修正証拠にはならない
より新しいRPMバージョン番号だけではなく、MSRCや変更履歴でCVE-2026-16493との対応を確認する
RPM管理外のAnsiblepip、venv、pipx、コンテナ内のansible-coreを個別に調査する
修正CVEが明記されたRPM実際に使用している実行ファイルもそのRPMに切り替わったことを確認する

脆弱性管理ツールへ登録する修正条件も、単純な「バージョンが2.17.11-1以上」ではなく、MicrosoftがCVE-2026-16493との対応を明示したRPMのEpoch、Version、Releaseを基準にしてください。

優先して調査する環境

Ansibleは、管理対象サーバーよりもコントロールノード側で動作します。そのため、管理対象ホストを無差別に調査するより、ansible-galaxyを実行する環境を先に調べる必要があります。

優先度調査対象理由
最優先CI/CDランナー外部のPull Requestや依存ファイルを自動処理する可能性がある
最優先AnsibleコントロールノードSSH鍵や管理対象システムへの認証情報を保持しやすい
高コンテナ形式のExecution Environmentホストを更新してもコンテナ内のAnsibleは更新されない
高VMイメージやコンテナイメージのビルダービルド時にGitからCollectionを取得する構成が多い
中管理者の作業端末手動で外部Collectionを導入している可能性がある
低Ansibleが入っていない管理対象ノードコントロールノードから操作されるだけなら直接の対象ではない

次のようなファイルやサービスも確認します。

  • requirements.ymlおよびrequirements.yaml
  • azure-pipelines.yml
  • .github/workflows配下のワークフロー
  • .gitlab-ci.yml
  • Jenkinsfile
  • Dockerfileおよびコンテナビルドスクリプト
  • cron、systemd timer、定期実行シェル
  • AWXやAutomation ControllerのExecution Environment
  • ゴールデンイメージ作成処理

Azure Linux 3.0でAnsibleのバージョンを確認する方法

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

最初に、対象ホストがAzure Linux 3.0であることを確認します。

grep -E '^(NAME|ID|VERSION_ID)=' /etc/os-release

続いて、Azure LinuxのRPMとしてインストールされているAnsibleの完全なバージョンを確認します。

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

出力例は次の形式です。

ansible-2.17.11-2.azl3.noarch

ここでは2.17.11だけでなく、Azure Linux側のリリース番号である-1.azl3や-2.azl3まで記録してください。

実際に実行されるAnsibleを確認する

RPMを更新しても、PATHの優先順位によってpipや仮想環境のAnsibleが実行されることがあります。

command -v ansible
command -v ansible-galaxy

readlink -f "$(command -v ansible)"
readlink -f "$(command -v ansible-galaxy)"

ansible --version
ansible-galaxy --version

ansible --versionに表示されるのは、関連付けられているansible-coreのバージョンです。ただし、Azure Linux独自のRPMリリース番号まで表示されるとは限りません。そのため、ansible --versionとrpm -q ansibleの両方が必要です。(Ansible документация)

実行ファイルがどのRPMに属するかも確認します。

ANSIBLE_BIN="$(command -v ansible || true)"

if [ -n "$ANSIBLE_BIN" ]; then
  rpm -qf "$(readlink -f "$ANSIBLE_BIN")" 2>/dev/null \
    || echo "RPM管理外のAnsibleです。pip、venv、pipx、コンテナを確認してください。"
fi

pipや仮想環境も確認する

RPMが更新済みでも、次の経路で古いansible-coreが残ることがあります。

python3 -m pip show ansible-core ansible 2>/dev/null
pipx list 2>/dev/null

仮想環境を使用している場合は、その環境を有効化してから確認します。

source /opt/ansible-venv/bin/activate

command -v ansible
ansible --version
python -m pip show ansible-core ansible

コンテナでAnsibleを実行している場合は、ホストではなく実際のコンテナ内で同じコマンドを実行してください。ホストOSのtdnf upgradeでは、既に作成されたコンテナイメージのレイヤーは更新されません。

GitからCollectionを取得している箇所を探す

Ansibleは、コマンドラインだけでなくrequirements.ymlからもGitリポジトリのCollectionをインストールできます。type: git、git+https、SSH形式のURIなどが調査対象です。(Ansible документация)

まず、ansible-galaxy collection installの実行箇所を検索します。

grep -RInE --exclude-dir=.git \
  'ansible-galaxy[[:space:]]+collection[[:space:]]+install' \
  /etc /opt /srv /var/lib 2>/dev/null

次に、依存関係ファイルを探します。

find /etc /opt /srv /var/lib -type f \
  \( -name 'requirements.yml' -o -name 'requirements.yaml' \) \
  -print 2>/dev/null

Git形式のCollection定義を検索します。

grep -RInE \
  --include='*.yml' \
  --include='*.yaml' \
  '(git\+https?://|git@|type:[[:space:]]*git)' \
  /etc /opt /srv /var/lib 2>/dev/null

大規模なサーバーでは、最初からファイルシステム全体を検索すると負荷が高くなります。Ansibleプロジェクト、CI作業ディレクトリ、コンテナビルド用リポジトリなど、可能性の高い場所から順番に調べてください。

次の条件に該当する処理は優先的に停止または修正します。

  • 外部ユーザーが変更できるrequirements.ymlを自動処理している
  • Pull Requestの内容を検証前にCIランナーが実行している
  • Collectionの取得元を環境変数やジョブ入力から受け取っている
  • ブランチ名やGit URIを外部パラメーターで指定できる
  • 本番用認証情報を持つランナーで依存Collectionをインストールしている
  • 毎回最新ブランチからCollectionを取得している

修正版が公開された後の更新手順

更新前の状態を記録する

ロールバックや監査証跡のため、更新前のバージョンとCollection一覧を保存します。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' ansible
ansible --version
ansible-galaxy --version

ansible-galaxy collection list \
  > /var/tmp/ansible-collections-before.txt

CI/CDやコンテナ環境では、使用中のイメージダイジェスト、DockerfileのコミットID、パイプライン実行番号も記録しておくと、後から影響範囲を追跡しやすくなります。

リポジトリで提供されている版を確認する

Azure Linuxでは、パッケージ管理にTiny DNFのtdnfを使用します。(Microsoft Learn)

sudo tdnf clean all
sudo tdnf makecache
tdnf info ansible

ここで表示された最新版が、次の条件を満たすか確認します。

  1. 現在のRPMより新しい。
  2. MSRCまたはAzure Linuxの変更履歴でCVE-2026-16493への対応が明示されている。
  3. 使用中のAzure Linux 3.0リポジトリ向けに提供されている。
  4. 組織内ミラーへ同期済みである。
  5. 実際に使用するアーキテクチャと環境に対応している。

単にtdnf info ansibleで新しい数字が表示されたという理由だけで、CVE-2026-16493の修正版とは判断しないでください。

Ansibleパッケージを更新する

修正対象RPMを確認できたら、Ansibleを更新します。

sudo tdnf upgrade ansible

組織内リポジトリを使用している場合は、先にミラーの同期日時と対象RPMの有無を確認します。Microsoft側で公開済みでも、社内ミラーの同期が遅れていると旧版のままになることがあります。

更新後に実行ファイルまで確認する

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

command -v ansible
command -v ansible-galaxy

ansible --version
ansible-galaxy --version

RPMの変更履歴も確認できます。

rpm -q --changelog ansible \
  | grep -A3 -B3 'CVE-2026-16493'

CVE番号が表示されない場合、それだけで未修正と断定はできません。しかし、少なくとも修正済みの証拠としては不十分です。MSRC、Azure Linuxのspecファイル、パッケージ変更履歴を合わせて確認してください。

PlaybookとCollectionをテストする

更新後は、構文確認とステージング環境でのテストを行います。

ansible-playbook --syntax-check site.yml

Check modeに対応するPlaybookであれば、次のように実行します。

ansible-playbook --check -i inventory site.yml

承認済みのrequirements.ymlについても、秘密情報を持たない検証環境でインストールテストを行ってください。

ansible-galaxy collection install -r requirements.yml

Galaxyサーバーから導入したCollectionは、条件を満たす場合、ansible-galaxy collection verifyでインストール内容を確認できます。(Ansible документация)

ansible-galaxy collection verify namespace.collection

コンテナやCI/CDでは再ビルドが必要

Ansibleをコンテナ内で実行している場合、Azure LinuxホストのRPMを更新するだけでは不十分です。

次の処理が必要です。

  1. 修正版を取得できる状態でコンテナイメージを再ビルドします。
  2. キャッシュによって旧RPMや旧Pythonパッケージが再利用されていないか確認します。
  3. 新しいイメージダイジェストをCI/CD設定へ反映します。
  4. 既存のランナーやPodを新しいイメージで作り直します。
  5. コンテナ内でansible --versionとRPM情報を再確認します。
  6. 古いイメージの利用を禁止または削除します。

Dockerfileでtdnf upgrade ansibleを実行していても、古いビルドキャッシュが使われれば更新されない場合があります。セキュリティ修正時は、キャッシュを無効にした再ビルドも検討してください。

また、タグだけでlatestやstableを指定すると、どのイメージを検証したか分からなくなります。修正確認時はイメージダイジェストも証跡として保存します。

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

修正版を確認できない、または保守日程の都合ですぐ更新できない場合は、次の対策を組み合わせます。

Gitからの直接インストールを止める

最も効果的な暫定対策は、Git URIを指定したCollectionインストールを停止することです。

collections:
  - name: https://example.invalid/organization/collection.git
    type: git

上記のような指定を一時的に使わず、組織が管理するGalaxyサーバーや、事前に検証したCollectionアーカイブへ切り替えます。

Gitから直接インストールする機能は、GalaxyやAutomation Hubに未公開のCollectionを利用するための簡易的な方法として提供されています。恒常的な本番配布では、承認済みアーティファクトを内部リポジトリから取得する構成の方が管理しやすくなります。(Ansible документация)

Collection取得元を許可リスト化する

CI/CDで使用可能なCollection取得元を、組織管理下のリポジトリに限定します。

ただし、単純な文字列検索やURLの先頭一致だけでは、引数インジェクション対策として不十分な場合があります。URIを外部入力から直接組み立てないこと、requirements.ymlの変更をコードレビュー対象にすることが重要です。

コミットIDを固定する

ブランチ名ではなく、レビュー済みのコミットIDを指定すると、取得するコードの意図しない変更を抑制できます。

collections:
  - name: git+https://example.invalid/organization/collection.git
    type: git
    version: 0123456789abcdef0123456789abcdef01234567

ただし、コミット固定はサプライチェーン管理の改善策であり、CVE-2026-16493そのものを修正するものではありません。URI自体を攻撃者が変更できる場合、コミットを固定しても引数インジェクションの危険は残ります。

依存導入用ランナーから秘密情報を外す

Collectionを取得する処理を、本番用SSH鍵やクラウド認証情報を持たない一時的な低権限環境へ分離します。

具体的には、次の情報を依存導入ジョブへ渡さないようにします。

  • 本番サーバーへ接続できるSSH秘密鍵
  • Azureサービスプリンシパルの資格情報
  • 長期間有効なアクセストークン
  • Vaultやシークレット管理サービスのトークン
  • 本番用インベントリと暗号化解除キー
  • コンテナレジストリの管理者資格情報

Collectionを検証した後に、署名済みまたはハッシュ確認済みのアーティファクトとして本番工程へ渡す構成が有効です。

既に不審なGit URIを処理した場合の対応

悪意ある可能性があるGit URIを、脆弱なAnsibleで処理した形跡がある場合は、パッケージ更新だけで対応を終了してはいけません。任意コマンドが実行された可能性を前提に、インシデントとして調査します。

  1. 対象のコントロールノードまたはCIランナーをネットワークから分離します。
  2. パイプラインログ、シェル履歴、Ansibleログ、requirements.ymlを保全します。
  3. 実行時に使用されたGit URI、ブランチ、タグ、コミットIDを確定します。
  4. 不審なプロセス、ファイル変更、外部通信、永続化設定を調査します。
  5. 実行アカウントが利用できたSSH鍵やトークンを失効させます。
  6. Azure、Git、コンテナレジストリ、Vault、CI/CDの資格情報を再発行します。
  7. 信頼できるイメージからランナーまたはVMを再構築します。
  8. 修正版と承認済み依存ファイルを使って処理を再実行します。

Collectionを削除しただけでは、既に実行されたコマンドや作成されたバックドアを取り除けません。特に一時的なCIランナーでない場合は、手作業での修復より再構築を優先します。

よくある誤判定と失敗例

誤った対応問題点正しい対応
管理対象ノードだけを更新する脆弱な処理は主にコントロールノードで実行されるansible-galaxyを実行するホストやランナーを調査する
ansible --versionだけを見るAzure LinuxのRPMリリース番号が分からないrpm -q ansibleと実行ファイルのパスも確認する
2.17.11-1以上なら安全と判定するMSRCの製品名と修正閾値を混同している可能性があるCVE修正が明示されたRPMを基準にする
2.17.11-2なので対応済みとする公開変更履歴で明示されているのはCVE-2026-11332CVE-2026-16493との対応を別途確認する
ホストのRPM更新だけで終了するvenv、pipx、コンテナに旧版が残る実際に呼び出されるバイナリを確認する
HTTPSのGit URIだから安全と考える通信暗号化と引数インジェクションは別問題URIの管理主体と入力経路を確認する
コミットを固定したので修正不要と考えるURI自体が改変可能なら攻撃経路が残る修正版導入と入力制限を併用する
Playbookが正常終了したので安全とする正常動作は脆弱性修正の証明にならないRPM、変更履歴、実行環境を証跡として残す

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

通常のPlaybook実行だけでも影響を受けますか

通常のansible-playbook実行だけで、直ちにこの脆弱性が発生するわけではありません。

ただし、Playbook実行前の処理としてansible-galaxy collection installを呼び出している場合や、CI/CDジョブが毎回依存Collectionを取得する場合は影響を受けます。

Ansible Galaxy公式サーバーからの導入も危険ですか

CVE-2026-16493が直接問題にするのは、Gitソースを処理する経路です。Galaxyサーバーから通常のCollectionアーティファクトを取得する処理と、Git URIから直接取得する処理は分けて調査してください。

ただし、公式サーバーから取得したという理由だけで、Collection自体の内容確認や署名検証が不要になるわけではありません。

ansible-2.17.11-2.azl3なら修正済みですか

CVE-2026-16493については、2.17.11-2という番号だけで修正済みとは判断できません。

Azure Linuxの公開変更履歴で、2.17.11-2はCVE-2026-11332の修正として説明されています。CVE-2026-16493の修正完了条件には、MicrosoftがこのCVEへの対応を明示したRPMを使用してください。(GitHub)

Azure Linuxの再起動は必要ですか

Ansibleはユーザー空間で動作するため、カーネル更新のようにOS再起動そのものが修正確認になるわけではありません。

重要なのは、更新後の新しいAnsibleが実際に使われていることです。常駐ランナー、長時間稼働するコンテナ、Execution Environmentなどは再起動または再作成し、古いプロセスやイメージが残らないようにしてください。

今すぐ行う対応チェックリスト

  • [ ] Azure Linux 3.0上のAnsibleコントロールノードを特定する
  • [ ] CI/CDランナー、ビルダー、Execution Environmentを調査する
  • [ ] rpm -q ansibleでRPMの完全なバージョンを確認する
  • [ ] command -v ansibleで実際の実行ファイルを確認する
  • [ ] pip、venv、pipx、コンテナ内のansible-coreも確認する
  • [ ] requirements.yml内のGitソースを検索する
  • [ ] 信頼できないGit URIからのCollection導入を停止する
  • [ ] 2.17.11-1や2.17.11-2を番号だけで修正版と判定しない
  • [ ] MSRCまたはAzure LinuxでCVE-2026-16493との対応が明示されたRPMを確認する
  • [ ] 修正版へ更新し、コンテナやランナーを再構築する
  • [ ] 更新後のRPM、実行パス、Ansibleバージョンを記録する
  • [ ] 不審なURIを処理済みなら資格情報を失効し、侵害調査を行う

CVE-2026-16493への対応では、最初に次の2つのコマンドを実行し、インストール済みRPMと実際に動くAnsibleを突き合わせることが重要です。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' ansible
command -v ansible

そのうえで、CI/CDやrequirements.ymlからGit形式のCollection取得を探してください。MSRCに表示されるazl3 ansible 2.17.11-1 on Azure Linux 3.0という文字列だけで対応済みにせず、CVE-2026-16493の修正が明示されたRPMを実際の実行環境へ導入したことを確認して、初めて対応完了とします。

Linux
Ansible 脆弱性対策 Azure Linux 3.0 CVE-2026-16493 Ansible Galaxy

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次