Palo Alto脆弱性CVE-2026-0265/0300｜Cloud NGFW・VM-Series影響評価とTerraform更新フロー

「Palo Alto Networksの脆弱性が出たらしいが、AWSのCloud NGFWやAzureのVM-Seriesを使っているうちの環境はアップデートが必要なのか」
ハードウェアアプライアンスのファイアウォールを20年以上扱ってきた感覚で言えば、Palo Alto Networksの脆弱性が出た時点で「即パッチ」が正解です。しかしクラウドに置いたNGFWは話が分岐します。マネージドサービスのCloud NGFW for AWSとPrisma Accessは今回のCVEの影響を受けず、ユーザー責任でPAN-OSを動かすVM-Series in AWS/Azureだけが「セルフ更新必須」というのが本記事の結論軸です。

この記事では2026年5月公開のPalo Alto Networks 2件の重要脆弱性（CVE-2026-0265 CAS認証バイパス・CVE-2026-0300 User-ID境界外書き込みRCE）について、クラウドNGFW構成での影響範囲、Cloud NGFW for AWS／VM-Series／Prisma Accessの取り扱い、AWS SG／Azure NSGとの多層防御、Terraform IaCでのバージョン管理を、クラウドFW運用設計視点で整理します。SOC初動観点はSecurityMaster側Palo Alto脆弱性記事で別途扱っています。

2026年5月、Palo Alto Networksで何が公開されたか（CVE-2026-0265／0300の一次情報整理）

まずは伝聞を排し、Palo Alto Networks Security Advisoryの一次情報を整理します。

JPCERT/CCの週次レポート2026-05-20【7】では、複数のPalo Alto Networks製品に脆弱性があるとの注意喚起がなされ、参照先としてPalo Alto Networks Security Advisoryが示されました。特にクラウド観点で押さえるべき2件は次のとおりです。
・CVE-2026-0265: Cloud Authentication Service(CAS)有効時の認証バイパス。CVSS v4.0 7.2(High)。
・CVE-2026-0300: User-ID認証ポータルの境界外書き込みによるリモートコード実行(RCE)。CVSS v4.0 9.3(Critical)。

CVE-2026-0265はCAS認証プロフィールが有効なログインインターフェースに対して、認証情報を持たない攻撃者がネットワーク経由で認証制御を迂回できる脆弱性です。CVE-2026-0300はUser-ID認証ポータルの境界外書き込みでroot権限の任意コードが実行されます。両CVEとも認証不要・ユーザー操作不要でリモート攻撃可能、0300は「限定的な悪用」が観測済みです。

ここでクラウド運用者にとって最重要なのは「影響を受けない製品」のリストです。
・Cloud NGFW: すべてのバージョンが両CVEの影響対象外
・Prisma Access: すべてのバージョンが両CVEの影響対象外
・VM-Series: PAN-OSバージョンが脆弱な範囲なら影響対象（CVE-2026-0300はVM-Series上のroot RCEを明示）
・PA-Series（物理）: PAN-OSバージョンが脆弱な範囲なら影響対象

つまり「同じPalo Alto Networksブランドのファイアウォール」でも、Cloud NGFW for AWS／Prisma Accessはマネージドサービスとして提供されるためユーザーは何も操作不要、VM-Series in AWS/AzureはユーザーがPAN-OSを動かしているため自己責任でアップグレード必須、という運用責任分界が今回明確に効いてきます。

Cloud NGFW for AWSの影響評価とユーザーが本当に確認すべきこと

Cloud NGFW for AWSはPalo Alto NetworksがAWS上でフルマネージド提供するNGFWサービスです。コントロールプレーン・データプレーン双方をPalo Alto Networksが運用し、PAN-OSのアップグレードはユーザーに開放されていません。今回のCVE-2026-0265／0300についても、Palo Alto Networks Security Advisoryの「Affected Products」セクションでCloud NGFWは明示的に「Not Affected」と分類されています。

これだけ聞くと「うちのCloud NGFWは何もしなくていい」となりますが、クラウドFW運用設計の視点では別の論点が残ります。Shared Responsibility Modelに照らすと、PAN-OS本体はPalo Alto Networks側、ルールスタック・セキュリティポリシー・脅威ID設定・ログ転送先はユーザー責任です。脆弱性公開タイミングは次の3点を再点検する好機です。

