Applying Vulnerability Protection to GlobalProtect Interfaces

Showing results for 
Show  only  | Search instead for 
Did you mean: 
L4 Transporter
75% helpful (9/12)


This document discusses the configuration steps for applying a vulnerability protection security profile to GlobalProtect interface, in order to protect the GlobalProtect services from attacks using published product security vulnerabilities.



In customer deployments that use GlobalProtect for remote access, customers often configure and apply security profiles such as vulnerability protection to network traffic between VPN clients and internal network zones. 


There are also certain circumstances where a customer may want to apply a vulnerability protection profile to traffic hitting the GlobalProtect portal and gateway services, which are served by the firewall and not just traffic going through the firewall into the network. For example, there may be situations where a customer wants to block attempted attacks before they are able to upgrade PAN-OS to a patched version. This can be accomplished by applying a properly configured vulnerability protection profile to a firewall rule that is configured to apply to traffic hitting the GlobalProtect portal and gateway services hosted by the firewall.


Note 1: 4/14/2024: A hotfix for each of the PAN-OS versions (10.2, 11.0, 11.1) affected by CVE-2024-3400 is now available in the Customer Support Portal (CSP) and inside PAN-OS (both NGFWs and Panorama). An ETA for other commonly deployed versions of PAN-OS is available on the product security advisory for CVE-2024-3400. It is recommended to apply this hotfix and also complete the mitigations recommended in the advisory. 


Note 2: This document uses CVE-2024-3400 as an example in this how-to guide, where vulnerability protection signature #95187 was released in content version 8833-8682, released on 4/11/2024 to detect and prevent attempted attacks. The vulnerability affected GlobalProtect portal and gateway services. This document assumes that the firewall is already configured and used as a GlobalProtect portal and/or gateway service.



Configuration Steps:


Step 1: Ensure that you have the latest content update installed that includes the relevant threat protection

  • Make sure the content version that you are running includes the threat signature(s) that need to be applied to the GlobalProtect interfaces in order to block the attack.
  • In the example used in this document, the minimum content version required is 8833-8682, which was released on 4/11/2024.


Step 2: Determine the correct zone for GP portal and GP gateway

    • If a GP Portal is configured, go to Network > GlobalProtect > Portals and find the portal and associated interface. In the example below, you will see we are using GP-Auto-Portal1 as an example. The interface that the portal connects to is shown to be ethernet1/1.


GlobalProtect Step 2.png


  • Determine the associated zone for the GlobalProtect portal that includes the interface found in the previous step.
    Go to Network > Interfaces > Ethernet. In the example below, we can see that interface ethernet1/1 is in GP-untrust zone.


GlobalProtect Step 2.1.png


  • If a GlobalProtect gateway is configured, go to Network > GlobalProtect > Gateways and find the gateway and associated interface. In the example below, you will see we are using GP-GW1 as an example. The interface is loopback.1.


GlobalProtect Step 2.2.png


  • Determine the zone associated with the GlobalProtect gateway. Go to Network > Interfaces > Loopback. We can see that interface loopback.1 is also in GP-untrust zone. Now we know the zone for the portal and gateway, which we need to protect with a vulnerability protection profile.


GlobalProtect step 2.3.png


Step 3: Modify or Create a New Vulnerability Protection Profile 

Configure a new or existing vulnerability profile that is specifically configured to block the relevant threat impacting the GlobalProtect services. Go to Objects > Security Profiles > Vulnerability Protection. We recommend as a best practice to simply set the blocking action of “reset-server” for all critical severity signature triggers.


