CVE-2024-3400: GlobalProtect zero-day gives root with a crafted session cookie

What it is

GlobalProtect didn’t validate the value of a session cookie before using it as a file name. A value containing ../ let an unauthenticated attacker create a file with any name in any directory. A background job later handled such file names in a shell command, so a crafted name became a command running as root.

The result was unauthenticated remote code execution on any firewall with a GlobalProtect portal or gateway, which describes most firewalls that offer remote access VPN. Palo Alto scored it the maximum CVSS 10.

Volexity caught the first attacker, which it tracks as UTA0218 and believes to be state-backed, on 10 April 2024. The earliest activity dated back to 26 March. Once proofs of concept were published on 16 April, many other groups joined in.

Am I affected?

Only firewalls running PAN-OS 10.2, 11.0 or 11.1 with a GlobalProtect portal or gateway configured. Check Network > GlobalProtect > Portals and Gateways. Device telemetry doesn’t matter: early guidance suggested it did, but that was withdrawn.

Older branches (10.1 and below), Panorama, Cloud NGFW and Prisma Access are not affected.

Since this is a 2024 bug, the real question today is whether a firewall that stayed unpatched through April 2024 was ever cleaned. Devices that were compromised and only patched may still carry attacker access or stolen secrets.

What to do

1. Make sure every firewall is on a fixed version. Any firewall still on 11.0 or another end-of-life branch should move to a supported release; fixes for later bugs, such as CVE-2026-0257, won’t come to it.

2. Check for past exploitation attempts with this CLI command from the advisory:

grep pattern "failed to unmarshal session(.\+.\/" mp-log gpsvc.log*

Normal lines show a GUID between the parentheses. A file path or shell command there (for example failed to unmarshal session(../../some/path)) means someone tried to exploit the device. Collect a tech support file before upgrading, since logs from the old installation become unreadable after the upgrade.

3. If the device was compromised, rebuild it. Palo Alto’s current guidance:

• Hardware (PA-Series): an Enhanced Factory Reset scheduled with support, because researchers showed persistence that survives a normal reset and upgrade.
• Virtual (VM-Series): deploy a fresh instance, and keep the old one shut down for forensics.
• In both cases, review the exported configuration for changes, change the master key, reset all passwords and keys, and reissue certificates.

4. Investigate the network behind it. In Volexity’s cases, the attackers used the firewall’s own highly privileged service account to move into the network over SMB and WinRM. They stole the Active Directory database (ntds.dit), DPAPI keys and saved browser credentials.

Detection

• The gpsvc.log check above, using a tech support file collected before any upgrade.
• Unusual traffic from the firewall itself: wget downloads straight to an IP address, requests to worldtimeapi.org, connections on port 8443 to unknown hosts, or SMB, RDP and WinRM sessions from the firewall to internal servers.
• Use of the firewall’s service accounts on internal systems.
• The file paths below, which need Palo Alto support or a tech support file review to check.