Cloud NGFWのコストは東京リージョン(ap-northeast-1)で1エンドポイント当たり概ね月額400USD前後、データ処理量1GB当たり0.065USD前後（2026年5月時点の参考値、最新請求はAWS Cost Explorerで確認）。AZごとにエンドポイントを配置するとコスト3倍が目安のため、本脆弱性対応を機にAZ単位のコスト最適化を併せて見直すと効率的です。マネージドサービスはユーザーが触らない部分が増えていくため、CVE公開はIAM・ログ・脅威プロファイル棚卸しの好機として使うのが現場目線で最も効率的です。Linuxサーバー本体のセキュリティ運用は姉妹サイトLinuxMaster.JPで解説しています。

VM-Series in AzureとPrisma Accessの取り扱いを分けて整理する

ここからがクラウド運用者にとっての本題です。VM-Series in Azure／AWSはユーザーがPAN-OSバージョンを管理する責任があり、今回のCVE-2026-0265／0300の影響を受けます。一方でPrisma Accessは影響対象外です。同じ「クラウド寄りのPalo Alto Networks製品」でも、運用責任が分かれているため対応フローも変わります。

VM-Series in Azureを利用している現場は次の手順で対応します。第1にAzure Portal上のVM-SeriesでPAN-OSバージョンを確認しアドバイザリの「Fixed in」以上か判定。第2にUser-ID認証ポータルおよびCAS認証プロフィールの利用有無を確認し、未使用なら無効化、使用中なら管理インターフェースのアクセスソースをAzure NSGおよびASGで信頼ネットワークのみに絞り込み。第3にPAN-OS修正版へのアップグレード計画を策定しHAペアでメンテナンス窓を確保して適用します。

VM-Series in AWSも基本フローは同じです。VM-SeriesのPAN-OSバージョンをコンソールまたはCLI(`show system info`)で確認し、影響該当ならメンテナンス窓を確保してアップグレード。AWS Marketplace経由デプロイの場合、AMI入れ替えではなくPAN-OS内部の更新で対処するのが原則です。

Prisma AccessはマネージドサービスのためPAN-OSアップグレードはPalo Alto Networksが自動実施。ユーザー側はインフラ更新通知メールの確認とService Connection／Remote Network Connectionの影響時間帯の社内周知のみ。今回の2件は影響対象外のため追加作業は基本発生しません。

CVE-2026-0265の「条件付き影響」とは、CAS認証プロフィールが有効でかつログインインターフェースに割り当てられている場合のみという意味です。ログインインターフェースに認証プロフィール割当のない構成は影響対象外となります。実機ではVM-Seriesでも商用デプロイの大半がSAMLまたはRADIUSを使用しており、CAS利用率は限定的です。一方でCVE-2026-0300はUser-ID認証ポータルが有効なPAN-OSデバイスは無条件で影響を受けるため、こちらの方が運用上のクリティカル度は高くなります。

ここで重要なのは「Cloud NGFWに切り替えれば今後の同種CVEからも解放される」というシンプルな結論を出さないことです。Cloud NGFWは確かにPAN-OS本体のCVE対応をユーザー責任から外せますが、ルールスタックやセキュリティポリシーの設計責任、IAMロールの権限スコープ、ログ転送先の保護はユーザー側に残ります。VM-Seriesと比較したコスト・カスタマイズ性・運用負荷の3軸で総合判断する必要があります。

AWS Security Group・Azure NSGとの多層防御を見直す

「VM-SeriesのPAN-OSをアップグレードすればこの脆弱性は終わる」と片付けるのが、オンプレ時代のFW運用に慣れた現場の典型的な失敗パターンです。クラウドではNGFWの上下に既にAWS Security GroupまたはAzure NSGという「もうひとつのファイアウォール層」が存在しており、これが多層防御として機能しているかを脆弱性対応のたびに点検するのが正解です。

AWS Security Group／Azure NSGはL3／L4ベースの基本的なフィルタリングしか提供せず、PAN-OSのような深層パケット検査(DPI)や脅威防御は持ちません。そのため「NGFWだけで完結させる」設計は実装としては成立しますが、NGFW自体がCVE-2026-0300のようなRCE脆弱性で侵害された場合、上位／下位の何が攻撃者の足場になるかが論点になります。多層防御の観点で再点検すべきは次の3点です。

1つ目はVM-Seriesの管理インターフェース保護です。管理インターフェース(eth1/0)に対し、運用拠点IPおよびAnsible／Terraform実行サーバーIPからのみインバウンド許可が原則。管理インターフェースが0.0.0.0/0に開いていればCVE-2026-0265の認証バイパス試行リスクが桁違いに上がります。SG／NSGの送信元IP制限は「最低限の二重ロック」です。

