CVE-2026-0300, Root RCE in PAN-OS Captive Portal

CVE-2026-0300 is not just another perimeter bug with a scary score. It is a root-level remote code execution vulnerability in the PAN-OS User-ID Authentication Portal, also known as Captive Portal, on affected Palo Alto Networks PA-Series and VM-Series firewalls. Palo Alto Networks describes the flaw as a buffer overflow in the User-ID Authentication Portal service that can allow an unauthenticated attacker to execute arbitrary code with root privileges by sending specially crafted packets. The official advisory marks the urgency as highest, assigns a CVSS v4.0 score of 9.3, and lists the exploit maturity as attacked. (セキュリティ.paloaltonetworks.com)

The important word is not only “critical.” The important word is “exposed.” CVE-2026-0300 applies only when the right vulnerable code path is reachable: the firewall must be a PA-Series or VM-Series system configured to use User-ID Authentication Portal, and the environment must expose the relevant portal behavior to untrusted or internet traffic. Prisma Access, Cloud NGFW, and Panorama appliances are listed as not impacted by this vulnerability. (セキュリティ.paloaltonetworks.com)

The bug also arrived with signs of real exploitation. Palo Alto Networks said limited exploitation had been observed against User-ID Authentication Portals exposed to untrusted IP addresses or the public internet. NVD records the vulnerability as received from Palo Alto Networks on May 6, 2026, and notes that CISA added it to the Known Exploited Vulnerabilities catalog with a required action to apply vendor mitigations or discontinue use if mitigations are unavailable. (セキュリティ.paloaltonetworks.com)

That combination changes the defender’s job. A vulnerability scanner finding is not enough. A clean version inventory is not enough. A firewall team has to answer four operational questions quickly: is the feature enabled, is the vulnerable traffic path reachable, is the device already suspicious, and can the exposure be removed before the fixed build is installed.

What CVE-2026-0300 actually affects

The vulnerable component is the PAN-OS User-ID Authentication Portal, which Palo Alto Networks also refers to as Captive Portal. In normal deployments, this feature helps the firewall map unknown traffic to user identity when the firewall cannot already associate an IP address with a username. That identity context can then be used in policy decisions.

Palo Alto’s official configuration guidance for Authentication Portal explains that a non-management Layer 3 interface used for incoming web requests must have an Interface Management Profile assigned, and that profile must enable Response Pages and User-ID. The same documentation also states that the management interface is used by default when connecting to authentication servers or User-ID agents, while service routes can be configured for authentication services such as LDAP, Kerberos, RADIUS, TACACS+, MFA, or UID Agent. (docs.paloaltonetworks.com)

That matters because CVE-2026-0300 is not simply “PAN-OS equals vulnerable.” It is a configuration-dependent exposure. Palo Alto says customers are impacted if both conditions are true: User-ID Authentication Portal is configured in the Authentication Portal settings, and an Interface Management Profile with Response Pages enabled is attached to any Layer 3 interface in a zone where untrusted or internet traffic can ingress. (セキュリティ.paloaltonetworks.com)

The official advisory also states that the risk is highest when the User-ID Authentication Portal is configured to enable access from the internet or any untrusted network. Restricting the portal to trusted internal IP addresses greatly reduces the risk. (セキュリティ.paloaltonetworks.com)

フィールド	Current understanding
CVE	CVE-2026-0300
Vendor	Palo Alto Networks
Product family	PAN-OS on PA-Series and VM-Series firewalls
コンポーネント	User-ID Authentication Portal, also known as Captive Portal
弱さ	CWE-787 out-of-bounds write
攻撃ベクトル	ネットワーク
Authentication required	なし
User interaction	なし
インパクト	Arbitrary code execution with root privileges
Public status	Limited exploitation observed
CISA KEV status	Added to Known Exploited Vulnerabilities catalog
Not impacted	Prisma Access, Cloud NGFW, Panorama appliances
Main mitigation before patch	Restrict Authentication Portal to trusted zones and disable Response Pages on untrusted ingress interfaces, or disable Authentication Portal if unused
Threat prevention option	Threat ID 510019, with PAN-OS 11.1 or later decoder support requirement

The table should be read as an exposure triage guide, not as a replacement for the vendor advisory. Palo Alto’s advisory was updated on May 7, 2026, and the patch table includes staged expected availability dates. Emergency handling should follow the current vendor advisory first. (セキュリティ.paloaltonetworks.com)

Why the Captive Portal path matters

Captive Portal is often treated as a user-experience feature. A user hits a page, authenticates, receives a mapping, and continues browsing. In a firewall, however, that flow intersects with sensitive boundary logic: HTTP handling, response pages, certificates, identity providers, directory services, interface profiles, and policy enforcement.

Palo Alto’s documentation distinguishes between Transparent and Redirect modes. Transparent mode intercepts web requests and impersonates the original destination URL by issuing an HTTP 401 authentication challenge, but browsers can show certificate errors because the firewall does not have the real certificate for the destination. Redirect mode intercepts web requests and sends users to a configured Redirect Host with an HTTP 302 response. Palo Alto describes Redirect mode as the better end-user experience and notes that it requires Response Pages on the Interface Management Profile assigned to the ingress Layer 3 interface. (docs.paloaltonetworks.com)

That requirement is central to the exposure condition. Response Pages are not just cosmetic HTML pages. The Interface Management Profile documentation says Response Pages enable Captive Portal response pages and leave ports open on Layer 3 interfaces, specifically port 6081 for Captive Portal in transparent mode and port 6082 for Captive Portal in redirect mode. (docs.paloaltonetworks.com)

For defenders, the operational takeaway is simple: the vulnerable feature path is tied to interface behavior. A firewall can be running an affected PAN-OS version but not be externally exploitable if the portal is not enabled and the Response Pages path is not reachable from untrusted networks. The inverse is also true. A firewall that looks “fine” from a generic software inventory perspective may still be exposed if a dataplane interface has the wrong Interface Management Profile attached.

