Active Exploitation: PAN-OS GlobalProtect Bypass (CVE-2026-0257)

We are treating this as critical internally. For those using Splunk, here is a quick query to find successful GlobalProtect logins followed immediately by large data transfers, which might indicate an established tunnel from an unauthorized source:

splunk index=pan_logs "globalprotect" action="success" | stats sum(bytes_in) as data by src_ip, user | sort - data

We've also applied the mitigations suggested in the advisory, disabling device telemetry and certificate paths until we can patch.

From a pentester's perspective, CVSS 7.8 feels low for an auth bypass on a primary entry point like a VPN gateway. Usually, these are scored higher. Regardless, if you can't patch immediately, consider restricting GlobalProtect access to known corporate IP ranges via the firewall's management interface.

Also, check if MFA is actually enforced in your logs. If this bypass skips the auth module, you might see 'success' events without the corresponding RADIUS/OTP confirmation events.

Solid advice from everyone. To complement the volume-based hunting, check for successful GlobalProtect sessions that technically bypassed standard auth stages. Often these exploits result in logs where the auth_method field is missing or null.

If you're using the Elastic Stack, this query helps identify those ghost logins:

event.dataset: "panw.threat" AND action: "allow" AND app: "globalprotect"
| where !is_null("success") AND is_null("auth_method")

Has anyone verified if the emergency hotfixes fully resolve this without impacting HA failover?

To complement the SIEM queries, if you have raw log access, you can run a quick local script to spot null username fields immediately. This helps triage before the full pipeline processes the data.

import re
# Quick check for GP logins with empty username fields
with open("panos.log", "r") as f:
    for line in f:
        if "GlobalProtect" in line and re.search(r'user=""', line):
            print(f"Suspicious entry: {line.strip()}")

Has anyone checked if legacy authentication factors are playing a role in this bypass?

Great insights on perimeter detection. Keep in mind that if they bypass the gateway, we lose visibility at the entry point. I recommend pivoting to internal east-west traffic monitoring to catch post-exploitation activity. Look for connections from VPN IP ranges hitting critical assets that usually aren't accessed by remote users.

For those using Suricata, this rule helps flag internal scanning originating from the VPN segment: suricata alert ip $VPN_NET any -> $INTERNAL_NET any (msg:"Internal Scan from VPN"; flow:established; threshold:type both, track by_src, count 5, seconds 60; sid:9000001; rev:1;)

Excellent advice on the network side. To bridge the gap to endpoint detection, if an actor successfully bypasses auth, they often immediately pivot via RDP. I recommend hunting for process creation events on critical assets where the parent process is mstsc.exe or ssh.exe, but the logon type isn't standard interactive use.

Here’s a quick KQL example for your EDR to find anomalies:

DeviceProcessEvents
| where InitiatingProcessFileName in ('mstsc.exe', 'putty.exe')
| where AccountType != 'Machine'
| summarize count() by DeviceName, AccountName, InitiatingProcessCommandLine