{"id":8711,"date":"2026-06-02T15:52:07","date_gmt":"2026-06-02T20:52:07","guid":{"rendered":"https:\/\/www.threatstop.com\/blog\/globalprotect-exploited-for-weeks-who-protects-the-firewall"},"modified":"2026-06-02T15:52:07","modified_gmt":"2026-06-02T20:52:07","slug":"globalprotect-exploited-for-weeks-who-protects-the-firewall","status":"publish","type":"post","link":"https:\/\/ddi.mohflo.net\/index.php\/2026\/06\/02\/globalprotect-exploited-for-weeks-who-protects-the-firewall\/","title":{"rendered":"GlobalProtect exploited for Weeks: Who Protects the Firewall?"},"content":{"rendered":"
<\/div>\n

Or, as those canny Romans had it: Quis custodiet ipsos custodes? (Who watches the watchmen?)<\/em><\/p>\n

<\/p>\n

You have a firewall to protect users, servers, applications, VPN users, and assorted expensive business-critical things behind it. That\u2019s great. But these days the firewall is not just a firewall. It is also a VPN gateway, an authentication point, a remote access portal, and usually the first system an attacker gets to talk to.<\/p>\n

So what happens when the firewall itself is the target?<\/p>\n

That is not a theoretical question. It has been happening more and more frequently lately.<\/p>\n

SecurityWeek reports<\/a> that attackers began exploiting CVE-2026-0257<\/a>, an authentication bypass vulnerability in Palo Alto Networks PAN-OS GlobalProtect<\/a>, just four days after public disclosure. Palo Alto Networks says the issue affects GlobalProtect portals or gateways under specific configurations and can let an attacker bypass restrictions and establish an unauthorized VPN connection. Palo Alto has marked the vulnerability as ATTACKED<\/strong> with HIGHEST<\/strong> urgency.<\/p>\n

This moved fast.<\/h4>\n

Rapid7 reported exploitation<\/a> beginning on May 17, 2026, with a second wave on May 21. In that second wave, Rapid7 observed VPN IP assignment following cookie authentication, which gave the attacker access to the internal network in some cases. <\/p>\n

How to Mitigate?<\/h3>\n

Upgrade to the fixed version of software from PAN, or apply their workaround ASAP<\/span><\/h4>\n

The correct answer is to patch. Palo Alto Networks has released fixed versions and documented mitigations, including disabling authentication override or using a dedicated certificate for authentication override cookies. Affected organizations should follow the Palo Alto advisory<\/a> and upgrade or mitigate immediately.<\/p>\n

But patching is not a force field.<\/p>\n

There are maintenance windows. There are HA pairs. There are remote users. There are change controls. There are rollback plans. There is always one box that everyone thought someone else owned.<\/p>\n

Attackers know this.<\/p>\n

They do not need every firewall to remain vulnerable forever. They only need enough vulnerable firewalls to remain reachable for long enough.<\/p>\n

That is where ThreatSTOP comes in. By blocking the scanning and exploiting hosts, we STOP the attack, buying you precious time.<\/p>\n

How the attack really starts<\/h3>\n

Attackers do not usually start by lovingly hand-crafting an exploit for your particular firewall while sipping artisanal coffee.<\/p>\n

They scan.<\/p>\n

They sweep the internet looking for systems that might be vulnerable. In this case, that means exposed GlobalProtect portals or gateways that may be running affected PAN-OS versions in an affected configuration.<\/p>\n

If the scanner gets a useful response, the target goes on a list.<\/p>\n

Then the work is handed off.<\/p>\n

The exploit attempt may come from a different host. It may come from cheap hosting. It may come from a proxy. It may come from compromised infrastructure. It may come from a botnet. It may come from infrastructure the attacker has used before because, like everyone else, criminals reuse things that work.<\/p>\n

That gives defenders more than one chance to stop the attack.<\/p>\n

Block the scanner, and the attacker may never know there is a useful target.<\/p>\n

Block the exploit host, and the vulnerable firewall never has to decide whether the forged cookie is good enough.<\/p>\n

Block the follow-on infrastructure, and even a successful exploit has a harder time becoming a breach.<\/p>\n

A vulnerability is not the same thing as a compromise. The attacker still has to connect.<\/p>\n

ThreatSTOP blocks the path to exploitation<\/h3>\n

This is the point we have made more than once,<\/a> as these types of vulnerabilities have become more common.<\/p>\n

IP blocks applied at the external interface take effect early, before the traffic reaches the higher inspection layers or the vulnerable service itself. That matters when the thing being attacked is the security device. <\/p>\n

ThreatSTOP IP Defense is designed for exactly this problem. It works with firewalls, routers, switches, load balancers, IDPS, and other TCP\/IP-based devices to identify and stop threats early.<\/p>\n

ThreatSTOP uses continuously updated threat intelligence derived from honeypots, our own scanners, AI analytics on: the logs received from over 100 million DNS clients, carrier customers, logs from firewalls using our service; and third party data from over a thousand other sources, to keep network devices updated with policies that block malicious IP sources and destinations.<\/p>\n

The best time to stop a firewall exploit is not after the authentication bypass succeeds.<\/p>\n

It is before the attacking host gets to talk to your external network at all.<\/p>\n

We know the reconnaissance scanners, and ThreatSTOP blocks them.<\/p>\n

We detect exploit hosts early and at scale. They attack us all the time. Thanks guys, every attack becomes intelligence to protect users. ThreatSTOP blocks them.<\/p>\n

We know the bots, proxies, abused VPNs, TOR exit nodes, and other criminal infrastructure. If you use these policy elements, ThreatSTOP blocks them.<\/p>\n

If a compromised device tries to call home, ThreatSTOP gives you another chance to stop the incident from becoming a breach by blocking those connections.<\/p>\n

ThreatSTOP interdicts multiple stages of the attacker workflow: noisy scanners first, then a different system for exploitation, and then follow-on infrastructure for call-homes or downloads.<\/p>\n

We are the best first line of defense, and the best last check on exploitation, exfiltration, and command and control.<\/p>\n

But the firewall already has security features<\/h3>\n

Yes. And that is exactly the point.<\/p>\n

When the device under attack is also the device enforcing the security policy, you do not want to rely on the vulnerable service to make the right decision. You want the bad source dropped before it reaches the service.<\/p>\n

Before the VPN logic.<\/p>\n

Before the cookie handling.<\/p>\n

Before the authentication bypass.<\/p>\n

Before the firewall has to be perfect.<\/p>\n

This is not \u201cput another firewall in front of the firewall.\u201d That way lies madness, budget meetings, and diagrams nobody wants to maintain.<\/p>\n

This is making the firewall protect itself.<\/p>\n

ThreatSTOP IP Defense <\/a>turns the existing firewall into a Threat Intelligence Gateway by keeping it updated with current intelligence about malicious infrastructure. ThreatSTOP enables the firewall to block connection attempts to criminal infrastructure on all ports and protocols with continuous, automatic policy updates.<\/p>\n

What this means for Palo Alto Networks customers<\/h3>\n

For organizations running Palo Alto Networks firewalls with GlobalProtect exposed to the internet, the checklist is straightforward:<\/p>\n

    \n
  1. Review Palo Alto\u2019s advisory for CVE-2026-0257<\/a>.<\/li>\n
  2. Confirm whether GlobalProtect portal or gateway is enabled.<\/li>\n
  3. Check whether authentication override cookies and the relevant certificate configuration create exposure.<\/li>\n
  4. Upgrade to a fixed PAN-OS version or apply Palo Alto\u2019s recommended mitigations.<\/li>\n
  5. Review GlobalProtect logs for suspicious cookie-based authentication and unexpected VPN assignment.<\/li>\n
  6. Use ThreatSTOP IP Defense to block known scanner, exploit, botnet, proxy, VPN abuse, and command-and-control infrastructure. This will protect against systems exploiting this vulnerability, and future ones.<\/li>\n<\/ol>\n

    ThreatSTOP does not replace patching. Nothing does.<\/p>\n

    ThreatSTOP reduces the attacker\u2019s opportunity to exploit the gap between the vulnerbility being discovered, \u201ca patch exists\u201d, and \u201cevery affected device is safely upgraded.\u201d <\/p>\n

    That gap is where attackers live. In today’s AI driven vulnerability detection and exploit creation world, time is not on the defender’s side. ThreatSTOP gives you back TIME.<\/p>\n

    Stop the knock at the door<\/h3>\n

    The current attacks targeting Palo Alto Networks are a reminder of a simple truth: perimeter devices are now targets, not just guards.<\/p>\n

    Attackers need to find vulnerable hosts. ThreatSTOP blocks the scanners.<\/p>\n

    Attackers need to send exploit traffic. ThreatSTOP blocks the exploit hosts.<\/p>\n

    Attackers need infrastructure to stage, proxy, control, and monetize attacks. ThreatSTOP blocks the criminal infrastructure.<\/p>\n

    The result is simple: even if a firewall is vulnerable, ThreatSTOP can prevent the exploit from being tried, or prevent it from succeeding, by blocking the attacking hosts before they get a clean shot.<\/p>\n

    Patch your Palo Alto firewalls.<\/p>\n

    And make sure the attackers cannot reach them while you do.<\/p>\n

    Connect with Customers. Disconnect from Risks.<\/strong><\/h4>\n

    Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    Or, as those canny Romans had it: Quis custodiet ipsos<\/p>\n","protected":false},"author":9,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[30,62,215,216,3951,61,49],"tags":[237,879,877,3956,6771,57,429],"class_list":["post-8711","post","type-post","status-publish","format-standard","hentry","category-dns","category-dns-security","category-passive-dns","category-pdns","category-predictive-threat-intelligence","category-protective-dns","category-threat-intelligence","tag-cyber-attacks","tag-inbound-attacks","tag-ip-firewall","tag-predictive-threat-intelligence","tag-specific-threats","tag-threat-intelligence","tag-threatstop-in-use"],"featured_image_urls":{"full":"","thumbnail":"","medium":"","medium_large":"","large":"","1536x1536":"","2048x2048":"","chromenews-featured":"","chromenews-large":"","chromenews-medium":""},"author_info":{"display_name":"Threat Stop","author_link":"https:\/\/ddi.mohflo.net\/index.php\/author\/threatstop\/"},"category_info":"DNS<\/a> DNS Security<\/a> Passive DNS<\/a> PDNS<\/a> Predictive Threat Intelligence<\/a> Protective DNS<\/a> Threat Intelligence<\/a>","tag_info":"Threat Intelligence","comment_count":"0","jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/posts\/8711","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/comments?post=8711"}],"version-history":[{"count":0,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/posts\/8711\/revisions"}],"wp:attachment":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/media?parent=8711"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/categories?post=8711"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/tags?post=8711"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}