This is exactly why edge-device CVEs create recurring incident response friction. The asset is not a normal server. Its network role is the reason it is exposed, its management model is different from endpoint systems, and the security team may not have EDR-level telemetry on the device itself. If attackers get code execution on the firewall, they are not just landing on a box. They are landing on a privileged network control point.

Affected PAN-OS versions and patch window

As of the current advisory state available on May 9, 2026, the official Palo Alto Networks table lists affected and planned fixed versions across PAN-OS 12.1, 11.2, 11.1, and 10.2. The table below follows the vendor advisory and should be treated as time-sensitive because some entries were listed with estimated release dates rather than already available builds. (セキュリティ.paloaltonetworks.com)

PAN-OS branch	影響を受けるバージョン	Fixed or planned unaffected versions	Vendor ETA in advisory
12.1	Earlier than 12.1.4-h5, earlier than 12.1.7	12.1.4-h5 or later, 12.1.7 or later	May 13 and May 28
11.2	Earlier than 11.2.4-h17, 11.2.7-h13, 11.2.10-h6, 11.2.12	11.2.4-h17 or later, 11.2.7-h13 or later, 11.2.10-h6 or later, 11.2.12 or later	May 13 and May 28 depending on train
11.1	Earlier than 11.1.4-h33, 11.1.6-h32, 11.1.7-h6, 11.1.10-h25, 11.1.13-h5, 11.1.15	Matching fixed hotfix or later versions	May 13 and May 28 depending on train
10.2	Earlier than 10.2.7-h34, 10.2.10-h36, 10.2.13-h21, 10.2.16-h7, 10.2.18-h6	Matching fixed hotfix or later versions	May 13 and May 28 depending on train

Rapid7’s emergency threat response post matches the same key pattern: no patches were available at initial publication, fixed versions were expected to begin rolling out on May 13, 2026, and additional releases were expected through May 28, 2026. (ラピッド7)

The staged release timeline affects how risk should be handled. A team cannot wait passively for the exact preferred hotfix if the portal is reachable from untrusted networks. The mitigation must reduce reachability first. Then patch as soon as a fixed release is available for the branch. Then retest the exposure. Then hunt for compromise.

The CISA KEV deadline makes the timeline even tighter for U.S. federal civilian agencies. NVD’s CISA KEV section lists CVE-2026-0300 as added on May 6, 2026, with a due date of May 9, 2026, and required action to apply vendor mitigations, follow BOD 22-01 guidance for cloud services, or discontinue use if mitigations are unavailable. (nvd.nist.gov)

Private-sector teams should not treat KEV as “government-only trivia.” KEV inclusion means there is evidence of active exploitation. For internet-facing edge devices, that is a materially different risk class from a theoretical advisory.

Exploitation status and post-exploitation behavior

The most useful public threat detail comes from Unit 42’s threat brief. Unit 42 said it was aware of only limited exploitation at publication time and was tracking CL-STA-1132, described as a likely state-sponsored threat cluster exploiting CVE-2026-0300. The attacker reportedly achieved unauthenticated RCE in PAN-OS and injected shellcode into an nginx worker process. (Unit 42)

Unit 42’s timeline matters because it shows the difference between “initial code execution” and “incident.” Starting April 9, 2026, there were unsuccessful exploitation attempts against a PAN-OS device. About a week later, the attackers successfully achieved RCE and injected shellcode. After compromise, they cleared crash kernel messages, deleted nginx crash entries and crash records, and removed crash core dump files. Four days later, they deployed tools with root privileges and conducted Active Directory enumeration using firewall service account credentials. On April 29, they reportedly conducted a SAML flood against the previously targeted device, promoted a second device to active, and then achieved RCE on the second device. (Unit 42)

That behavior is consistent with a disciplined edge-device operation. The attacker did not need noisy ransomware tooling to create serious risk. Root access on a firewall can support stealthy tunneling, identity discovery, traffic observation, configuration manipulation, and movement toward directory infrastructure.

Unit 42 specifically named EarthWorm and ReverseSocks5. EarthWorm is an open-source tunneling tool that can act as a SOCKS5 server, create reverse SOCKS5 tunnels, bridge listening ports, forward local traffic to remote hosts, and chain transfer modes for multi-hop tunneling. ReverseSocks5 establishes an outbound connection from the target to a controller and creates a SOCKS5 proxy tunnel, which allows the controller to route traffic into the target’s internal network. (Unit 42)

The defender’s mindset should shift from “Did someone send an exploit packet?” to “Did someone use the firewall as a covert pivot?” A firewall compromise may not look like a Windows endpoint compromise. There may be no familiar endpoint detection telemetry, no user workstation malware, and no obvious phishing chain. Instead, you may see a strange outbound tunnel, suspicious identity queries, HA failover anomalies, crash artifacts that disappear, or a service account used in a place it should not be used.

Why root on a firewall is different from root on a server

Root on a server is bad. Root on a firewall is strategically bad.

A firewall is placed at a trust boundary. It sees traffic that endpoint agents may never see. It can enforce or weaken segmentation. It may terminate VPNs, mediate identity-aware rules, talk to directory services, hold certificates, forward logs, and participate in high-availability failover. It is also often managed by a smaller group of network administrators, with change windows that differ from server patch cycles.

That creates several specific risks.

First, an attacker can use the device as a pivot point. If a tunneling tool runs on a firewall, its traffic can blend with expected infrastructure traffic better than malware on a random workstation. Outbound connections from security infrastructure may receive less scrutiny than outbound connections from a user laptop.

