PAN-OS GlobalProtect Authentication Bypass

CVE-2026-0257: PAN-OS GlobalProtect Authentication Bypass

The Short Version

CVE-2026-0257 is an authentication bypass vulnerability in Palo Alto Networks PAN-OS affecting the GlobalProtect portal and gateway. The root cause is embarrassingly straightforward: the device trusts authentication override cookies that have been encrypted with a public key it happily hands out over TLS. No credentials required. No interaction from a user. Just an HTTPS handshake, a little RSA math, and you have a forged VPN session token the firewall accepts without complaint.

The vendor originally scored this at CVSSv4 4.7. “Medium,” they said. CISA then added it to the Known Exploited Vulnerabilities catalog and mandated federal agencies patch by June 1, 2026. Rapid7 observed active exploitation across multiple customers starting May 17. The score was quietly revised to 7.8 before the dust settled. That CVSS trajectory should tell you everything you need to know about how the initial triage landed.

This is a configuration-dependent vulnerability, which means it does not affect every PAN-OS deployment. But the configuration that enables it, authentication override cookies shared with the HTTPS certificate, is not exotic. It is a reasonable deployment pattern that a lot of organizations have been running for years.

Post-Exploitation: Observed Attacker Activity

Once an attacker bypasses authentication and receives an internal private_ip assignment, they immediately shift to internal network intrusion. In-the-wild tracking across compromised environments shows actors deploying an automated, noisy combination of three primary tools directly out of the unauthorized VPN sessions:

• Nmap: Broad internal scanning to map out subnets and locate Domain Controllers and high-value infrastructure.
• Kerbrute: Kerberos Pre-Authentication abuse on Domain Controllers to rapidly enumerate users and password spray accounts.
• Impacket: Lateral movement and remote command execution via SMB/WMI using harvested credentials to compromise internal endpoints.

1. Internal Reconnaissance via Nmap

With an active VPN tunnel established, attackers use Nmap to map out internal segments, specifically hunting for Domain Controllers, file shares, and hypervisors.

2. Active Directory Enumeration via Kerbrute

To avoid triggering noisy account lockouts via traditional brute-forcing, attackers deploy kerbrute to abuse Kerberos Pre-Authentication for user enumeration and password spraying.

• Log Fingerprints: This activity completely bypasses standard Windows Security Event ID 4625 (Failed Logon). Instead, look for a surge of Event ID 4768 (A Kerberos authentication ticket (TGT) was requested) on your Domain Controllers originating from the VPN IP.
• Specific Error Codes to Hunt:
  • Result Code 0x6: Client not found in Kerberos database. A single VPN IP cycling through hundreds of usernames triggering this code indicates active user enumeration.
  • Result Code 0x18: Pre-authentication information invalid. This indicates a bad password and points to an active password-spraying campaign.

3. Lateral Movement and Execution via Impacket

Once credentials or local admin tokens are harvested, attackers leverage the Impacket Python library to pivot laterally and execute code remotely on internal endpoints.

A. psexec.py / smbexec.py (Remote Service Creation)

These modules interact with the Service Control Manager (svcctl) over SMB (Port 445) to create a temporary, high-privilege system service.

• Host Telemetry: Look for Windows Security Log Event ID 4697 or System Log Event ID 7045 (A service was installed in the system) on target servers.
• Impacket Default Fingerprints:
  • Service Name: Random 4-to-8 alphanumeric characters (e.g., BTOA, psexecsvc).
  • Service File Path: Execution out of writable system shares, typically looking like %SystemRoot%\System32\shares\<random>.exe or a direct invocation of cmd.exe /Q /c.

B. wmiexec.py (Semi-Interactive Shell via WMI)

For a stealthier approach that avoids service creation, attackers use WMI execution over RPC (Port 135) to spawn commands via the Win32_Process class.

• Host Telemetry: Look for Windows Security Log Event ID 4688 (Process Creation) tracking anomalous command shell behaviors.
• Impacket Default Fingerprints: Impacket pipes command outputs into hidden administrative shares. Look for this specific process lineage:
  • WmiPrvSE.exe -> cmd.exe /Q /c <command> > \\127.0.0.1\ADMIN$\__1234567890 2>&1

  • Artifacts: The rapid creation and deletion of files prefixed with a double underscore (__) inside the C:\Windows\ directory.

    Hunt Strategy: Correlating the Chain