2つ目はUser-ID認証ポータル公開インターフェースの保護です。CVE-2026-0300は認証ポータルへの細工パケットでトリガーされるため、SG／NSGでアクセス元を限定すればPAN-OS到達前に遮断できます。Azure NSGではASG、AWSではSGの参照ベース許可が役立ちます。

3つ目はEast-Westトラフィック制御です。VM-Series侵害でroot権限を取られた場合、内部EC2／Azure VMへの横展開が始まります。SG／NSGのEgressルールを「必要な宛先のみ許可」に切り替えていない現場は、本対応に併せて見直す価値があります。

クラウドではSG／NSG／NGFW／WAF／VPC Endpointの5層構造になっており、どの層も単独で侵害される前提で設計するのが現代のセオリーです。

Terraform／IaCでのPAN-OSバージョン固定と更新フロー

Terraformでクラウド上のVM-Seriesを管理している現場では、PAN-OSバージョンの取り扱いがそのまま脆弱性対応のスピードを決めます。Palo Alto NetworksはAWS／Azure双方に対して公式Terraformモジュール(`terraform-provider-panos`、`terraform-aws-vmseries-modules`、`terraform-azurerm-vmseries-modules`)を提供しており、これらのモジュールは「バージョン固定」を強く推奨しています。

VM-Series Terraform構成では、AMI ID／Image Reference／PAN-OSソフトウェアバージョンの3階層でバージョン管理が分かれます。AMI IDは初期デプロイ時のベース、PAN-OSソフトウェアバージョンはデプロイ後の運用更新で変わります。Terraform側でAMI IDだけを固定し、PAN-OSは別の運用フロー（Panorama経由またはWeb UI経由）で更新する2階層管理が現場では一般的です。

“`
# 例: Terraform variables.tf でのバージョン固定（概念）
# AMI IDは初期デプロイ専用、運用更新時はPanorama側でPAN-OSを管理する
variable “vmseries_ami_id” {
type = string
default = “ami-xxxxxxxxxxxxxxxxx” # 初期デプロイ時のAMI
}

variable “vmseries_panos_target_version” {
type = string
default = “11.2.12” # 修正版を明示してドリフト検知
}
“`

このような形でTerraform側にtarget versionを変数として持っておき、Panorama側の実バージョンと比較するスクリプトをCI／CDで回しておけば、脆弱性公開時に「どのVM-Seriesがどのバージョンか」を即座に棚卸しできます。

Cloud NGFW for AWSのTerraform管理は別アプローチになります。`terraform-provider-cloudngfwaws`はPAN-OSバージョンに依存せず、ルールスタック・セキュリティルール・脅威防御プロファイル・NGFWエンドポイントを宣言的に管理します。PAN-OS本体のアップグレードはPalo Alto Networks側で透過的に行われるため、Terraform側で考慮する必要はありません。ただしルールスタックのバージョン管理（commit／rollback）はユーザー責任で残るため、`terraform plan`の差分が出る場合は必ず内容を確認してからapplyする運用フローが必要です。

Terraform更新時のチェック観点を5つに絞ると次のようになります。
・バージョンドリフト検知: Panorama実バージョンとTerraform変数の比較を週次CIで自動化
・HAペアの順序保証: Active／Passiveの切替手順をTerraform外のRunbookで明文化
・ルールスタック差分の事前レビュー: Cloud NGFW側`terraform plan`は必ずPRレビュー必須化
・IAMロール最小権限: Terraform実行ロールの`cloudngfwaws:*`は必要なアクションのみ列挙
・state ファイルの保護: S3バックエンドのSSE-KMS暗号化＋バージョニング＋MFA Delete

CVE公開のたびに同じチェックリストを回せる状態を作っておくのが、クラウドFW運用の安定化への近道です。

Palo Alto NetworksのCloud NGFW for AWS Terraformプロバイダはオープンソースとして公開されており、AWS Quick Start経由でVM-Seriesのリファレンスアーキテクチャもデプロイ可能です。両者の使い分けの基本は「マネージド優先か、PAN-OSの完全制御優先か」で判断します。

クラウドネットワーク全体のIaC設計を深掘りしたい場合は、書籍Amazon Web Services基礎からのネットワーク&サーバー構築改訂4版（PR）でVPC／Direct Connect／VPN構成の基礎を抑えると、Palo Alto Networks製品との接続設計が一段クリアになります。