Second, the firewall may have credentials or service relationships that lead toward identity infrastructure. Unit 42 reported Active Directory enumeration using credentials likely obtained from the firewall. That is a critical clue: the perimeter device may become an identity stepping stone. (Unit 42)

Third, logging may be incomplete. Unit 42 reported cleanup of crash kernel messages, nginx crash records, crash core dumps, and audit evidence. If the attacker can remove evidence on the box, defenders must rely on independent logs: SIEM exports, NetFlow, packet capture where available, DNS logs, authentication logs, directory server logs, cloud telemetry, and management-plane change records. (Unit 42)

Fourth, HA pairs can turn one compromise into a sequence. The reported April 29 SAML flood and failover to a second device shows why teams must check both active and passive appliances, not only the unit that showed the first symptom. (Unit 42)

Finally, firewalls often sit outside normal endpoint hardening processes. If a server is compromised, responders may have EDR artifacts, memory telemetry, command-line logs, package inventories, and golden image rebuild processes. If an edge device is compromised, the response may require vendor support, enhanced factory reset, configuration restoration, secret rotation, and network revalidation.

The safest exposure triage flow

The first job is not to prove exploitation. The first job is to remove the exposed attack path without breaking legitimate business traffic more than necessary.

A practical triage flow looks like this.

ステップ	Question	Evidence source	アクション
1	Do we run PA-Series or VM-Series PAN-OS	Firewall inventory, Panorama, procurement CMDB, cloud VM records	Scope affected appliance class
2	Are we on affected PAN-OS branches	Running version and maintenance release	Map to vendor patch table
3	Is User-ID Authentication Portal enabled	Device > User Identification > Authentication Portal Settings	Disable if not required
4	Is Response Pages enabled on an ingress L3 interface profile	Network > Interface > Advanced Tab > Interface Management Profile	Remove Response Pages from untrusted ingress interfaces
5	Can untrusted or public traffic reach the portal path	External ASM, firewall zone policy, NAT, routing, packet capture	Restrict access to trusted zones and internal IPs
6	Is Threat Prevention available and compatible	Subscription status, content version, PAN-OS version	Enable Threat ID 510019 where supported
7	Are there signs of compromise	Device logs, external SIEM, NetFlow, directory logs, Unit 42 IoCs	Escalate to incident response
8	Is a fixed release available for our branch	Vendor advisory and support portal	Patch and retest exposure

Palo Alto’s workaround section is direct: restrict User-ID Authentication Portal access to only trusted zones, disable Response Pages in the Interface Management Profile attached to every Layer 3 interface where untrusted or internet traffic can ingress, keep Response Pages only on trusted internal interfaces where legitimate users’ browsers ingress, or disable User-ID Authentication Portal if it is not required. (セキュリティ.paloaltonetworks.com)

For customers with Threat Prevention, Palo Alto says attacks for this vulnerability can be blocked by enabling Threat ID 510019 from Applications and Threats content version 9097-10022. The same advisory notes that decoder capabilities require PAN-OS 11.1 or later for Threat ID support. (セキュリティ.paloaltonetworks.com)

That last detail is easy to miss. A team may have a subscription but still lack effective coverage if the PAN-OS version cannot support the required decoder capability. Treat signature-based protection as a layer, not the primary fix.

Non-destructive validation without exploit traffic

For an actively exploited root RCE, security teams often feel pressure to “prove” vulnerability with a proof of concept. That is the wrong default for production firewalls. A reliable exploit check could crash a service, alter memory, trigger failover, or create artifacts that look like attacker behavior. It may also violate policy or law if used outside explicit authorization.

A safer validation model is evidence-based and non-destructive.

Validation type	Safe method	What it proves	What it does not prove
Version validation	Compare PAN-OS version to vendor patch table	Software may be affected	Whether the vulnerable path is reachable
Feature validation	Check Authentication Portal configuration	Feature is enabled or disabled	Whether ingress exposure exists
Interface validation	Check Interface Management Profile and Response Pages	Response Pages can be served on specific interfaces	Whether internet routing reaches it
External exposure validation	Authorized external ASM or controlled connect tests that do not send malformed payloads	A portal-like service is reachable	Memory corruption exploitability
Threat prevention validation	Confirm content version and Threat ID 510019 mode	Signature layer is configured	That all attack variants are blocked
Post-patch validation	Confirm fixed version and re-check exposure	Patch state and exposure state improved	That prior compromise did not occur

A useful validation report should say one of three things: “not affected because the product class or version is outside scope,” “potentially affected but not externally reachable under current configuration,” or “affected and exposed, immediate mitigation required.” Avoid vague labels like “vulnerable” unless you can explain which condition made it vulnerable.

The following Python script is intentionally local-only. It parses an exported PAN-OS XML configuration file and looks for likely indicators that Authentication Portal is enabled, Interface Management Profiles include Response Pages, and interfaces reference those profiles. It does not connect to a firewall, does not send packets, and does not test exploitability. It is a starting point for authorized configuration review, not a vendor-supported scanner.

#!/usr/bin/env python3
"""
Local PAN-OS exposure helper for CVE-2026-0300 style triage.

Use only with configuration files you are authorized to review.
This script does not send network traffic and does not attempt exploitation.
It looks for configuration patterns that should trigger manual review:
  - Authentication Portal enabled
  - Interface Management Profiles with Response Pages enabled
  - Interfaces referencing those profiles

PAN-OS XML structure can vary by version and deployment.
Always confirm findings in the firewall UI or with vendor-supported tooling.
"""

from __future__ import annotations

import sys
import xml.etree.ElementTree as ET
from pathlib import Path
from typing import Iterable


def text_of(node: ET.Element | None) -> str:
    return "" if node is None or node.text is None else node.text.strip()


def iter_entries(root: ET.Element, tag_name: str) -> Iterable[ET.Element]:
    for node in root.iter("entry"):
        if node.get("name") == tag_name:
            yield node