To turn these post-exploit observations into an actionable defense, defenders must link the initial perimeter entry point directly to internal network behavioral shifts:

  [PAN-OS Firewall]                              [Active Directory]                            [Internal Endpoint]
   GlobalProtect Log                              Domain Controller                             Security Event Log
  ------------------                             -------------------                           -------------------
   Auth Type: "Cookie"                            Event ID: 4768 (TGT)                          Event ID: 4697 / 7045
   User: admin                                    Result Code: 0x6 / 0x18                       Service: <Random>.exe
   Source: Vultr/Dromatics IP  =======>           Src IP: Assigned VPN IP   =======>            Src IP: Assigned VPN IP
   Action: Assigns Private IP                     (Kerbrute Enumeration)                        (Impacket Lateral Pivot)

If your GlobalProtect logs show an unvalidated cookie login event, pivot immediately to your internal network logs and filter for all traffic originating from that specific internally assigned private_ip during the session window. Any instance of the internal IP interacting with a Domain Controller over Port 88 (Kerberos) or Port 445 (SMB) immediately following authentication should be treated as a confirmed active intrusion.

Timeline and Abuse History

The advisory came out on May 13, 2026, and was internally discovered by Palo Alto Networks’ own security research team. No external researcher credit. This is not unusual for edge device vulnerabilities, but it does leave a question open about whether anyone else found it earlier and just did not talk about it.

The gap between disclosure and exploitation was four days. By May 17, Rapid7 MDR was already responding to alerts across customer environments. All source activity in that first wave traced back to Vultr-hosted infrastructure. The same spoofed MAC address (aa:bb:cc:dd:ee:ff, which is about as subtle as wearing a ski mask to a bank) appeared consistently across impacted organizations.

A second exploitation wave hit on May 21. Same MAC address. Different infrastructure provider (Dromatics Systems this time). Based on behavioral consistency across both waves, Rapid7 assessed this was likely the same threat actor. In that second wave, the attacker went further: Rapid7 observed POST requests to /ssl-vpn/hipreport.esp and /ssl-vpn/getconfig.esp, which is the sequence that follows successful cookie authentication and results in an actual VPN tunnel being established.

On May 29, CISA added CVE-2026-0257 to KEV. Also on May 29, Palo Alto updated their advisory to reflect active exploitation and bumped the CVSS. The deadline for federal civilian agencies was June 1, 2026.

Today is June 5. If you are still unpatched and unmitigated, you are operating on borrowed time, and the threat actor has already shown they know your address.

Impacted Versions and Patch Status

The vulnerability requires a specific configuration to be present. The impacted product lines are PAN-OS physical and virtual firewalls and Prisma Access. Cloud NGFW and Panorama are not affected.

Required configuration for exposure:

• GlobalProtect portal or gateway must be configured
• Authentication override cookies must be enabled (generate or accept)
• The certificate used for authentication override cookie encryption must be the same certificate used for another feature, specifically the HTTPS service

That last condition is the one that bites. Palo Alto’s own documentation does not scream at you to isolate this certificate. It is a design pattern that made operational sense, and now it is the attack vector.

Affected versions:

Heads up on the post-patch behavior: After upgrading, all existing authentication override cookies are invalidated. Every GlobalProtect user will need to re-authenticate once. This is intentional and expected. Plan for the user support load accordingly.

Proof-of-Concept Details

Rapid7 Labs published a working PoC as part of their disclosure. The script (forge_cookie.py) is available at sfewer-r7/CVE-2026-0257 on GitHub.

The tool is built for defender validation, not attacker tooling. It retrieves the TLS certificate chain from the target, iterates over each certificate’s public key, and attempts to forge a valid authentication override cookie with each one. If the device is misconfigured in the way CVE-2026-0257 requires, one of those forged cookies will be accepted and a VPN session will be established.

$ python3 forge_cookie.py --target 192.168.86.99 --user haxor
[*] Retrieving certificate chain from 192.168.86.99:443 ...
  Found 2 certificate(s) in chain:
  [0] CN=192.168.86.99 (RSA 2048 bits, CA=False)
  [1] CN=GP-Lab-CA (RSA 2048 bits, CA=True)

