技術 約6分で読めます

PAN-OSのCVE-2026-0300悪用でUser-ID Authentication Portalからroot RCEに到達

いけさん目次

TL;DR

影響 PAN-OSのUser-ID Authentication Portalを有効化したPA-Series / VM-Series。公開インターネットやuntrusted zoneから届く構成ではCVSS 9.3のroot RCE

対応 修正版は2026年5月13日以降に順次提供予定。パッチ前はPortalの到達元をtrusted zoneへ限定、不要なら無効化

暫定 Response Pagesの無効化、Threat ID 510019の有効化、nginx crash痕跡・core dump削除・AD列挙・EarthWorm / ReverseSocks5取得の確認


Palo Alto Networksが2026年5月5日に公開したCVE-2026-0300は、User-ID Authentication Portal(Captive Portal)のバッファオーバーフローだ。
PA-Series / VM-SeriesでこのPortalを使っており、untrusted IPや公開インターネットから到達できる構成だと、認証なしでroot権限の任意コード実行まで行ける。

5月6日のUnit 42のThreat Briefで話が一段進んだ。
単なる「危険な未修正CVE」ではなく、CL-STA-1132として追跡される国家支援型と疑われる攻撃グループが、すでにRCEを成立させてnginx worker processへshellcodeを注入していた。
The Hacker Newsの続報では、4月9日ごろの失敗試行、1週間後の成功、4月29日の2台目への展開まで時系列が出ている。

PAN-OSとCaptive Portalの構成

PAN-OSはPalo Alto Networks製の次世代ファイアウォールで動く専用OSだ。
ハードウェアアプライアンスのPA-Seriesと仮想マシン版のVM-Seriesで動き、企業ネットワークの境界防御やデータセンターのセグメント分離に使われている。
Panoramaで複数台を一元管理し、Prisma AccessやCloud NGFWはクラウド提供版にあたる(今回の脆弱性はPA-SeriesとVM-Seriesのみ対象)。

User-ID Authentication Portal(Captive Portal)は、PAN-OS上で動く認証ゲートだ。
未認証ユーザーがネットワークにアクセスしようとするとWebログイン画面にリダイレクトし、認証を通さないとトラフィックを許可しない。
空港やカフェのWi-Fiで出る接続前ログイン画面と仕組みは似ているが、企業のPAN-OS環境ではActive Directoryと連携している。
認証後のIPアドレスとADアカウントの紐付けを使って、ファイアウォールポリシーをユーザー単位で適用するUser-ID機能と連動する。

このPortalがADとの連携を握っている点が、今回の脆弱性のインパクトを重くしている。
Portalを攻略すればファイアウォールのroot権限だけでなく、内部のID基盤への足がかりまで手に入る。

公開Captive Portalだけが主戦場になる

公式アドバイザリの露出条件はかなり具体的だ。
User-ID Authentication Portal SettingsでAuthentication Portalが有効になっていて、Response Pageが有効なInterface Management Profileを、untrustedまたはinternet trafficが入るL3 interfaceへ付けている場合に問題になる。

Prisma Access、Cloud NGFW、Panorama appliancesは対象外。
PAN-OSを使っていても、Portalを使っていない環境や、trusted internal IPからしか届かない構成ではリスクが大きく下がる。
逆に、外向きのファイアウォールでCaptive Portalを公開しているなら、パッチ日を待つ話ではなく露出を先に切る話になる。

対象バージョンはPAN-OS 12.1、11.2、11.1、10.2系にまたがる。
修正版のETAは系列ごとに5月13日と5月28日に分かれており、記事作成時点(2026年5月9日 JST)ではまだ「更新すれば完了」になっていない系列が多い。

系列影響範囲の例修正版の予定
PAN-OS 12.112.1.4-h5未満、12.1.7未満12.1.4-h5は5月13日、12.1.7は5月28日
PAN-OS 11.211.2.4-h17未満、11.2.7-h13未満、11.2.10-h6未満、11.2.12未満5月13日または5月28日
PAN-OS 11.111.1.4-h33未満、11.1.6-h32未満、11.1.10-h25未満など5月13日または5月28日
PAN-OS 10.210.2.7-h34未満、10.2.10-h36未満、10.2.18-h6未満など5月13日または5月28日