def find_nodes_by_local_name(root: ET.Element, local_name: str) -> list[ET.Element]:
    return [node for node in root.iter() if node.tag.split("}")[-1] == local_name]


def has_yes_value(node: ET.Element) -> bool:
    return text_of(node).lower() in {"yes", "true", "enabled", "enable"}


def main() -> int:
    if len(sys.argv) != 2:
        print(f"Usage: {Path(sys.argv[0]).name} running-config.xml", file=sys.stderr)
        return 2

    config_path = Path(sys.argv[1])
    if not config_path.exists():
        print(f"File not found: {config_path}", file=sys.stderr)
        return 2

    root = ET.parse(config_path).getroot()

    print("[1] Authentication Portal indicators")
    auth_portal_hits = []
    for node in root.iter():
        tag = node.tag.lower()
        value = text_of(node).lower()
        if "authentication-portal" in tag or "captive-portal" in tag:
            auth_portal_hits.append((node.tag, value))

    if auth_portal_hits:
        for tag, value in auth_portal_hits[:30]:
            print(f"  - {tag}: {value}")
        if len(auth_portal_hits) > 30:
            print(f"  - ... {len(auth_portal_hits) - 30} additional matching nodes")
    else:
        print("  - No obvious Authentication Portal nodes found by tag search")

    print("\n[2] Interface Management Profiles with Response Pages")
    profiles_with_response_pages: set[str] = set()

    for profile in root.findall(".//profiles/interface-management-profile/entry"):
        profile_name = profile.get("name", "<unnamed>")
        response_pages = profile.find(".//response-pages")
        if response_pages is not None:
            enabled_children = [
                child.tag for child in list(response_pages)
                if has_yes_value(child) or text_of(child) == ""
            ]
            if enabled_children:
                profiles_with_response_pages.add(profile_name)
                print(f"  - {profile_name}: response-pages present, review manually")

    if not profiles_with_response_pages:
        print("  - No Interface Management Profile with obvious Response Pages found")

    print("\n[3] Interfaces referencing profiles with Response Pages")
    for interface in root.findall(".//interface//entry"):
        iface_name = interface.get("name", "<unnamed>")
        mgmt_profile = interface.find(".//management-profile")
        mgmt_profile_name = text_of(mgmt_profile)
        if mgmt_profile_name in profiles_with_response_pages:
            print(f"  - {iface_name}: references {mgmt_profile_name}")

    print("\n[4] Review reminder")
    print("  - Confirm whether these interfaces are Layer 3 interfaces.")
    print("  - Confirm whether any listed interface is in an untrusted or internet ingress zone.")
    print("  - Confirm whether User-ID Authentication Portal is enabled in the UI.")
    print("  - Apply Palo Alto Networks mitigation and patch guidance.")

    return 0


if __name__ == "__main__":
    raise SystemExit(main())

The script deliberately avoids making a final determination. PAN-OS configurations can be complex, especially with Panorama templates, multiple virtual systems, shared objects, and interface inheritance. The output is a prompt for manual validation.

For an authorized team using an AI-assisted security workflow, this is the kind of evidence chain that should be preserved: source advisory, affected version table, local configuration proof, external exposure proof, mitigation change, post-change retest, and final report artifact. Penligent’s public site describes workflows for security engineers, pentesters, and red teams that combine CVE scanning, guided verification, evidence-first results, and controlled agentic workflows; in a CVE-2026-0300 response, the safe use case is not firing exploit traffic at production firewalls, but organizing authorized checks and reproducible evidence around exposure reduction and retesting. (寡黙)

External exposure checks that avoid weaponized payloads

External validation should prove reachability, not memory corruption. A safe exposure check can answer whether the portal-like service is reachable from an untrusted vantage point without sending malformed exploit data.

Examples of safe checks include:

# Confirm DNS resolution for known portal hostnames.
dig +short auth.example.com

# Check whether a TCP service is reachable without sending exploit payloads.
nc -vz auth.example.com 443
nc -vz auth.example.com 6081
nc -vz auth.example.com 6082

# Capture TLS certificate metadata without fuzzing the endpoint.
openssl s_client -connect auth.example.com:443 -servername auth.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

These commands do not prove CVE-2026-0300 exploitation. They help identify public reachability, certificate identity, and unexpected listening services. If a team discovers a portal reachable from the internet or untrusted zones, the proper response is to restrict access or disable the feature, not to escalate into exploit testing.

For internet-scale exposure, public reporting varied because different scanners measure different signals. BleepingComputer cited Shadowserver tracking more than 5,800 exposed PAN-OS VM-Series firewalls online, mostly in Asia and North America, but that count should not be interpreted as the exact number of exploitable CVE-2026-0300 systems because exploitability also depends on Authentication Portal and Response Pages exposure. (ブリーピングコンピューター)

This distinction matters in executive communication. “Thousands of PAN-OS devices are visible online” is not the same as “thousands are confirmed vulnerable to CVE-2026-0300.” The right language is sharper: the publicly reachable population gives attackers a target pool, while the exploitable subset depends on configuration.

Immediate mitigation plan

The fastest safe action is to remove the exposed path.

First, disable User-ID Authentication Portal if the business does not require it. Palo Alto’s advisory explicitly lists disabling the portal as a mitigation option. (セキュリティ.paloaltonetworks.com)

Second, restrict Authentication Portal access to trusted zones only. This is not the same as “hide it behind an obscure hostname.” The control should be enforced through zone design, permitted IP ranges, interface profile settings, and firewall policy.

Third, disable Response Pages in Interface Management Profiles attached to every Layer 3 interface where untrusted or internet traffic can ingress. Palo Alto’s mitigation text is specific: keep Response Pages enabled only on interfaces in trust or internal zones where legitimate users’ browsers ingress. (セキュリティ.paloaltonetworks.com)

