CVE-2024-3400 is a critical command injection flaw in the GlobalProtect feature of Palo Alto Networks PAN-OS 10.2, 11.0 and 11.1 that lets an unauthenticated attacker run code as root on the firewall. Fix it by installing the fixed hotfix for your branch (such as 10.2.9-h1, 11.0.4-h1 or 11.1.2-h3 or later), then check the device for compromise.
Only firewalls with a GlobalProtect portal or gateway configured are exposed. Turning off device telemetry, an early suggested workaround, is no longer considered a mitigation.
What the scanner is actually detecting
In Nessus the finding is titled Palo Alto Networks PAN-OS CVE-2024-3400, plugin ID 193255, in the Palo Alto Local Security Checks family. The plugin compares the PAN-OS version Nessus collected from the firewall against the affected ranges. Tenable’s description states that Nessus has not tested for the issue and relies only on the self-reported version number.
Two details matter when you read a Nessus 193255 result:
- It is a paranoid check. The plugin requires the Settings/ParanoidReport item, so it only reports when the scan policy’s report paranoia is set to Paranoid. That is Tenable’s signal that the version alone cannot prove exposure.
- It does not confirm GlobalProtect. The vulnerability needs a GlobalProtect portal or gateway, and the plugin does not verify that one is configured. It also does not know whether Threat Prevention signatures are blocking the attack.
The affected and fixed versions, per the Palo Alto Networks advisory:
| Branch | Fixed hotfixes (install the one for your maintenance release, or any later version) |
|---|---|
| PAN-OS 11.1 | 11.1.0-h3, 11.1.1-h1, 11.1.2-h3 |
| PAN-OS 11.0 | 11.0.0-h3, 11.0.1-h4, 11.0.2-h4, 11.0.3-h10, 11.0.4-h1 |
| PAN-OS 10.2 | 10.2.0-h3, 10.2.1-h2, 10.2.2-h5, 10.2.3-h13, 10.2.4-h16, 10.2.5-h6, 10.2.6-h3, 10.2.7-h8, 10.2.8-h3, 10.2.9-h1 |
| PAN-OS 10.1, 10.0, 9.1, 9.0 | Not affected |
Cloud NGFW, Panorama appliances and Prisma Access are not affected.
Real-world risk
This one deserves its critical rating. Palo Alto Networks scores it 10.0: network attack, low complexity, no authentication. It was exploited as a zero-day before the advisory appeared on April 12, 2024; Volexity reported the in-the-wild attacks and Unit 42 tracked the activity as Operation MidnightEclipse. CISA added it to the Known Exploited Vulnerabilities catalog with a due date of April 19, 2024 (see our explainer on the CISA KEV catalog for what that listing means for your patch deadlines). Public proofs of concept exist, and Tenable lists Metasploit and Core Impact modules.
For balance: Unit 42 reported that most cases it handled were unsuccessful attempts or low-level tests, with very few showing interactive attacker access. The advisory also notes that persistence techniques that survive reboots and upgrades have been publicly described. That is why patching alone is not the end of the job if the device was already probed. A firewall running an affected version with GlobalProtect enabled on an internet-facing interface should be treated as an emergency.
How to confirm it on the host
Log in to the firewall CLI over SSH and check the software and content versions. Look at the sw-version and app-version fields:
show system infoNext, check whether GlobalProtect is configured. In the web interface, open Network > GlobalProtect > Portals and Network > GlobalProtect > Gateways. If both lists are empty, the device is not exposed to this CVE.
Check for CVE-2024-3400 indicators of compromise
Palo Alto provides this command, run from the PAN-OS CLI, to look for exploit attempts in the GlobalProtect service log:
grep pattern "failed to unmarshal session(.+./" mp-log gpsvc.log*Normal entries contain a session GUID, such as failed to unmarshal session(01234567-89ab-cdef-1234-567890abcdef). An entry with a path in it, such as failed to unmarshal session(../../some/path), indicates an attempted exploit. You can also open a case in the Palo Alto Customer Support Portal and upload a tech support file (TSF) to have its logs compared against known exploit attempts. Collect the TSF (Device > Support > Generate Tech Support File) before you reboot into a fixed version, because some logs from the previous installation become inaccessible after the upgrade.
How to fix it
Install the fixed PAN-OS hotfix
This is the only real fix. In the web interface: export a copy of the running configuration, update content under Device > Dynamic Updates, then go to Device > Software, click Check Now, download the hotfix for your maintenance release, install it and reboot. If Panorama manages the firewalls, you can deploy software from Panorama instead. The equivalent CLI sequence, using the PAN-OS hotfix 11.1.2-h3 as the example:
request content upgrade check
request content upgrade download latest
request content upgrade install version latest
request system software check
request system software download version 11.1.2-h3
show jobs id <job-id>
request system software install version 11.1.2-h3
request restart systemThe installed version only takes effect after the restart. A hotfix on your current maintenance release does not need a base image; moving to a different feature release (for example 11.0 to 11.1) does, so follow the PAN-OS upgrade guide for that path. PAN-OS 11.0 reached end of life on November 17, 2024, and 10.2 is past its standard support end date, so plan a move to a supported release after the emergency hotfix.
Interim protection: Threat Prevention signatures
If you cannot reboot right away, customers with a Threat Prevention subscription can block the attack with Threat IDs 95187, 95189 and 95191, available in Applications and Threats content version 8836-8695 and later. The signatures only help if vulnerability protection is applied to traffic reaching the GlobalProtect interface. Palo Alto’s guidance is a security rule under Policies > Security with source zone any, destination zone set to the zone of the GlobalProtect portal or gateway interface, and a Vulnerability Protection profile attached that blocks these threat IDs. Commit, then test from an outside host against your own firewall:
curl -v -k -H "Cookie: SESSID=/../TESTVULN" https://<your-firewall>/global-protect/login.espA protected firewall returns no response (the connection is reset). A successful HTTP response means the signatures are not applied correctly. This is a stopgap for days, not weeks. For how to handle a KEV entry while the real fix waits, see what to do when a KEV vulnerability has no patch yet.
If the device was compromised
Unit 42 sorted compromise into four levels. The recommended response for each, as summarized by CERT-EU:
| Level | What was observed | Response |
|---|---|---|
| 0: Probe | Unsuccessful exploit attempt | Update to the latest hotfix |
| 1: Test | A 0-byte file was created on the firewall | Update to the latest hotfix |
| 2: Potential exfiltration | A file (typically the running configuration) was copied to a web-accessible location | Incident response, update, then a Private Data Reset |
| 3: Interactive access | Shell commands, backdoors or downloaded files | Incident response, update, then a Factory Reset |
An Enhanced Factory Reset, which does not depend on the integrity of the possibly compromised device, can be scheduled through Palo Alto TAC. Virtual firewalls are replaced with a new instance. After restoring, Palo Alto’s remediation article says to review the backed-up configuration for unauthorized changes, change the master key and use AES-256-GCM for system secrets, reset all passwords, pre-shared keys, private keys and secrets, and revoke and reissue all certificates with private keys on the device.
How to verify the fix and rescan
- Run show system info and confirm sw-version shows a fixed hotfix for your branch.
- Re-run the gpsvc.log grep over the following days. New attempts against a patched device are expected; they are not a sign the fix failed.
- Rescan with the same Nessus policy and credentials (Paranoid report setting included) so plugin 193255 runs against the new version string and closes.
- Check your other GlobalProtect firewalls. Scanning only the ones in your asset list misses forgotten portals; our guide to external attack surface management scope covers how to find them.
What can break and how to roll back
Installing a PAN-OS hotfix requires a reboot, which drops traffic through a standalone firewall and disconnects GlobalProtect users. On an HA pair, follow Palo Alto’s HA upgrade procedure and upgrade one peer at a time. Hotfixes on the same maintenance release rarely change behavior, but read the release notes for known issues.
To roll back, install the previous PAN-OS version from Device > Software and reboot, then restore the configuration you exported. Rolling back reinstates the vulnerability, so keep the Threat Prevention signatures in place if you do. A Vulnerability Protection profile newly attached to GlobalProtect traffic can also block other signatures; check the threat log (Monitor > Logs > Threat) if users report connection failures, and add exceptions per threat ID rather than removing the profile.
Common false positive reasons
- No GlobalProtect portal or gateway. The advisory limits the issue to firewalls with GlobalProtect configured. If both configuration lists are empty, record a screenshot as evidence and schedule the upgrade at normal priority.
- Stale version data. The plugin reads the version collected during the scan. A result from a scan that ran before the hotfix will not reflect it until you rescan.
- Unaffected platform or branch. PAN-OS 10.1 and earlier, Panorama, Cloud NGFW and Prisma Access are not affected. Check which asset and version the plugin output names.
Two situations look like false positives but are not: a firewall protected only by Threat Prevention signatures (mitigated, still vulnerable) and a firewall with telemetry disabled (telemetry is not required for exposure).
FAQ
Does disabling device telemetry fix CVE-2024-3400?
No. Palo Alto updated the advisory to say telemetry does not need to be enabled for a firewall to be exposed, so disabling it is not an effective mitigation.
Which hotfix do I need?
The fixed hotfix for your current maintenance release, for example 10.2.9-h1 on 10.2.9, 11.0.4-h1 on 11.0.4 or 11.1.2-h3 on 11.1.2, or any later version.
Is Panorama affected?
No. Panorama appliances, Cloud NGFW and Prisma Access are not affected. Firewalls that Panorama manages still need the hotfix if they run an affected version with GlobalProtect.
Does upgrading remove an attacker who already got in?
Not reliably. Persistence that survives upgrades has been described publicly, so a device showing Level 2 or 3 activity needs a reset and credential rotation, not just the hotfix.
Tracking this finding across many hosts
Across several firewalls, the work is separating devices that really run GlobalProtect from version-only hits and proving each one was patched. If you use SITEY, you upload the .nessus export, AI triage suggests likely false positives with supporting evidence while a person makes the final call, and a per-finding Nessus retest confirms closure after the hotfix. SITEY agents run on Windows and Linux endpoints, so the firewall upgrade itself remains a change you make on the device.