This is a spare key hidden under the front-door mat of your VPN perimeter
CVE-2024-3400 is an unauthenticated command-injection chain in Palo Alto PAN-OS GlobalProtect. In practice, the bug lets an attacker use the GlobalProtect web surface to create a file in a controlled path and turn that into root-level command execution on the firewall. The exposed population is narrower than the headline implies: it applies to PAN-OS 10.2, 11.0, and 11.1 only, and only when a GlobalProtect gateway or portal is configured. Palo Alto’s final advisory also clarified that **device telemetry is *not* required** for exposure.
The vendor’s 10.0 / CRITICAL rating is basically fair in the environments that matter. Yes, there is real friction because this is not every PAN-OS box on earth; it requires a specific feature set and version family. But the vulnerable asset is often an internet-facing security gateway, exploitation was observed in the wild before broad patch adoption, and post-exploitation lands on the firewall itself, which is a terrible place to lose control of. That combination keeps this firmly CRITICAL.
4 steps from start to impact.
Find an exposed GlobalProtect edge
curl/Burp validation.- Target is internet-reachable
- Target runs PAN-OS 10.2, 11.0, or 11.1
- GlobalProtect portal or gateway is configured
- Non-GlobalProtect firewalls are out of scope
- Internal-only VPN portals materially reduce attacker reach
- Version family is limited; PAN-OS 9.x, 10.0, 10.1, Cloud NGFW, Panorama, and Prisma Access are not affected
Abuse hipreport.esp for arbitrary file creation
/ssl-vpn/hipreport.esp using a malicious SESSID cookie. Public write-ups and GitHub PoCs show this as a path-traversal-style primitive that creates attacker-controlled files in web-accessible or processing-sensitive locations. WatchTowr-inspired checks and later GitHub PoCs made this step easy to reproduce for defenders and attackers alike.- Unauthenticated HTTPS access to the GlobalProtect web surface
- Vulnerable PAN-OS branch/hotfix level
- Request reaches the firewall without upstream blocking
- Threat Prevention signatures on the GlobalProtect interface can break the exploit path
- Reverse proxies or IP restrictions may reduce reachable population
- Some public PoCs only validate the file-write stage, not full RCE
hipreport.esp; external checks often detect the file-write primitive, but they do not confirm whether persistence or later stages succeeded.Convert file creation into root command execution
- Successful file-write primitive
- Target remains unpatched and unblocked
- Affected processing path is present in the running build
- Hotfixes fully block the initial remote command execution path
- Exploit reliability can vary by exact maintenance release
- Some organizations moved quickly because the asset class is high-value and already monitored
Persist and pivot from the firewall
- Initial RCE succeeded
- Attacker maintains outbound connectivity or staging access
- No immediate containment or rebuild occurred
- Rapid admin response can limit dwell time
- Full reimage / enhanced factory reset destroys many persistence paths
- The vast majority of observed cases discussed by Unit 42 were unsuccessful attempts rather than durable compromises
The supporting signals.
| In-the-wild status | Confirmed exploited. Volexity reported active exploitation; Palo Alto/Unit 42 tracked the activity as Operation MidnightEclipse. |
|---|---|
| KEV status | CISA KEV-listed on 2024-04-12 with a federal due date of 2024-04-19. |
| Proof-of-concept availability | Public PoCs exist. GitHub repos such as ihebski/CVE-2024-3400 and related projects reproduced the file-write / RCE checks after disclosure, with attribution back to WatchTowr Labs research. |
| EPSS | 0.94323 from the supplied intel block, which is consistent with an extremely high exploitation likelihood; third-party mirrors place it around the 99.9th+ percentile. |
| CVSS meaning | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H is the full nightmare path: remote, no auth, no user action, with total CIA impact and scope change because compromise of the firewall affects trust boundaries around it. |
| Affected versions | PAN-OS 10.2, 11.0, and 11.1 only, and only when GlobalProtect portal or gateway is configured. Palo Alto later clarified that device telemetry is not required. |
| Fixed versions | Base fixed releases are 10.2.9-h1, 11.0.4-h1, and 11.1.2-h3, plus backported hotfixes for several earlier maintenance releases in those trains. |
| Exposure data | Shadowserver reported 6,634 vulnerable GlobalProtect instances in April 2024. Recorded Future cited over 156,000 internet-exposed PAN-OS devices broadly, which matters because the vulnerable feature commonly lives on the perimeter. |
| Disclosure timeline | Publicly disclosed on 2024-04-12 after Palo Alto learned from Volexity on 2024-04-10; Volexity observed the earliest known exploitation on 2024-03-26. |
| Reporting / research | Initial external reporting came from Volexity; Palo Alto PSIRT and Unit 42 handled vendor analysis, hotfixes, IOC guidance, and post-exploitation tracking. |
noisgate verdict.
The decisive factor is not the theoretical CVSS math; it is that this is an unauthenticated internet-edge firewall RCE with confirmed exploitation. The only real downward pressure is configuration scoping to specific PAN-OS trains with GlobalProtect enabled, but that friction is not enough to pull a live-exploited perimeter root compromise out of the CRITICAL bucket.
Why this verdict
- KEV + active exploitation erase most debate: this was abused in the wild before routine patching, so the risk is proven, not hypothetical.
- Attacker position is as bad as it gets: unauthenticated remote access over the internet to a perimeter VPN/firewall means no phishing, no credential theft, and no pre-existing foothold is required.
- The blast radius is larger than one host: compromise lands on a security gateway that brokers remote access and sits in a privileged network position, so one exploit can expose credentials, traffic paths, and internal pivot opportunities.
- Real-world friction exists but is narrow: the attack only applies to PAN-OS 10.2/11.0/11.1 with GlobalProtect portal/gateway configured, which trims the exposed population but still leaves a large, high-value footprint.
- Defensive tooling is weaker on appliances: many organizations lack true EDR on firewalls, so post-exploitation visibility is poorer than on a normal server.
Why not higher?
There is not much room above this. The only reason this is 9.8 instead of a dogmatic 10.0 is that not every PAN-OS deployment is reachable or configured for GlobalProtect, and unaffected trains/products remove a meaningful chunk of the installed base. That scoping matters, but only slightly.
Why not lower?
A downgrade would require meaningful attacker friction such as authentication, internal-network access, or a niche-only exposed population. None of that applies here. This is an internet-edge, no-auth root RCE on a security appliance with public exploitation evidence and KEV status.
What to do — in priority order.
- Upgrade PAN-OS now — Move affected firewalls to a fixed release or the applicable hotfix immediately, within hours because this CVE is KEV-listed and actively exploited. This is the only control that cleanly removes the initial RCE path.
- Enable Threat Prevention signatures on GlobalProtect — Apply Palo Alto Threat IDs 95187, 95189, and 95191 to the GlobalProtect interface immediately, within hours, if subscription coverage exists. This is the fastest vendor-supported temporary brake while emergency upgrades are underway.
- Reduce internet reachability — Restrict GlobalProtect exposure by source IP, upstream ACL, or temporary service disablement immediately, within hours for high-risk or slow-to-patch assets. This directly attacks the exploit’s biggest amplifier: unauthenticated internet reachability.
- Run IOC and integrity review — Pull TSF, review Palo Alto and Unit 42 IOC guidance, and treat suspicious systems as potential firewall compromises immediately, within hours. If there is evidence of exploitation or you missed the vendor’s cleanup thresholds, plan for vendor-guided reset/rebuild rather than trusting an in-place upgrade alone.
- Disabling device telemetry does not work; Palo Alto updated the advisory and explicitly said telemetry is not required for exposure.
- Generic EDR assumptions do not help much; most firewalls do not have full endpoint-style telemetry, so you cannot count on normal host controls to catch post-exploitation.
- Patching Panorama, Prisma Access, or unaffected PAN-OS trains does nothing for this issue because those products/versions are not in scope.
Crowdsourced verification payload.
Run this from an auditor workstation that can reach the firewall management or API interface over HTTPS. Invoke it as ./check-cve-2024-3400.sh fw.example.com APIKEY using an administrator API key; no shell access to the firewall is required. The script classifies a device as PATCHED if it is on a fixed/hotfixed version or if no GlobalProtect portal/gateway config is found, VULNERABLE if the version is affected and GlobalProtect is configured, and UNKNOWN if the API data cannot be retrieved or parsed.
#!/usr/bin/env bash
# check-cve-2024-3400.sh
# Determine likely exposure to CVE-2024-3400 on a Palo Alto PAN-OS firewall.
# Usage: ./check-cve-2024-3400.sh <host> <api_key>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
HOST="${1:-}"
APIKEY="${2:-}"
if [[ -z "$HOST" || -z "$APIKEY" ]]; then
echo "UNKNOWN - usage: $0 <host> <api_key>"
exit 2
fi
fetch_api() {
local type="$1"
local payload_key="$2"
local payload_val="$3"
curl -sk --connect-timeout 10 --max-time 20 \
--data-urlencode "type=${type}" \
--data-urlencode "key=${APIKEY}" \
--data-urlencode "${payload_key}=${payload_val}" \
"https://${HOST}/api/"
}
extract_tag() {
local tag="$1"
sed -n "s:.*<${tag}>\([^<]*\)</${tag}>.*:\1:p" | head -n1
}
version_tuple() {
# Convert PAN-OS version like 11.1.2-h3 into four integers: major minor maint hotfix
local v="$1"
if [[ "$v" =~ ^([0-9]+)\.([0-9]+)\.([0-9]+)(-h([0-9]+))?$ ]]; then
local a="${BASH_REMATCH[1]}"
local b="${BASH_REMATCH[2]}"
local c="${BASH_REMATCH[3]}"
local d="${BASH_REMATCH[5]:-0}"
echo "$a $b $c $d"
return 0
fi
return 1
}
is_at_least() {
# Usage: is_at_least current target
local cur target
cur=( $(version_tuple "$1") ) || return 1
target=( $(version_tuple "$2") ) || return 1
local i
for i in 0 1 2 3; do
if (( cur[i] > target[i] )); then return 0; fi
if (( cur[i] < target[i] )); then return 1; fi
done
return 0
}
is_patched_version() {
local v="$1"
local t
t=( $(version_tuple "$v") ) || return 2
local major="${t[0]}"
local minor="${t[1]}"
local maint="${t[2]}"
# PAN-OS 10.2 hotfix matrix from vendor advisory
if [[ "$major.$minor" == "10.2" ]]; then
case "$maint" in
0) is_at_least "$v" "10.2.0-h3"; return $? ;;
1) is_at_least "$v" "10.2.1-h2"; return $? ;;
2) is_at_least "$v" "10.2.2-h5"; return $? ;;
3) is_at_least "$v" "10.2.3-h13"; return $? ;;
4) is_at_least "$v" "10.2.4-h16"; return $? ;;
5) is_at_least "$v" "10.2.5-h6"; return $? ;;
6) is_at_least "$v" "10.2.6-h3"; return $? ;;
7) is_at_least "$v" "10.2.7-h8"; return $? ;;
8) is_at_least "$v" "10.2.8-h3"; return $? ;;
*) is_at_least "$v" "10.2.9-h1"; return $? ;;
esac
fi
# PAN-OS 11.0 hotfix matrix from vendor advisory
if [[ "$major.$minor" == "11.0" ]]; then
case "$maint" in
0) is_at_least "$v" "11.0.0-h3"; return $? ;;
1) is_at_least "$v" "11.0.1-h4"; return $? ;;
2) is_at_least "$v" "11.0.2-h4"; return $? ;;
3) is_at_least "$v" "11.0.3-h10"; return $? ;;
*) is_at_least "$v" "11.0.4-h1"; return $? ;;
esac
fi
# PAN-OS 11.1 hotfix matrix from vendor advisory
if [[ "$major.$minor" == "11.1" ]]; then
case "$maint" in
0) is_at_least "$v" "11.1.0-h3"; return $? ;;
1) is_at_least "$v" "11.1.1-h1"; return $? ;;
*) is_at_least "$v" "11.1.2-h3"; return $? ;;
esac
fi
# Unaffected trains/products for this CVE
if [[ "$major.$minor" == "9.0" || "$major.$minor" == "9.1" || "$major.$minor" == "10.0" || "$major.$minor" == "10.1" ]]; then
return 0
fi
# Later major/minor trains not listed as affected in the vendor advisory
if (( major > 11 )) || { (( major == 11 )) && (( minor > 1 )); }; then
return 0
fi
# Could not classify
return 2
}
SYSINFO_XML="$(fetch_api op cmd '<show><system><info></info></system></show>')"
if [[ -z "$SYSINFO_XML" ]] || ! echo "$SYSINFO_XML" | grep -q '<response status="success">'; then
echo "UNKNOWN - failed to retrieve system info from API"
exit 2
fi
SWVER="$(echo "$SYSINFO_XML" | tr -d '\n' | extract_tag sw-version)"
if [[ -z "$SWVER" ]]; then
echo "UNKNOWN - could not parse sw-version"
exit 2
fi
CFG_XML="$(fetch_api config xpath "/config/devices/entry[@name='localhost.localdomain']/network/global-protect")"
if [[ -z "$CFG_XML" ]] || ! echo "$CFG_XML" | grep -q '<response status="success">'; then
echo "UNKNOWN - version=${SWVER}, failed to retrieve GlobalProtect config"
exit 2
fi
HAS_GP=1
if echo "$CFG_XML" | grep -Eq '<global-protect>|<portal>|<gateways?>'; then
HAS_GP=0
fi
is_patched_version "$SWVER"
PATCH_STATUS=$?
if [[ $PATCH_STATUS -eq 2 ]]; then
echo "UNKNOWN - version=${SWVER}, could not classify against vendor matrix"
exit 2
fi
if [[ $PATCH_STATUS -eq 0 ]]; then
echo "PATCHED - version=${SWVER} is on an unaffected/fixed/hotfixed release"
exit 0
fi
if [[ $HAS_GP -eq 0 ]]; then
echo "VULNERABLE - version=${SWVER} is affected and GlobalProtect config appears present"
exit 1
else
echo "PATCHED - version=${SWVER} is affected in theory, but no GlobalProtect portal/gateway config was found"
exit 0
fi
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.