Fourth, enable the vendor-provided Threat Prevention coverage if available and compatible. Threat ID 510019 is a mitigation layer, not a substitute for removing exposure and patching. (セキュリティ.paloaltonetworks.com)

Fifth, prepare the patch path. Check the exact maintenance train and hotfix build, not just the major version. The patch table uses maintenance-specific thresholds. A firewall on PAN-OS 11.2 may need a different fixed build depending on whether it is in the 11.2.4, 11.2.7, 11.2.10, or 11.2.12 path. (セキュリティ.paloaltonetworks.com)

Sixth, check HA pairs together. If one unit is exposed, assume the paired unit may become exposed during failover or may inherit the same risky interface profile. Unit 42’s report that attackers used a SAML flood to promote a second device to active should be treated as a warning against single-appliance triage. (Unit 42)

Seventh, export and preserve logs before making large changes if compromise is suspected. Mitigation is urgent, but evidence can disappear quickly, especially if attackers have root access or if normal log rotation continues. Forwarded logs and out-of-band telemetry are especially valuable.

Hunt for compromise, not just exposure

CVE-2026-0300 response should include a compromise hunt if the device was exposed to untrusted networks before mitigation. The vendor advisory’s “limited exploitation” language does not guarantee safety for any individual organization. It only describes observed scope at the time of publication. (セキュリティ.paloaltonetworks.com)

Start with the public Unit 42 indicators. The published IoCs include several IP addresses, a C2 staging address, URLs for EarthWorm and ReverseSocks5 downloads, an EarthWorm hash, a suspicious user agent string, and file paths such as /var/tmp/linuxap, /var/tmp/linuxda, /var/tmp/linuxupdate, /tmp/.c, /tmp/R5そして /var/R5. (Unit 42)

Use those IoCs carefully. A direct hit is valuable, but the absence of a hit is weak evidence. Attackers can change infrastructure, filenames, paths, and tooling quickly. Unit 42’s stronger lesson is behavioral: tunneling, log cleanup, AD enumeration, suspicious failover, and intermittent operator activity.

A useful SOC hunt should include at least six data sets:

Data set	What to search for	なぜそれが重要なのか
Firewall system logs	Crash cleanup, nginx crash records, unusual restarts, HA role changes	Unit 42 reported crash and nginx evidence deletion
Firewall traffic logs	Outbound connections to unusual VPS or tunnel endpoints	EarthWorm and ReverseSocks5 support pivoting
DNS logs	Lookups or connections to attacker infrastructure	Tunneling often needs staging or controller infrastructure
Directory logs	Firewall service account querying domain root or DomainDnsZones	Unit 42 reported AD enumeration using likely firewall credentials
SIEM forwarded logs	Gaps, resets, missing event sequences, unusual admin activity	Local logs may be deleted
Change management logs	Interface profile changes, Response Pages changes, portal settings changes	Exposure may result from a recent configuration change

A sample KQL query for Microsoft Sentinel-style logs might look like this. Field names will vary by environment.

let suspicious_ips = dynamic([
  "67.206.213.86",
  "136.0.8.48",
  "146.70.100.69",
  "149.104.66.84"
]);
let suspicious_paths = dynamic([
  "/var/tmp/linuxap",
  "/var/tmp/linuxda",
  "/var/tmp/linuxupdate",
  "/tmp/.c",
  "/tmp/R5",
  "/var/R5"
]);
let suspicious_ua = "Safari/532.31 Mozilla/5.5";
union isfuzzy=true
  CommonSecurityLog,
  Syslog,
  DeviceNetworkEvents,
  DeviceFileEvents
| where TimeGenerated > ago(45d)
| where tostring(SourceIP) in (suspicious_ips)
   or tostring(DestinationIP) in (suspicious_ips)
   or tostring(RemoteIP) in (suspicious_ips)
   or tostring(RequestURL) has "146.70.100.69"
   or tostring(FileName) in (suspicious_paths)
   or tostring(ProcessCommandLine) has_any (suspicious_paths)
   or tostring(UserAgent) has suspicious_ua
| project TimeGenerated, Type, DeviceName, SourceIP, DestinationIP, RemoteIP,
          UserName, FileName, ProcessCommandLine, RequestURL, UserAgent, Message
| order by TimeGenerated desc

A Sigma-style rule for forwarded Linux-like telemetry from appliances or supporting collectors can be written as a generic detection. It will require mapping to the organization’s log schema.

title: Possible CVE-2026-0300 Post Exploitation Tooling on Network Edge Device
id: 5d0e9d46-2f37-4e71-b7fd-030020260300
status: experimental
description: Detects file paths and tool names reported in public CVE-2026-0300 post-exploitation activity. Tune for appliance log availability and false positives.
references:
  - Palo Alto Networks Unit 42 threat brief for CVE-2026-0300
author: Security Team
date: 2026-05-09
logsource:
  product: linux
  category: file_event
detection:
  selection_paths:
    TargetFilename|contains:
      - '/var/tmp/linuxap'
      - '/var/tmp/linuxda'
      - '/var/tmp/linuxupdate'
      - '/tmp/.c'
      - '/tmp/R5'
      - '/var/R5'
  selection_tools:
    TargetFilename|contains:
      - 'ReverseSocks5'
      - 'EarthWorm'
      - 'ew_for_linux'
  condition: selection_paths or selection_tools
fields:
  - Image
  - TargetFilename
  - User
  - CommandLine
  - Hostname
falsepositives:
  - Authorized lab testing
  - Incident response staging in a contained environment
level: high

The rule is intentionally conservative. It does not claim to detect exploitation itself. It detects artifacts that public reporting associated with post-exploitation activity. A mature hunt should also look for unknown tunneling binaries, unexplained outbound SOCKS-like behavior, and administrative account use from firewall-associated identities.

