CVE-2024-5921 is an insufficient certificate validation flaw in the Palo Alto Networks GlobalProtect app. NVD scores it 8.8 (High) and the vendor 5.6 (Medium). Fixed releases include 6.3.2 and 6.2.6, but updating alone is not enough: strict certificate checking must also be configured.
What's affected
The record says an attacker can make the app connect to arbitrary servers, and that a local non-administrator user or an attacker on the same subnet could install malicious root certificates and then deliver software signed by them. The weakness is CWE-295, improper certificate validation. The NVD vector is adjacent network, no privileges, no user interaction.
Per the vendor advisory:
- 6.3: Windows and macOS before 6.3.2 affected, fixed in 6.3.2
- 6.2: Windows before 6.2.6, macOS before 6.2.6-c857, Linux before 6.2.1-c31 and Windows UWP before 6.2.6 affected. The UWP fix was still pending at the time of the advisory
- 6.1: all Windows, macOS and Linux versions listed as affected with no fix. Android before 6.1.6 and iOS before 6.1.7 affected
- 6.0: Windows before 6.0.12 affected, fixed in 6.0.12. macOS listed as affected with no fix
- No affected versions are listed when the app runs in FIPS-CC mode
Severity conflict. NVD gives 8.8 High. The vendor gives CVSS 4.0 base-threat 5.6 Medium with an adjacent attack vector. The advisory notes a public conference talk, blog posts and a proof of concept, with exploit maturity rated POC. It states that Palo Alto Networks is not aware of malicious exploitation, and the record does not mark the CVE as known exploited.
How to check if you're exposed
Check the GlobalProtect version and platform on each endpoint against the list. Then check configuration, because the advisory says an update is not sufficient by itself.
Confirm that the portal TLS chain meets the vendor criteria, that the chain is in the operating system root store, and that the strict verification option named full-chain-cert-verify is set to yes. Newer app releases (6.2.8 and 6.3.3 and later on Windows and macOS) add an Enable Strict Certificate Check setting, which takes effect only after the first connection.
What to do now
- Upgrade to a fixed release for your branch and platform.
- Make sure portal certificate chains meet the vendor criteria and are in the OS root store.
- Set full-chain-cert-verify to yes, or enable the Strict Certificate Check setting on versions that have it, and apply the registry or plist changes on earlier versions as the advisory describes.
- For 6.0 or 5.1 deployments that cannot move, the vendor describes running the app in FIPS-CC mode as a workaround.
- Do not rely on setting Allow User to Change Portal Address to No. The vendor says that is not a valid workaround.
Why it matters
VPN clients are trust anchors. They decide which servers to believe and often run with high privileges. If the client accepts a server it should reject, the client can be steered into installing certificates and software the attacker controls.
The adjacent attack vector explains the gap between the two scores: an attacker has to share the network or be a local user. Public proof of concept code exists, so assume capable attackers understand the weakness and finish the configuration steps, not just the upgrade.
Quick check
Why is an upgrade not enough?
The vendor says strict certificate verification and portal certificate chain requirements must also be configured for the protection to apply.
Is a proof of concept public?
The vendor advisory says a conference talk, blog posts and a proof of concept exist. It also says it is not aware of malicious exploitation.
Sources
- Palo Alto Networks advisory for CVE-2024-5921
- NVD record for CVE-2024-5921
- Gold entry
Last reviewed: 19 October 2026.
