So much for 'Medium' severity: Hunting CVE-2026-0257 VPN Bypasses
Hey everyone,
Just saw the alert drop regarding CVE-2026-0257. While Palo Alto classified this as medium severity (CVSS 7.8), the fact that it's an authentication bypass for GlobalProtect and is currently under active exploitation changes the risk profile significantly. Essentially, bad actors can establish VPN tunnels without valid credentials.
For those managing PAN-OS or Prisma Access who can't patch immediately, we need to focus on detection. Since the flaw bypasses the standard auth layer, you might see successful tunnel setups in your traffic logs without a corresponding successful login event immediately preceding them. I'm currently correlating GlobalProtect traffic logs against authentication logs to hunt for these orphaned sessions.
Here is a basic KQL query I'm using to look for discrepancies in Sentinel:
PaloAltoNetworksCL
| where log_source =~ "TRAFFIC"
| where app =~ "globalprotect"
| where action =~ "accept"
| project TimeGenerated, src_ip, dst_ip, user
| join kind=leftanti (
SigninLogs
| where AppDisplayName contains "GlobalProtect"
| where Result == "Success"
| project user, TimeGenerated
) on user
Is anyone seeing specific IOCs associated with this active exploitation yet, or just mass scanning attempts?
We noticed a drop in standard brute-force attempts yesterday, replaced by connection attempts against non-existent accounts. It felt off because the logs showed 'tunnel established' but no MFA prompt was ever triggered. We ended up implementing a temporary deny-list on untrusted GeoIPs as a stopgap while we schedule the maintenance window.
Good call on the correlation logic. For those running Suricata or Zeek, keep an eye out for SSL/TLS sessions to the GlobalProtect portal that don't follow the standard cipher suite negotiation or have mismatched certificate fingerprints. You can filter for this in Zeek with:
zeek -r capture.pcap 'ssl::log' | grep 'GlobalProtect'
If you see established connections without the client hello extensions specific to Palo Alto clients, flag it.
I'm currently testing this in a lab environment. It seems the bypass relies on a specific race condition during the SAML assertion. If you have 'SAML Strict Mode' enabled on your GlobalProtect gateway configuration, the vulnerability seems to fail validation because the malformed session cookie gets rejected. Can anyone else confirm if Strict SAML enforcement effectively blocks this CVE?
Building on Amy’s point about the logs, if you’re using Splunk, you should specifically hunt for successful tunnel-up events where the user field is null. Since this CVE bypasses authentication, the session starts but the user context is missing.
Here’s a quick hunt query to isolate those sessions:
splunk index=pan_logs log_subtype="globalprotect" action="tunnel-up"
| where isnull(user) OR user=""
| stats count by src_ip, gateway
If you see high volume from specific IPs, you might be seeing exploitation attempts rather than just configuration noise.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access