Directory and identity review

The Active Directory angle deserves special attention. Unit 42 reported enumeration using credentials likely obtained from the firewall, targeting domain root and DomainDnsZones. (Unit 42)

Security teams should identify every directory, RADIUS, TACACS+, SAML, LDAP, Kerberos, MFA, and User-ID integration connected to the firewall. The goal is not just to rotate a password blindly. The goal is to understand which identities the firewall could use, what privileges they have, where they authenticated, and whether those identities performed abnormal reads or writes during the exposure window.

A practical identity review should ask:

Question	なぜそれが重要なのか
Which service accounts are configured on affected firewalls	Attackers may harvest or abuse stored credentials
Are those accounts domain-wide or scoped narrowly	Overprivileged accounts increase blast radius
Did the accounts authenticate from unusual IPs or hosts	Compromise may move off the firewall
Did the accounts query domain root, DNS zones, groups, or admin objects	Enumeration may precede lateral movement
Do any SAML or MFA logs show floods or anomalous retries	Unit 42 reported a SAML flood in the campaign
Were passwords, tokens, certificates, or keytabs rotated after mitigation	Removing exposure does not invalidate stolen material

A simple KQL-style identity hunt might look like this:

let firewall_accounts = dynamic([
  "svc-pan-userid",
  "svc-firewall-ldap",
  "svc-radius-pan"
]);
SigninLogs
| where TimeGenerated > ago(45d)
| where UserPrincipalName in~ (firewall_accounts)
| summarize count(),
            firstSeen=min(TimeGenerated),
            lastSeen=max(TimeGenerated),
            apps=make_set(AppDisplayName, 20),
            ips=make_set(IPAddress, 50),
            locations=make_set(Location, 20)
          by UserPrincipalName
| order by lastSeen desc

For Windows domain controllers, teams can search for directory service access events from firewall-associated accounts. Event IDs, schema, and log availability vary, but the detection principle is stable: look for abnormal queries, unusual source IPs, and service accounts behaving like discovery tools.

# Run on a secured analysis workstation with exported domain controller logs.
# Adjust account names and paths for your environment.

$FirewallAccounts = @("svc-pan-userid", "svc-firewall-ldap", "svc-radius-pan")
$LogPath = "C:\IR\Exported-DC-Security.evtx"

Get-WinEvent -Path $LogPath |
  Where-Object {
    $msg = $_.Message
    $FirewallAccounts | ForEach-Object { $msg -match $_ }
  } |
  Select-Object TimeCreated, Id, ProviderName, Message |
  Export-Csv C:\IR\firewall-service-account-events.csv -NoTypeInformation

Again, this does not prove CVE-2026-0300 exploitation. It helps answer whether identities connected to the firewall showed suspicious behavior during the relevant window.

Log cleanup and the danger of false negatives

One of the most dangerous parts of the Unit 42 report is not the exploit itself. It is the cleanup. The attackers reportedly cleared crash kernel messages, deleted nginx crash entries and crash records, removed crash core dump files, deleted ptrace injection evidence from the audit log, and deleted a SUID privilege escalation binary. (Unit 42)

That means defenders should treat local log absence with caution. A firewall that has no obvious crash record may be clean, or it may have had the record deleted. The difference often depends on whether logs were forwarded before deletion.

A better model is to compare independent telemetry sources.

信号	Local-only reliability	Better corroboration
Firewall crash records	Weak if attacker had root	SIEM forwarded logs, support bundle timeline, HA peer logs
Nginx crash entries	Weak after cleanup	External monitoring gaps, traffic anomalies
Outbound tunnel connections	ミディアム	NetFlow, DNS logs, proxy logs, cloud firewall logs
AD enumeration	Medium to strong	Domain controller logs, identity provider logs
SAML floods	ミディアム	IdP logs, HA failover logs, authentication failure metrics
Config changes	ミディアム	Panorama audit logs, ticketing records, backup diffs

If the device was exposed and any suspicious behavior exists, involve the vendor or a qualified incident response team. A root-level compromise of a firewall is not the right place for casual cleanup. Depending on evidence, a rebuild or enhanced factory reset may be safer than trusting the existing appliance state.

Patch, then verify the control plane and the data plane

Patching is necessary, but it is not the entire closure condition.

After installing the fixed build, validate the following:

コントロール	Post-patch check
PAN-OS version	Confirm exact hotfix or later fixed build
Authentication Portal	Confirm whether it remains enabled for a justified business reason
Interface Management Profiles	Confirm Response Pages are not enabled on untrusted ingress interfaces
Permitted IPs	Confirm profile access is restricted to trusted internal ranges where possible
Threat Prevention	Confirm content version and Threat ID 510019 status if applicable
HA pair	Confirm both peers are patched and share safe exposure configuration
過去ログ	Confirm forwarding is working after reboot or failover
秘密	Rotate service account credentials, certificates, and tokens if compromise is plausible
External exposure	Re-run non-destructive exposure check from outside the trusted network

Do not close the ticket with “patched” if the same risky exposure remains reachable. A patch removes the known vulnerable code path for CVE-2026-0300, but the architectural weakness remains if sensitive portal or management-like services are reachable from untrusted networks without a strong reason.

The Interface Management Profile documentation is blunt about management exposure: when enabling access to a firewall interface, do not enable management access such as HTTP, HTTPS, SSH, or Telnet from the internet or other untrusted zones, and never enable HTTP or Telnet because they transmit in cleartext. It also notes that if no Interface Management Profile is assigned to an interface, access for all IP addresses, protocols, and services is denied by default. (docs.paloaltonetworks.com)

That default-deny behavior is a useful design principle. Edge devices should expose the minimum service surface needed for their role. Everything else should be explicitly justified.