GlobalProtect Step 3.png


  • Alternatively, you can add an exception specifically for the relevant signature (#95187 in this case) to configure the reset-server action for this signature when it triggers (see below).


Screenshot 2024-04-14 at 8.33.05 AM.png



Step 4: Modify or create a firewall security rule

After modifying or creating a new vulnerability protection object, verify what security policies were in place to protect GlobalProtect services, and add newly created Vulnerability Protection Profile. If you already have a customized / Best Practices Profile attached to your security policy, please go back to Step 3 and amend your existing Vulnerability Protection Profile instead of creating a new one.


If you did not have an existing security policy and rule in place, then go ahead and create a security rule to apply the vulnerability protection profile to. Go to Policies > Security. Create a new policy. In this example, we name it “block_gp_vulnerability.” The source zone should be “any” and the destination zone is the GlobalProtect gateway and/or GlobalProtect portal zones we found in step 1. Assign to this rule the Vulnerability Protection Profile you modified or created in step 3. Please make sure that the rest of the the applied policy and security policies follow our best practices guides.



GlobalProtect Step 4.png



Step 5: Commit

Commit the changes to apply the new Vulnerability Protection Profile to the Security Rule protecting the GP Portal and/or Gateway.  Any attempted attacks against the GlobalProtect services that attempt to use this specific vulnerability will be blocked and logged in the threat log.




Is GlobalProtect enabled?
  • You can verify by checking for entries in your firewall web interface (Network > GlobalProtect)


Am I compromised?
  • You can upload a technical support file (TSF) to Customer Support Portal (CSP) after opening a case to determine if your firewall device(s) match(es) known indicators of compromise (IoC).


What do I need to do?
  • Review the output of technical support file (TSF) analysis (see above question) to understand the level of attempted exploitation and remediation steps provided in the Unit 42 Threat Brief for CVE-2024-3400.
  • As a best practice, we strongly recommend all customers apply the Threat Prevention signature with Threat ID 95187 and 95189 (available in Applications and Threats content version 8835-8689 and later), and apply vulnerability protection to their GlobalProtect interface.
  • After completing above steps we strongly recommend installing the hotfix listed in the advisory for your impacted PAN-OS devices.


Is Prisma Access or Cloud NGFW impacted by this vulnerability?
  • Prisma Access and Cloud NGFW are not impacted by this vulnerability.


What PAN-OS versions are affected?
  • This affects PAN-OS versions 10.2 and greater.
  • Hotfixes are released for PAN-OS 10.2, 11.0 and 11.1 branches. Please refer to the security advisory for more information.


Is disabling telemetry an effective mitigation strategy?
  • In earlier versions of the advisory, disabling device telemetry was listed as a secondary mitigation action. Disabling device telemetry is no longer an effective mitigation. Device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability.


How can I look for IoCs and research a potential compromise?


I applied the hotfix; how can I confirm I’m now “clean”?
  • Before rebooting into the hotfix it is recommended that you take a TSF and upload for analysis on any level of compromise and take the recommended remediation actions if appropriate
  • After remediating if needed, upgrading and booting into the hotfix, you can verify that you are running the fixed version of code by running the “show system info” CLI command and checking the sw-version field against what is published as fixed in the CVE.
  • You can upload the new TSF for analysis and confirmation that no further indicators of compromise are seen from the upgraded device.


Additional Resources on CVE-2024-3400:
Rate this article:
L0 Member

@DevalS If you have a Security Policy that is already setup to allow users to access the WAN interface for the GlobalProtect portals zone or interface then that rule is where you want to make sure a Vulnerability Profile is applied. If that Vulnerability Profile is in line with the Palo Alto Recommended best practice then you are already good to go.

L3 Networker

Got the signature deployed - finally!



  • The vulnerability id 95187 would not show up in the Panorama 10.2.8 GUI no matter what I did.



  • Credit to @AJS_Justin - This command on the command line, plus a hard browser page refresh in Panorama, worked to make 95187 visible.
    request content upgrade install sync-to-peer yes commit yes version latest


Follow Up:

  • I will give credit to PAN for a mitigation that does not involve an immediate code upgrade. (Thanks!)
  • That said, if there are PANOS issues that prevent me from implementing the mitigation, then someone from PAN should step up and include that information in the mitigation notes!
  • I'll bet good money that PAN TAC has seen an excess of calls today just because the vulnerability ID would not appear in the GUI.


L0 Member

Applications and Threats Content version 8834 updated the metadata for threat id 95187 and it does show up in gui now

L1 Bithead

This article should/must be heavily adjusted. As several has mentioned here, following the guidelines will make things worse, since an any any allow rule on top with only vulnerability protection for that specific signature will open “everything”. I’ve just assisted a customer who followed this exact article and made an any any allow rule with only vulnerability protection for that specific signature. Crisis. All rules below with best practice setup where shadowed. 

Very important with 


@maurisy can you please adjust this article to advice people to follow best practices, so that inbound communication to GlobalProtect are protected with all profiles running best practices, including vulnerability protection which will have reset-both for critical severity vulnerabilities. Then the only thing customers need to verify is that they have that specific signature update, which seems to have been a problem with this release so that they have to delete the content update and download it again. And that’s it. 

No config change is needed if they’re running best practices. 

Please adjust this article so that no more customers open “everything”





L1 Bithead

Hi Team,


Please help me to understand the below:


Firewall 1 - 10.2, GP portal & Gateway, Device telemetry enabled

Firewall 2 - 10.2, only GP portal & gateway, no device telemetry enabled

Firewall 3 - 10.2, no GP portal and gateway, only device telemetry enabled.


Firewall 1 will be impacted by this vulnerability.


Please confirm if firewall 2 and firewall 3 will also be impacted due to this vulnerability.


Thanks in advance

L0 Member

Anyone know of a way to test it from the outside to see if the vulnerability is in fact blocked/mitigated?

L1 Bithead

Anyone else having issues with GP portal after upgrading?
All my users are now unable to connect. From the logs it seems that it "Failed to get client config"


If i replace the group-matching with a test user it works right away...worked before as a charme


Any ideas?

Community Team Member

Hi @M.Sharma415844 ,


No, this issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 firewalls configured with GlobalProtect gateway or GlobalProtect portal (or both) and device telemetry enabled.


Kind regards,


L1 Bithead

Hi @kiwi 


Thank you for your confirmation.


I understand now that only firewall 1 will be impacted. Not firewall 2 and 3.


Thanks again

L1 Bithead

Nevermind my previous was another azure-related issue

L0 Member


Should the service/application be ANY? 

L0 Member

I think the article confused a lot of people and causing some to overthink. If you have a vulnerability profile that has "critical" classified vulnerabilities set to reset-both or reset-server, and applied to the Security Policy that is allowing the GlobalProtect connection (SSL/IPSec), you're already protected. The article tried to list a way to "override" the default actions your policies may have been set to in case for some reason you're not blocking "critical" vulnerabilities. Which is a weird thing to assume for them... but I guess in an effort to be thorough. 

L0 Member

The threat ID 95187 is appearing correclty after installation of APP ID 8834.

L0 Member

@waleedsabourDO NOT add a new rule a the top of your rule list. Doing so will allow all sorts of things into your network that you don't want. Here's what to do instead:

1. Disable telemetry. Commit this change.

2. Update the firmware on your firewall(s) to the appropriate patched version.

3. Go back and check your existing inbound security profiles, make sure they are set to something (not "none") that blocks the malicious stuff.


L1 Bithead

Instead of search for the Threat id in the exemption tab, just search for the cve.


( cve contains 'cve-2024-3400' )


Since they are adding more, they will all show up.  Later. 

L1 Bithead



Our firewall which has GP portal is currently running on 10.1.11-h5 and would like to know if we are also impacted by

CVE-2024-3400 PAN-OS: OS Command Injection Vulnerability in GlobalProtect


As the advisory mentions that all the firewalls above 10.2 are the ones which are impacted.

I just want to double check that PAN OS 10.1 is not impacted by this CVE.



L0 Member
L0 Member

The Vulnerability Protection Profile is applied to the rule you set up for GP under Policies.

L0 Member

Anyone know of a way to test it from the outside to see if the vulnerability is in fact blocked/mitigated?

monitor > logs > threat > paste this in for filter:
( severity eq 'critical' ) and ( name-of-threatid eq 'Palo Alto Networks GlobalProtect OS Command Injection Vulnerability' )

L1 Bithead

To see if there's any hit on the signatures in the threat log: (( threatid eq '95187' ) or ( threatid eq '95189' ) or ( threatid eq '95191' ))

L1 Bithead



By reading the bulletin from Palo Alto Networks, 10.1 are not impacted.

L1 Bithead

I've written an article on how to whitelist (Least Privilege) inbound GlobalProtect communication including URL, and similar for outbound communication from the Firewall so that malicious outbound connections aren't possible. Do your proactive security job properly. Use your firewall as it was meant to be used. Assume Breach. Least Privilege. Zero Trust.


Start with this, and continue the Least Privilege approach for server to internet communication, start with your domain controllers, because what do your DCs need towards internet? This is all about Cyber Kill Chain #6, Command & Control

L1 Bithead

Someone are wondering if they can test if they're still vulnerable. Check out this PoC:

Community Team Member

Hi Everyone, we took a look at the comments and added a FAQ to the article.

  • 227 Subscriptions
Register or Sign-in
Article Dashboard
Version history
Last Updated:
‎04-24-2024 10:11 AM
Updated by: