Cybersecurity

Critical VPN Security Flaw Under Active Attack — Check Your Palo Alto GlobalProtect Connections Now

A serious authentication bypass flaw in Palo Alto GlobalProtect VPN is being actively exploited — no password required. Here's what small businesses need to know and do right now.

Critical VPN Security Flaw Under Active Attack — Check Your Palo Alto GlobalProtect Connections Now

If your business uses a Palo Alto Networks firewall to let employees connect remotely, there's an actively exploited security flaw you need to know about right now. It doesn't require a password to exploit. It doesn't require any user interaction. And it's already hit multiple organizations in the real world.

Here's everything you need to know — in plain English.


What Is Palo Alto GlobalProtect?

Palo Alto GlobalProtect is a VPN (Virtual Private Network) solution built into Palo Alto Networks firewall hardware. Many small and mid-sized businesses use it to let employees securely connect to the office network from home or while traveling. If your business has a Palo Alto firewall and employees log into it remotely, there's a good chance GlobalProtect is how they're doing it.

You might be running GlobalProtect if:

  • Your employees use a "GlobalProtect" client app on their laptops to connect to the office
  • Your IT provider set up a Palo Alto firewall (brands like PA-220, PA-440, or similar)
  • Your VPN login page is hosted through a Palo Alto "portal" or "gateway" address

If any of that sounds familiar, keep reading.


What's the Flaw? (CVE-2026-0257)

The vulnerability is tracked as CVE-2026-0257 and carries a CVSS score of 7.8. It affects the GlobalProtect portal and gateway components of Palo Alto's PAN-OS software, and it allows attackers to bypass authentication entirely and establish unauthorized VPN connections — no username, no password required.

Here's the technical core of why it works: many organizations use the same certificate for both their HTTPS service and the cookie encryption feature that GlobalProtect uses to keep users logged in. That's a common misconfiguration. When those two services share a certificate, an attacker can grab the public key right from the HTTPS session — which is publicly visible — and use it to forge a fake authentication cookie for any account on the device, including the local administrator account.

As Security Affairs explains, once that forged cookie is accepted, the device treats the attacker as a fully authenticated, legitimate user. No credentials required.

Rapid7 built a proof-of-concept script that demonstrates just how fast this works: retrieve the certificate chain, forge a cookie, test it. The whole process takes seconds against a vulnerable appliance.


Is This Actually Being Exploited?

Yes — and it's been happening longer than most organizations realize.

Cybersecurity firm Rapid7 confirmed active exploitation across numerous customer environments, with the earliest observed attacks dating back to May 17, 2026. Their monitoring team caught the first wave on May 18 at 01:51 UTC, originating from infrastructure hosted by Vultr. The attacker used the hostname "GP-CLIENT" on a Linux system and a spoofed MAC address of aa:bb:cc:dd:ee:ff.

A second wave hit on May 21, this time originating from a hosting provider called Dromatics Systems, using the hostname "DESKTOP-GP01" — but the same spoofed MAC address. That consistent MAC address is what led Rapid7 to conclude both waves were likely the work of a single threat actor.

In some of those second-wave attacks, the forged cookie wasn't just accepted — the attacker was actually assigned a VPN IP address and gained access to the internal network. That's a full breach of the network perimeter. Fortunately, Rapid7 states they did not observe any indication of successful lateral movement in the environments where VPN sessions were established — but "no lateral movement yet" is not the same as "you're safe."

In 8 out of 10 impacted customers, the appliance accepted the forged cookie but didn't complete a full VPN session — the exact reason for that inconsistency remains unclear.


Are You Vulnerable? Here's How to Check

Your setup is at risk if both of the following are true:

  1. Authentication override cookies are enabled on your GlobalProtect portal or gateway
  2. The cookie certificate is shared with the HTTPS service — meaning you're using the same certificate for both

If your Cloud Authentication Service is disabled and you haven't specifically created a separate certificate for cookie encryption, there's a good chance you match this profile.

The vulnerability does not affect Panorama or Cloud NGFW deployments, according to Palo Alto Networks' advisory.

If you're not sure how your firewall is configured, your IT administrator or the person who set up your Palo Alto device can check these settings. Rapid7 has also published a public proof-of-concept script on GitHub that can test whether your appliance is vulnerable — though running that kind of test is best left to someone with firewall experience.


What to Do Right Now

Palo Alto Networks patched CVE-2026-0257 on May 13, 2026. If you haven't updated your PAN-OS firmware since then, that's your first priority. Here are your options, from most to least preferred:

1. Patch your PAN-OS firmware. Upgrade to a patched version of PAN-OS as quickly as possible. This is the permanent fix.

2. Generate a dedicated cookie certificate. If you can't patch immediately, create a new, separate certificate used exclusively for the authentication override feature — one that is not shared with your HTTPS service. This closes the specific attack vector.

3. Disable authentication override cookies entirely. If neither of the above is immediately feasible, disabling the authentication override feature removes the exposure until you can patch properly.

CISA has added CVE-2026-0257 to its Known Exploited Vulnerabilities catalog and ordered federal agencies to mitigate the flaw by June 1, 2026. That urgency applies to private businesses too.


Why Palo Alto's "Medium" Rating Understates the Risk

Palo Alto initially rated this flaw as medium severity because it requires a specific configuration to be exploitable. Rapid7 pushed back on that framing — hard.

As Security Affairs notes, Rapid7's position is that an authentication bypass on an internet-facing enterprise VPN appliance — where successful exploitation lands an attacker directly inside your network — is not a medium-severity problem, regardless of what the CVSS calculator says. The real-world evidence backs them up: multiple businesses have already been hit.


What Small Businesses in Particular Should Do

If you're a Yuba City small business running Palo Alto gear, this is worth a quick conversation with whoever manages your network. A few questions to ask right now:

  • "Is our PAN-OS firmware up to date as of May 13, 2026?"
  • "Are we using authentication override cookies on GlobalProtect?"
  • "Is our cookie certificate separate from our HTTPS certificate?"

If you don't have an IT provider on retainer and need help checking your firewall configuration, our /business IT support team is available to take a look — this is exactly the kind of thing worth catching before it becomes a breach.

The indicators of compromise — including the attacker IP addresses and the hostnames "GP-CLIENT" and "DESKTOP-GP01" — are published in Rapid7's advisory if your team wants to scan logs for signs of prior compromise.


The bottom line: a patch has existed since May 13. The attacks started May 17. There is no good reason to remain unpatched at this point. If you use Palo Alto GlobalProtect, verify your configuration and update today.

Related local service
Worried this could be malware?
If your computer has pop-ups, redirects, suspicious downloads, or ransomware warnings, start with our local virus removal page.
Tags
cybersecurity vulnerability patch-management small-business-it web-security