Related PAN-OS CVEs that explain the pattern

CVE-2026-0300 fits a broader pattern of high-impact PAN-OS vulnerabilities where exploitability depends on a specific feature and exposure path.

CVE-2024-3400 is the closest historical comparison. Palo Alto described it as command injection resulting from arbitrary file creation in the GlobalProtect feature of PAN-OS, affecting specific versions and distinct feature configurations. It could allow an unauthenticated attacker to execute arbitrary code with root privileges on the firewall, while Cloud NGFW, Panorama appliances, and Prisma Access were not impacted. (セキュリティ.paloaltonetworks.com)

The operational lesson from CVE-2024-3400 is not just “patch GlobalProtect.” It is that perimeter features with unauthenticated reachability can become root-level entry points. The affected set was not every Palo Alto deployment. It depended on version, feature configuration, and exposure. That same decision model appears again in CVE-2026-0300.

CVE-2024-0012 shows the management-plane version of the same problem. Palo Alto described it as an authentication bypass in the PAN-OS management web interface that allowed an unauthenticated attacker with network access to gain administrator privileges, perform administrative actions, tamper with configuration, or exploit other authenticated privilege escalation vulnerabilities such as CVE-2024-9474. The vendor stated the risk was greatly reduced by restricting management web interface access to trusted internal IP addresses. (セキュリティ.paloaltonetworks.com)

Those cases create a practical rule: for edge infrastructure, “vulnerable” is a three-part question.

Question	例
Is the affected code present	PAN-OS branch and hotfix state
Is the affected feature enabled	GlobalProtect, management web interface, Authentication Portal
Is the feature reachable from untrusted networks	Internet-facing portal, exposed management interface, unsafe interface profile

The same pattern appears across many edge-device incident cycles: the attacker does not need broad phishing success when a boundary device offers unauthenticated or weakly gated reachability into privileged software.

Hardening recommendations beyond the emergency

Emergency mitigation gets you out of the immediate blast radius. Hardening prevents the next advisory from becoming the next incident.

Start with a dedicated edge-device exposure inventory. Do not rely only on CMDB product names. Track the exact appliance, software branch, hotfix, internet-facing interfaces, interface profiles, management services, authentication services, HA role, logging destination, and service accounts.

Then separate user-facing access from management access. Captive Portal, VPN, GlobalProtect, management UI, API, SSH, SNMP, syslog, authentication backends, and Response Pages should not be treated as one generic “firewall access” bucket. Each has different trust assumptions.

Apply least privilege to service accounts. A firewall account used for LDAP lookup or User-ID mapping should not have broad administrative rights in the domain. If the firewall is compromised, the account should not become a directory discovery skeleton key.

Forward logs off the device. Local logs are useful but insufficient for root-level compromise. Logs should be sent to systems the firewall cannot modify. Retain NetFlow, DNS, authentication, and IdP logs for a window long enough to cover pre-disclosure exploitation.

Check HA symmetry. Many teams patch the active peer first and assume the passive peer follows. Confirm both. Also confirm that failover does not expose a different interface, certificate, NAT path, or Response Pages profile.

Build a rapid CVE playbook for feature-dependent vulnerabilities. The playbook should collect version, feature, exposure, mitigation, threat protection, patch, and post-compromise evidence in one place. For teams using Penligent or a similar authorized AI-assisted security workflow, the useful role is evidence orchestration: collect the advisory facts, map assets, run safe checks, preserve artifacts, and produce a reproducible retest trail. The tool should remain inside explicit authorization boundaries, especially when dealing with live perimeter infrastructure. Penligent’s own site includes an authorized-use disclaimer, which is the correct boundary for this type of work. (寡黙)

Finally, rehearse rebuild and credential rotation. If an edge device is compromised with root privileges, a clean patch may not be enough. Prepare procedures for configuration backup validation, factory reset, trusted image install, certificate replacement, service account rotation, HA rejoin, and post-rebuild exposure testing.

Common mistakes during CVE-2026-0300 response

The first mistake is treating the CVSS score as the full risk statement. CVSS 9.3 communicates severity, but the practical risk depends on exposure. A non-exposed device still needs patching, but it is not the same emergency as an internet-reachable portal on an affected build.

The second mistake is checking only the major version. PAN-OS 11.2 is not enough information. The advisory lists specific maintenance hotfix thresholds such as 11.2.7-h13 and 11.2.10-h6. Version triage must include the full release string. (セキュリティ.paloaltonetworks.com)

The third mistake is disabling Authentication Portal but forgetting Response Pages on untrusted interfaces. Palo Alto’s mitigation explicitly calls out Response Pages in Interface Management Profiles attached to every Layer 3 interface where untrusted or internet traffic can ingress. (セキュリティ.paloaltonetworks.com)

The fourth mistake is trusting a signature alone. Threat ID 510019 is useful where supported, but the advisory notes PAN-OS 11.1 or later decoder support requirements. Signature protection also does not remove the need to patch. (セキュリティ.paloaltonetworks.com)

The fifth mistake is hunting only for the published IoCs. Unit 42’s IoCs are important, but attackers can rotate infrastructure and filenames. The more durable hunt is behavioral: tunneling, outbound proxy behavior, AD enumeration, HA failover manipulation, crash cleanup, and log gaps.

The sixth mistake is checking only the active firewall. HA peer devices, standby appliances, lab clones, cloud VM-Series instances, and forgotten regional appliances may share the same vulnerable configuration.

The seventh mistake is failing to rotate secrets after suspected compromise. If attackers reached root on a firewall that stores or uses service credentials, patching the code path does not invalidate stolen credentials.

A practical 72-hour response plan

The following plan assumes an organization has at least one Palo Alto PA-Series or VM-Series firewall and needs to respond without waiting for every fixed build to become available.