よくある質問（FAQ）

Q1. Cloud NGFW for AWSは何もしなくて本当に大丈夫ですか？
A. Palo Alto Networks Security Advisoryの「Affected Products」セクションでCloud NGFWはNot Affectedと明示されています。ただしPAN-OS本体のCVE対応とは別に、ユーザー責任のルールスタック・脅威プロファイル・IAMポリシー・ログ転送設定は脆弱性公開タイミングで棚卸ししておくと安心です。

Q2. VM-Series in Azureを使っていますがPAN-OSバージョン確認方法は？
A. VM-SeriesにSSHでログインし`show system info`コマンドで`sw-version`を確認します。またはAzure PortalからVMの拡張機能経由でも取得可能です。Panorama経由で集中管理している場合はPanorama UIのDevices画面に全VM-Seriesのバージョンが表示されます。

Q3. Prisma AccessはなぜCVEの影響を受けないのでしょうか？
A. Prisma AccessはPalo Alto Networksがマネージド提供するSASE/SSE型のクラウドセキュリティサービスで、PAN-OS本体のアップグレード／パッチ適用はサービス側で実施されます。脆弱性公開時点でPalo Alto Networksが社内的に修正版へ更新済みのため、ユーザー側でPAN-OSバージョンを意識する必要がありません。

Q4. VM-SeriesからCloud NGFWへの移行は今回のCVEを機にやるべきですか？
A. 単発のCVE対応を理由に移行判断するのは早計です。Cloud NGFWはPAN-OS本体の責任が外れる代わりにカスタマイズ性が制限される場合があり、コスト・カスタマイズ性・運用負荷の3軸を半年～1年スパンで比較してください。

Q5. User-ID認証ポータルは未使用ですがCVE-2026-0300の影響はありますか？
A. User-ID認証ポータルがインターフェースに割り当てられていない構成では影響対象外です。Web UIの`Network → Network Profiles → Interface Mgmt`で各インターフェースの「Authentication Portal」が無効化されているかを点検します。

Q6. Terraform管理のVM-SeriesでPAN-OSアップグレードはTerraform完結できますか？
A. 原則できません。PAN-OS本体の更新はPanorama／Web UI／CLIで実施し、TerraformはAMI ID／インスタンスタイプ／ネットワーク設定の管理に留めるのが推奨フローです。`panos_target_version`変数でドリフト検知のみ自動化するのが現実解です。

Q7. AWS Security GroupだけでVM-Series相当の防御は実現できますか？
A. できません。SGはL3／L4のステートフルフィルタリングに限定され、DPI・脅威防御・URLフィルタリングはありません。SGは下位層、L7検査はNGFW（VM-SeriesまたはCloud NGFW）の役割分担が定石です。

本記事のまとめとクラウドFW運用チェックリスト

2026年5月公開のPalo Alto Networks脆弱性CVE-2026-0265／0300について、クラウド観点でのポイントとCVE公開時に使える運用チェックリストを整理します。
・Cloud NGFW for AWS／Prisma Access: 両CVEとも影響対象外、ユーザー側のPAN-OS更新作業は不要
・VM-Series in AWS／Azure: ユーザー責任でPAN-OSアップグレード必須、HAペアでメンテ窓確保
・SG／NSGの管理面保護: 管理インターフェースのインバウンドを信頼IPのみに絞り込み、User-IDポータルのアクセス元を限定
・Terraform管理: `panos_target_version`変数でドリフト検知、PAN-OS本体更新はPanorama側で実行
・運用棚卸し: CVEのたびにIAM／ログ転送／脅威プロファイルを点検する習慣化が現場目線で有効

属人化しやすいのはPAN-OSバージョン情報がスプレッドシートに散在しているケースで、TerraformまたはPanoramaに集約しておくと脆弱性公開時の初動が大きく短縮できます。Terraform実装の基礎から継続的デプロイ運用までを腰を据えて学ぶなら、書籍Terraformではじめる実践IaC ―AWSでのインフラストラクチャ構築の基本から継続的デプロイまで（PR）が体系的にまとまっており、PAN-OSバージョン管理のような「運用とIaCの結節点」を考えるベースになります。

SOC初動や国内FWシェア観点での「ファイアウォール本体が攻撃面」になる時代の意義については、姉妹サイトSecurityMaster側のPalo Alto Networks複数脆弱性｜CAS認証バイパスとUser-ID RCE、ファイアウォール本体が狙われる時代のSOC対応で詳しく解説していますので、合わせてご覧ください。