When a VPN vulnerability is actively exploited, it changes the priority list fast. This is not the week to debate long-term architecture. It is the week to get clear on what is exposed, patch what is vulnerable, and confirm nobody used the gap to walk in.

CVE-2026-0257 affects the GlobalProtect portal and gateway in certain PAN-OS versions, and it can allow an attacker to establish an unauthorised VPN connection. Palo Alto Networks has marked it as “ATTACKED”, which is their way of saying, “assume someone is trying this in the real world.”

First, confirm what you actually have exposed

A lot of businesses think they have “one VPN”, but in practice remote access grows extra branches over time. Before you touch upgrades, make sure you are not missing an entry point.

Inventory every remote access path into your environment:

  • GlobalProtect portal and gateway. These are the core components mentioned in the advisory, and they are often internet-facing.
  • Other VPN services. If you still have an older VPN method enabled “just in case”, treat it as a perimeter system too.
  • Vendor access paths. Think about outsourced accounting, software vendors, copier/printer support, building management, and any “temporary” remote access that became permanent.
  • Published admin interfaces. If anything administrative is reachable from the internet, include it in the same review.

The goal is simple: you want one written list of what is reachable from the outside, what it is for, and who owns it.

Check versions and match them to the advisory

Once you know which firewalls and gateways are in play, confirm the PAN-OS version on each one and compare it to the affected and fixed versions.

A few practical tips that help in real life:

  • Do not assume all sites match. Headquarters may be patched while a smaller office is still on an older release.
  • Do not confuse Panorama with the firewall version. Palo Alto notes that Panorama and Cloud NGFW are not impacted by this issue, but the firewall running the GlobalProtect portal or gateway is what matters.
  • Write down the target version before you start. The advisory lists multiple “fixed” versions across PAN-OS branches. Pick the correct fixed version for your current branch (or your planned upgrade path) and stick to it.

If you are unsure which device is actually hosting the portal or gateway, treat that as a red flag in itself. You should be able to answer that question quickly.

Apply emergency upgrades, and use the vendor’s workarounds if you cannot patch today

When exploitation is active, the cleanest outcome is: upgrade to a fixed PAN-OS version as soon as your change process allows.

But sometimes you cannot patch immediately (business hours, change freezes, hardware constraints, or you need to stage the update). If that is your situation, use the mitigations Palo Alto provides while you plan the upgrade.

From Palo Alto’s CVE-2026-0257 advisory, one key mitigation is to disable Authentication Override options related to generating and accepting cookies in the GlobalProtect portal and gateway configuration.

A practical way to run this as a business-safe change:

  • Pick a maintenance window, even if it is short. You are changing remote access behaviour, so you want a defined window and a rollback plan.
  • Communicate impact in plain language. For example: “You may be prompted to sign in again,” or “VPN may briefly disconnect.”
  • Stage the upgrade package ahead of time. Do the download, verify you have space, and confirm you have console access if something goes sideways.

If you have cyber insurance or compliance obligations, log the dates and times of mitigations and patches. You want a clear record of what you did and when.

Review logs for suspicious sessions (focus on “who connected”)

With an authentication bypass, your question is not only “did someone probe us?” It is “did anyone successfully establish a VPN session who should not have been able to?”

Palo Alto’s Unit 42 published a threat brief on observed exploitation and includes specific indicators to hunt for in GlobalProtect logs, including a list of IP addresses to search for and guidance to look for successful gateway-connected events.

What to look for in your GlobalProtect logs:

  • Gateway-connected events. These are the sessions that actually established a connection.
  • Source region and public IP. GlobalProtect logs include fields like source region and public IP, which help you spot “this user never signs in from there.”
  • Host ID and machine name. If you see an unfamiliar device name for a known user, pause and investigate.
  • Client version and OS details. Useful for spotting odd combinations that do not match your fleet.
  • Unusual login duration. Very short connects in a tight pattern can indicate automated testing. Very long connects from an unexpected location can indicate persistence.

If you have central logging (SIEM), pull these logs there as well. If you do not, export what you can now. During a busy response week, logs are the first thing to get overwritten.

Consider temporarily tightening split tunnelling and location-based access

When you are dealing with an actively exploited perimeter issue, it is reasonable to temporarily reduce “degrees of freedom” in remote access. The trade-off is user convenience versus containment.

Two options that often help, depending on your setup:

  • Disable split tunnelling (or reduce exclusions). Split tunnelling can be useful for performance, but it means some traffic bypasses inspection and policy enforcement. If you suspect unauthorised access, routing more traffic through your controls can make investigation and containment simpler.
  • Restrict access by location. If your workforce is primarily in the US, and you suddenly see authentication attempts from other countries, geo-based restrictions can cut noise quickly. Prisma Access documentation describes blocking incoming connections from specific countries using policy rules, and similar geo controls exist in PAN-OS policy objects.

Do not treat geo-blocking as a “security silver bullet”. It is a practical speed bump, and it can also block legitimate travellers. If you enable it, pair it with a clear exception process.

The calm takeaway

When a perimeter VPN flaw is being exploited, the right response is boring and disciplined: inventory exposure, verify versions, apply emergency upgrades or vendor mitigations, then review GlobalProtect logs for suspicious gateway-connected sessions.

If you would like help verifying your exposure, planning a safe emergency upgrade, or reviewing GlobalProtect logs for suspicious sessions, the Flexnet Networks team can help you run that response cleanly.

Sources