Hour 0 to hour 2

Identify all PA-Series and VM-Series firewalls. Pull exact PAN-OS versions and hotfix levels. Identify which systems have User-ID Authentication Portal enabled. Identify all Interface Management Profiles with Response Pages enabled. Identify all Layer 3 interfaces where those profiles are attached. Determine whether any of those interfaces can receive untrusted or internet traffic.

Immediately disable Authentication Portal where it is not required. Where it is required, restrict access to trusted internal zones and remove Response Pages from profiles attached to untrusted ingress interfaces. Confirm that business-critical user authentication flows still work from trusted networks.

Enable Threat ID 510019 if the organization has Threat Prevention, the correct content version, and PAN-OS compatibility. Treat this as defense in depth, not as closure.

Hour 2 to hour 12

Export configurations and relevant logs. Preserve SIEM, NetFlow, DNS, IdP, directory, and firewall logs for at least the period beginning April 9, 2026, because Unit 42 reported unsuccessful attempts starting that date. (Unit 42)

Search for Unit 42 IoCs and behaviors. Check for outbound connections to suspicious VPS infrastructure, downloaded tunneling tools, unexpected files in /tmp そして /var/tmp, nginx crash anomalies, audit log gaps, suspicious SAML traffic, and HA role transitions.

Review firewall service accounts. Determine whether credentials, tokens, keytabs, or certificates need rotation. If any suspicious activity appears, prioritize rotation and incident response over routine patch planning.

Hour 12 to hour 24

Map every affected system to the vendor patch table. If a fixed version is available, schedule emergency installation. If the fixed version for a specific maintenance path is not yet available, keep mitigations in place and track the vendor’s staged release dates.

Perform non-destructive external exposure checks from an untrusted vantage point. Confirm that the portal path is not reachable from the internet or unauthorized ranges. Do not send malformed exploit payloads.

Brief leadership with precise language: affected devices, exposed devices, mitigated devices, suspected compromise, and patch ETA. Avoid mixing these categories.

Hour 24 to hour 72

Patch available builds. Re-check the same exposure paths after patching. Confirm HA peer parity. Confirm logging after failover tests. Continue threat hunting for delayed lateral movement or identity abuse.

If compromise is suspected, escalate to a full edge-device incident workflow. Consider vendor support, enhanced forensic collection, rebuild, credential rotation, and segmentation review.

Document the final state: exact versions, mitigation changes, evidence collected, logs reviewed, credentials rotated, residual risk, and next review date.

What defenders should watch after May 13 and May 28

The first fixed releases do not end the story. Public advisories often trigger copycat scanning, fake proof-of-concept repositories, opportunistic exploitation attempts, and noisy internet-wide probes. Cvefeed-style aggregation already showed multiple GitHub repositories claiming proof-of-concept or audit tooling shortly after disclosure, but such repositories should be treated cautiously unless validated by trusted researchers or vendors. (cvefeed.io)

After patches land, defenders should watch for three follow-on risks.

First, delayed exploitation against organizations that waited for routine patch windows. Internet-facing edge devices are attractive because attackers can scan at scale and prioritize exposed services.

Second, post-compromise persistence from earlier exploitation. A patched binary does not remove tunnels, stolen credentials, altered configuration, or downstream identity abuse.

Third, confusion between fixed and mitigated states. A device may be patched but still expose unnecessary portal behavior. Another device may be mitigated but still unpatched. Both states need tracking.

The clean end state is patched, not exposed unnecessarily, reviewed for compromise, logging externally, credentials validated or rotated, and HA peers checked.

Reference links and further reading

Palo Alto Networks official advisory for CVE-2026-0300, the primary source for affected versions, exposure conditions, mitigations, and Threat ID guidance. (セキュリティ.paloaltonetworks.com)

NVD entry for CVE-2026-0300, including the CVE description, CVSS information from the CNA, CISA KEV metadata, and change history. (nvd.nist.gov)

CISA Known Exploited Vulnerabilities catalog entry as represented in NVD’s CVE detail page, including the May 6, 2026 addition date and May 9, 2026 due date. (nvd.nist.gov)

Unit 42 threat brief on exploitation of the PAN-OS Captive Portal zero-day, including CL-STA-1132 activity, shellcode injection into an nginx worker process, log cleanup, tunneling tools, AD enumeration, SAML flood behavior, and IoCs. (Unit 42)

Rapid7 emergency threat response post for a concise affected-version matrix, mitigation summary, and external context on patch timing. (ラピッド7)

Palo Alto Networks Authentication Portal configuration documentation, useful for understanding Response Pages, User-ID, Redirect mode, and interface profile dependencies. (docs.paloaltonetworks.com)

Palo Alto Networks Interface Management Profile documentation, useful for understanding Response Pages, permitted services, default-deny behavior when no profile is assigned, and the warning against enabling management access from untrusted zones. (docs.paloaltonetworks.com)

Palo Alto Networks advisory for CVE-2024-3400, a related PAN-OS GlobalProtect root RCE case that shows why feature configuration and exposure are central to edge-device vulnerability response. (セキュリティ.paloaltonetworks.com)

Palo Alto Networks advisory for CVE-2024-0012, a related PAN-OS management web interface authentication bypass that reinforces the importance of restricting sensitive interfaces to trusted internal IP addresses. (セキュリティ.paloaltonetworks.com)

Penligent related reading on PAN-OS and AI-assisted validation workflows, including its CVE-2026-0227 PAN-OS GlobalProtect article, its article on shrinking patch windows, and its discussion of white-box audits and black-box proof. (寡黙)

Penligent homepage for authorized AI-assisted pentesting workflows, CVE scanning, verification, evidence-first results, and controlled agentic workflows for security engineers, pentesters, and red teams. (寡黙)