[*] Forging cookie for user 'haxor', testing each key

  Trying [0] CN=192.168.86.99
  [-] Failure - Gateway did not accepted the forged cookie
  [-] Failure - Portal did not accepted the forged cookie

  Trying [1] CN=GP-Lab-CA
  [+] Success - Gateway accepted the forged cookie
  Cookie: ng9ygxlaclylNXeSHcakXZPK06Fno0svVirz6RhRtA5mDmOaZy...

The second certificate in that chain, the CA certificate, is the one shared with the HTTPS service. The gateway accepted a cookie signed with its own CA’s public key because it never verified that the cookie came from a source it should trust. It only verified that the decryption worked.

Usage options let you specify target username, domain, host ID, client OS, client IP, and whether to test against a portal, gateway, or both. Attackers in the wild used admin as the target username in observed exploitation, which makes sense: shoot for the highest-privilege local account first.

Exploitation Mechanics

Let’s talk about what is actually happening here, because the gap between “authentication bypass” and the mechanics of why deserves more than a paragraph.

The Authentication Override Feature

GlobalProtect supports a convenience feature: rather than requiring users to re-authenticate every time they connect, the portal or gateway can issue an encrypted cookie after a successful authentication. On subsequent connections, the user presents this cookie instead of credentials. The device decrypts it, extracts the claimed identity and session parameters, and lets them in. Think of it like a signed session token, except the signing is done with RSA encryption and there is no separate integrity mechanism layered on top.

This feature is not enabled by default. When it is enabled, there are two configuration checkboxes in play: “Generate cookie for authentication override” (portal/gateway issues the cookie) and “Accept cookie for authentication override” (portal/gateway will honor a cookie on login). The vulnerability is exploitable when the second option is on and the certificate situation is wrong.

The Certificate Reuse Problem

The fix for this vulnerability in isolation is clear: do not use the same certificate for authentication override cookies that you use for your HTTPS service. When you do, an attacker who can complete a TLS handshake with your GlobalProtect portal or gateway will retrieve the certificate chain. That chain contains the public key. That public key is exactly what they need to encrypt a forged cookie.

Looking at the gpsvc binary (Rapid7’s analysis examined PAN-OS 10.2.8), the main_DecryptAppAuthCookie function handles incoming authentication cookies. It base64-decodes the cookie value, then runs RSA decryption using the configured private key. The decrypted content is then treated as trusted session data with no signature verification of any kind performed afterward.