ここはNVDやスキャナーのCVSSだけを見るより、ベンダーアドバイザリを直接読むほうが早い。
NIST NVDがCVE全件エンリッチメントをやめた話でも書いた通り、実悪用があるCVEではCISA KEV、ベンダーadvisory、Unit 42のような調査レポートを並べて見る運用に寄せるしかない。

侵害後の動きがファイアウォール内で終わっていない

Unit 42が出した今回の嫌な点は、RCE後の動きだ。
攻撃者は初期侵害直後にcrash kernel messages、nginx crash entries、nginx crash records、crash core dump filesを消している。
つまり「Portalのログに失敗が並んでいないから無傷」とは言えない。

その後、ファイアウォールのservice account credentialsを使ってActive Directoryを列挙したとされている。
ファイアウォールを境界機器としてしか見ていないと、この段階を見落とす。
User-IDまわりはそもそも認証・ユーザー識別のためにADと関係を持つので、侵害後に内部ID基盤へ手が伸びる流れが自然に残る。

4月29日にはSAML floodで以前の対象デバイスから2台目をActiveに昇格させ、同じinternet-facing trafficを継承させたうえで、2台目でもRCEを成立させたとUnit 42は説明している。
そこでEarthWormとReverseSocks5が落とされた。
どちらもオープンソースのトンネリングツールで、ReverseSocks5は被害側から外へ接続を張り、攻撃者が内部ネットワークへSOCKS5経由で入るために使える。

APT28のTP-LinkルーターDNS改ざんでも似た構図が出ていた。
境界の箱はEDRが入りにくく、ログも薄く、侵害後はネットワークと認証の両方を触れる。
今回のPAN-OSではSOHOルーターではなく企業ファイアウォールが対象なので、取得できる権限と内部到達性がさらに重い。

パッチ前に切れる入口

公式の暫定策は2本立てだ。
User-ID Authentication Portalへのアクセスをtrusted zoneだけに絞り、untrustedまたはinternet trafficが入るL3 interfaceに付けたInterface Management ProfileではResponse Pagesを無効化する。
Portalを使っていないなら無効化する。

Threat Prevention subscriptionがある場合は、Applications and Threats content version 9097-10022以降でThreat ID 510019を有効化する。
ただし、Threat IDのdecoder supportにはPAN-OS 11.1以降が必要とされている。
古い10.2系を残している環境では、シグネチャで塞ぐ前提に寄せすぎないほうがいい。

公開管理面のRCEは、入口が違っても運用上の癖が似る。
ActiveMQ Jolokia APIのRCEでは「管理APIを外へ出していたら、認証の有無やデフォルト認証情報が被害を決める」話だった。
PAN-OSの場合は管理APIではなくCaptive Portalだが、外部から到達できる製品内サービスが、その製品の最強権限へ直結する点は同じだ。

見るログはPortalだけでは足りない

侵害調査では、User-ID Authentication Portalの到達ログだけで終わらせない。
Unit 42が挙げた挙動に沿うなら、nginx worker processへの不自然なshellcode注入、crash関連ログの欠落、core dump削除、audit logからのptrace injection evidence削除、SUID privilege escalation binaryの削除が候補になる。

ネットワーク側では、ファイアウォール自身から外へ出るHTTP/HTTPS取得を疑う。
EarthWormやReverseSocks5の取得、外向きSOCKSトンネル、普段ない宛先への長時間セッションがあるなら、Portalの露出有無と時系列を合わせる。

AD側も見る。
ファイアウォールのservice account credentialsでdomain rootやDomainDnsZonesを列挙した痕跡、通常のUser-ID運用では出ないLDAP query、短時間に集中した認証失敗や成功が残っていないかを追う。
ファイアウォールを再起動してパッチ適用しても、持ち出された資格情報や内部列挙の結果は消えない。

参考