error __gostk main_DecryptAppAuthCookie(
    main_GpTask_0 *t,
    string authCookie,
    string privateCert,
    string *user,
    string *domain,
    string *hostId,
    string *clientOs,
    string *remoteAddr,
    int64 *ts)
{
  if ( privateCert.len )
  {
    *(retval *)&text[48] = paloaltonetworks_com_libs_common_DecryptRsaPrivateWithBase64Std(
                             privateCert,
                             (string)0LL,
                             authCookie);

The function decrypts using the private key and trusts whatever comes out. There is no MAC. There is no signature. There is no challenge-response. If the decryption succeeds, the content is valid. Full stop.

The attacker’s workflow to forge a cookie follows directly from this:

1. Retrieve the TLS certificate chain from the GlobalProtect portal or gateway HTTPS endpoint
2. Identify the CA certificate or any certificate in the chain that is shared with the authentication override feature
3. Construct the expected cookie payload: username, domain, host ID, client OS, remote address, timestamp, and cookie lifetime
4. Encrypt that payload with the public key from the identified certificate
5. Base64-encode the result
6. Submit as the portal-userauthcookie or portal-prelogonuserauthcookie HTTP form parameter in a POST to /ssl-vpn/login.esp

The firewall decrypts it with its own private key, gets back a structurally valid payload, and treats the claimed identity as authenticated. Username is attacker-controlled. Domain is attacker-controlled. The only constraint is that the public key used for encryption must correspond to the private key configured for cookie decryption.

The Cookie Structure

The authentication override cookie encodes the following fields:

• Username
• Domain name
• Host ID
• Client OS
• Remote address
• Timestamp (used to enforce cookie lifetime)

The attacker controls all of these. In the wild, threat actors supplied admin as the username, aa:bb:cc:dd:ee:ff as a spoofed MAC / Host ID, and either GP-CLIENT or DESKTOP-GP01 as the client hostname depending on the wave. The client OS was set to Linux in the first wave and Windows in the second.

The timestamp matters because authentication override cookies have a configurable lifetime. If the timestamp in the forged cookie is too old relative to the configured lifetime, the gateway will reject it. Attackers just set the timestamp to current time, which costs nothing.

Post-Authentication VPN Access

After cookie acceptance, the flow continues like a normal GlobalProtect session. The device assigns a VPN IP address and the client can make requests to internal endpoints. Rapid7 observed POST requests to:

• /ssl-vpn/hipreport.esp - submits host information profile data (HIP check results)
• /ssl-vpn/getconfig.esp - retrieves VPN tunnel configuration and establishes the secure session

These two requests are the handshake that gets you from “authenticated” to “have an IP on the internal network.” In 8 out of 10 impacted Rapid7 MDR customers, only the cookie probe was observed without a full tunnel being established. In 2 out of 10, the attacker followed through to tunnel establishment.

Considerations and Limitations: What You Can and Cannot See

What the Logs Do and Do Not Capture

GlobalProtect authentication logs record cookie-based authentications. You will see entries like this when exploitation occurs:

1,2026/05/18 01:51:37,010101010101,GLOBALPROTECT,0,2817,2026/05/18 01:51:37,vsys1,gateway-auth,login,Cookie,,admin,US,GP-CLIENT,104.207.144.154,0.0.0.0,0.0.0.0,0.0.0.0,aa:bb:cc:dd:ee:ff,,6.0.0,,Linux,"linux-64",1,,,"Auth latency: 78ms, profile: local_auth_profile",success,,0,,0,GP-Gateway,...

A few things worth noting in that log entry: the authentication type is explicitly Cookie. The client hostname is GP-CLIENT. The MAC address is aa:bb:cc:dd:ee:ff. The source IP is a Vultr-hosted address. The auth profile is local_auth_profile. All of these are attacker-controlled and none of them are validated against anything external.

This is actually the forensic story in miniature: the logs tell you that authentication happened, they tell you the claimed identity, and they tell you every parameter the attacker chose to supply. They do not tell you whether any of it is real. You already know it is not.

What Is Not Left Behind

The forged cookie itself is not stored on the firewall in a form that persists to disk for later analysis. By the time you are doing forensics, the cookie has been decrypted, the fields have been extracted, and the session has been processed. What you have is the authentication log entry, not the raw cryptographic artifact.

There is no file written. There is no command executed. There is no payload dropped. A successful exploitation of CVE-2026-0257 in its basic form is purely a network-layer event: a specially crafted HTTPS POST that the firewall processes as a normal VPN authentication. If the attacker chooses to stop after probing (8 out of 10 customers in the Rapid7 data), your primary evidence of the event is the GlobalProtect authentication log showing a successful cookie login from an unusual source.

For the 2 out of 10 cases where tunnel establishment followed, you also get network traffic from the assigned VPN IP. Whether your network monitoring captures that traffic, and to what depth, determines how much you understand about what the attacker did after they got in.

The CVSS Mismatch Problem

The original 4.7 score reflects a technically constrained scenario: configuration-dependent, no lateral movement observed, access to the network segment rather than a specific target. But GlobalProtect is a VPN appliance. Its entire purpose is to be the boundary between the public internet and your internal network. An unauthenticated remote attacker with a working forged cookie is now inside that boundary.

The “medium severity” framing does not survive contact with reality. Every organization that runs GlobalProtect for remote access has made it network-accessible from the internet by design. This is not a vulnerability in a backend service protected by layers. It is the front door.

Forensic Visibility After the Fact

If you are trying to determine whether you were compromised prior to detection:

The GlobalProtect logs are your primary artifact. The relevant fields are auth type (Cookie), source IP, client hostname, MAC address, and username. For exploitation using the public tooling, you are looking for logins from unusual source IPs with admin as the username, aa:bb:cc:dd:ee:ff as the MAC, and either GP-CLIENT or DESKTOP-GP01 as the client hostname.

The limitation is that none of these fields are validated. A careful attacker can supply plausible-looking values. A fake cookie with a legitimate-looking hostname and a MAC address that matches an expected device format blends into normal authentication traffic. The authentication latency field in the log might be marginally different from legitimate cookie logins, but this is a very weak signal and not reliable.

If the attacker moved laterally from the VPN IP, that activity happens on your internal network and is captured by whatever monitoring you have there, not by the firewall. The firewall’s job ended when it handed out a VPN session.

Detection and Hunting

Primary Detection: GlobalProtect Authentication Logs

The known attacker behavior from in-the-wild exploitation gives you specific hunt queries. The indicators are attacker-controlled, so they can change. Use them as a starting point, not a definitive signal set.

Known attacker IOCs (from Rapid7’s observed exploitation):

Hunt logic (Palo Alto firewall GlobalProtect logs):

# Splunk-style query for suspicious cookie authentications
index=paloalto sourcetype=pan_globalprotect
| where auth_type="Cookie"
| where username="admin"
| stats count by src_ip, username, client_hostname, mac_address, auth_profile, _time
| where count > 1 OR src_ip IN ("104.207.144.154","146.19.216.119",
  "146.19.216.120","146.19.216.125","209.99.191.137","79.130.26.202")

Behavioral detection without IP-based IOCs:

Suspicious cookie auth patterns to look for regardless of IP:

• Cookie authentications to local admin accounts (auth profile points to local database)
• Cookie authentications from IPs that have no prior credential-based authentication history on the device
• MAC address aa:bb:cc:dd:ee:ff or any all-zero or all-f pattern
• Client hostnames that do not match your expected endpoint naming conventions
• Cookie authentication followed immediately by requests to /ssl-vpn/hipreport.esp and /ssl-vpn/getconfig.esp from a new source IP

Rapid7 detection rules (for InsightIDR / MDR customers):

• Suspicious Authentication - Palo Alto GlobalProtect Cookie Authentication to Local Admin Account
• Threat Intel (Rapid7 MDR SOC/IR) - VPN Authentication via Spoofed MAC Address
• Suspicious VPN Authentication - Palo Alto GlobalProtect Login via Default Hostname
• Suspicious VPN Authentication - Local Account Logon via Generic Non-Human Identity
• Suspicious Authentication - Vultr
• Suspicious Authentication - Dromatics Systems

Checking If You Are Vulnerable Before Hunting

Before hunting for exploitation, check if your configuration is even vulnerable. Rapid7’s forge_cookie.py can tell you quickly:

# Run the PoC against your own appliance in a test window
python3 forge_cookie.py --target <your_gp_ip> --user testuser --verbose

If any certificate in your chain produces a successful cookie, you are vulnerable. This is the fastest way to understand your exposure without waiting for a full audit.

To check manually in the management UI:

• Portal: Network > GlobalProtect > Portals > [Portal Name] > Agent > [Config Profile] > Authentication tab
• Gateway: Network > GlobalProtect > Gateways > [Gateway Name] > Agent > Client Settings > [Profile] > Authentication Override tab

If either “Generate cookie for authentication override” or “Accept cookie for authentication override” is checked, and the certificate used is also used for the HTTPS service or any other feature, you are in scope.

Remediation and Workarounds

Option 1: Patch (Preferred)

Upgrade to a fixed PAN-OS version per the table in the affected versions section. After patching, the authentication override cookie generation uses a more secure method. All existing cookies will be invalidated on upgrade. Users will need to re-authenticate once. This is expected behavior and a one-time event.

The patch does not remove the authentication override feature. It changes the underlying cryptographic implementation so that forged cookies can no longer be constructed from a public key. Communication about the re-auth requirement to your user base before the upgrade window will prevent a helpdesk surge.

Option 2: Use a Dedicated Certificate for Authentication Override (Mitigation)

If patching immediately is not feasible, generate a certificate that is used exclusively for authentication override cookies and configure GlobalProtect to use it. This certificate must not be shared with the HTTPS service or any other feature. It should be generated fresh, not repurposed.

Steps:

1. Device > Certificate Management > Certificates > Generate
2. Create a new certificate with a name that makes its purpose obvious (e.g., GP-AuthOverride-Cert)
3. Do not install it as the HTTPS/SSL/TLS certificate for the portal or gateway
4. Configure the portal and gateway authentication override settings to reference this new certificate
5. Commit and deploy

The public key on this certificate is never exposed via a TLS handshake to the internet. An attacker cannot retrieve it, so they cannot forge cookies encrypted with it.

Option 3: Disable Authentication Override (Maximum Mitigation)

If the operational impact of disabling authentication override is acceptable (users will need to re-authenticate on every new GlobalProtect session), disabling the feature entirely removes the attack surface.

Portal: Network > GlobalProtect > Portals > [Portal] > Agent > [Config] > Authentication tab, uncheck both cookie options.

Gateway: Network > GlobalProtect > Gateways > [Gateway] > Agent > Client Settings > [Profile] > Authentication Override tab, uncheck “Accept cookie for authentication override.”

This is the cleanest option from a security standpoint. It is also the one with the highest operational friction.

Post-Exploitation Response Checklist

If you have confirmed or suspect exploitation occurred:

## Immediate Actions
- [ ] Determine if authentication override cookies were enabled and certificate was shared
- [ ] Pull GlobalProtect logs for the past 30+ days
- [ ] Search logs for Cookie-type authentications from unexpected sources
- [ ] Check for authentications to local admin accounts via cookie
- [ ] Identify any VPN IPs assigned from successful cookie authentications
- [ ] Review network traffic from those VPN IPs during the exploitation window

## Containment
- [ ] Apply mitigation (dedicated cert or disable auth override) immediately
- [ ] Rotate credentials for any local accounts that appeared in forged login events
- [ ] Revoke and reissue any certificates that were shared with the authentication override feature
- [ ] Block known attacker IPs at perimeter if not already covered by threat intel feeds
- [ ] Consider revoking all active GlobalProtect sessions and requiring full re-authentication

## Investigation
- [ ] Generate tech support file from affected appliance before any changes
- [ ] Identify all VPN IPs assigned to authenticated sessions from attacker source IPs
- [ ] Review internal network logs for activity from those VPN IPs
- [ ] Check for lateral movement: authentication attempts, SMB, RDP, or other protocol activity
- [ ] Assess what internal resources are reachable from the VPN IP pool
- [ ] Determine blast radius based on network segmentation

## Recovery
- [ ] Patch to fixed PAN-OS version
- [ ] Generate new dedicated certificate for authentication override if feature is retained
- [ ] Rotate all local credentials on the appliance
- [ ] Review certificate management practices across the environment
- [ ] Verify monitoring coverage for GlobalProtect authentication events going forward

Closing Assessment

CVE-2026-0257 is a clean vulnerability in a bad location. The technical mechanism is straightforward: RSA encryption without integrity verification, using a key that is publicly accessible. The design decision that enabled it was reasonable in isolation. The certificate used for authentication override cookie encryption was also used for TLS, because at the time of configuration, that seemed like a sensible centralization of certificate management. It turns out that decision made the public key available to anyone who could complete a TLS handshake with the appliance.

The four-day gap from disclosure to active exploitation, combined with CISA KEV addition and the CVSS revision from 4.7 to 7.8, tells a familiar story about edge device vulnerabilities: vendor scoring reflects the theoretical baseline. Operational reality accounts for the fact that GlobalProtect is the network perimeter. An authentication bypass in the network perimeter is not a medium-severity configuration issue. It is a door without a lock.

What makes this particularly uncomfortable from a forensic standpoint is how little the attacker leaves behind. The exploitation chain is a single authenticated HTTPS POST. No malware. No persistence mechanism. No files on disk. The session it creates looks identical to a legitimate VPN session in most of your downstream monitoring, because from the firewall’s perspective, it is legitimate. The attacker chose the username, chose the MAC, chose the client hostname, and the device believed all of it.

Detection depends heavily on hunting GlobalProtect authentication logs for cookie-based authentications that do not match expected behavior. The known IOCs from current in-the-wild activity are useful but not durable. A motivated attacker will vary source IPs and fake more convincing client metadata. The behavioral signal that matters most is cookie authentication to local admin accounts, which is something legitimate users almost never do and attackers almost always try.

Patch if you can. If you cannot patch immediately, isolate the authentication override certificate as described above. Either action eliminates the vulnerability. Doing nothing means you are relying on your perimeter to protect your perimeter, which is a philosophical problem as much as a technical one.

References

• Vendor Advisory: CVE-2026-0257 PAN-OS: GlobalProtect Authentication Bypass Vulnerabilities
• Rapid7 ETR / Observed Exploitation: Rapid7 Observed Exploitation of PAN-OS GlobalProtect Authentication Bypass Vulnerability
• Proof-of-Concept: sfewer-r7/CVE-2026-0257
• The Hacker News: PAN-OS GlobalProtect Authentication Bypass Under Active Exploitation