CVE-2026-0257 is an authentication bypass in the GlobalProtect portal and gateway of Palo Alto Networks PAN-OS, patched in May 2026. Unit 42 now says Qilin and Inc ransomware operators use it for initial access. If your firewalls accept authentication override cookies, upgrade to a fixed build, end existing VPN sessions and hunt for intrusion.
That last step is the one teams skip. The flaw was fixed five months ago and has been in CISA's Known Exploited Vulnerabilities catalog since late May, according to Rapid7 and BleepingComputer. What changed in October is who is using it and what they do once inside. A VPN session that looks like a remote worker can turn into domain-wide encryption.
This post covers what the vendor and named researchers report, how to check exposure, what to hunt for, and what would have helped. It is not about CVE-2026-0322, the separate PAN-OS management interface flaw added to KEV on 14 October. That one is covered in our post on edge device zero days in October 2026.
What happened
The story has two phases. In May, exploitation looked like opportunistic VPN access with no follow-on activity. From June onward, researchers began tying it to ransomware.
| Date (2026) | Event | Source |
|---|---|---|
| 13 May | Palo Alto Networks publishes the CVE-2026-0257 advisory and fixed builds. It is first rated medium (CVSS v4.0 4.7) | Palo Alto Networks, Rapid7 |
| 17 May | Earliest exploitation Rapid7 observed | Rapid7 |
| 18 May | First wave seen by Rapid7 MDR, from Vultr-hosted infrastructure | Rapid7 |
| 21 May | Second wave, from Dromatics Systems infrastructure; some victims are assigned VPN IP addresses | Rapid7 |
| 29 May | Palo Alto raises the rating to high (CVSS v4.0 7.8) after "limited exploit attempts". CISA adds the CVE to KEV with a federal due date of 1 June | Palo Alto Networks, Rapid7, BleepingComputer |
| 3 Jun | Palo Alto adds an FAQ on phased upgrades and certificates | Palo Alto Networks |
| Early Jun | Unit 42 incident response investigations involving the flaw begin | Unit 42 |
| Jun | Intrusions that start with CVE-2026-0257 and end in Qilin ransomware, published by Arctic Wolf on 20 July | Arctic Wolf |
| 9 Oct | ReliaQuest warns that Qilin and Settra ransomware groups are exploiting the flaw | Infosecurity Magazine |
| 19 Oct | Unit 42 names Spikey Scorpius (Qilin) and Tarnished Scorpius (Inc) as operators exploiting it | Unit 42 |
| 20 Oct | Unit 42 adds verification and remediation guidance on management interface exposure | Unit 42 |
What is disputed or unclear
- KEV date. Rapid7, BleepingComputer and Infosecurity Magazine report that CISA added CVE-2026-0257 to KEV on 29 May with a 1 June federal deadline. Unit 42's brief says 13 May, which is the date of Palo Alto's advisory. We could not load CISA's catalog when writing this, so we cite the reports that quote it.
- Lateral movement. Rapid7 saw "no indication of successful lateral movement" in its May cases, and Unit 42's summary still says no post-access behaviour had been identified. Unit 42's own 19 October update, Arctic Wolf and ReliaQuest describe reconnaissance, credential theft and ransomware after access. Both statements can be true: the early waves stopped at the VPN, and later operators did not.
- Severity. The base score is 7.8 (high). Palo Alto gives it its highest suggested urgency, and some outlets call it critical. Rapid7 recommends treating it as critical.
- Settra. Unit 42 mentions Settra ransomware only by citing ReliaQuest's public reporting. We found no independent confirmation.
- Victims. No source we read names a victim organisation or gives a victim count.
Who is affected
Exposure depends on configuration, not just version. Per Palo Alto's advisory, the flaw affects firewalls with a GlobalProtect portal or gateway where authentication override cookies are enabled and a specific certificate configuration exists. Rapid7 notes the feature is not on by default, and the advisory's workaround points at the certificate used to protect those cookies: it should be dedicated to that job and not shared with other services.
| Product | Status | Fixed builds (per Palo Alto) |
|---|---|---|
| PAN-OS 12.1 | Affected | 12.1.4-h6, 12.1.7 and later |
| PAN-OS 11.2 | Affected | 11.2.4-h17, 11.2.7-h14, 11.2.10-h7, 11.2.12 and later |
| PAN-OS 11.1 | Affected | 11.1.4-h33, 11.1.6-h32, 11.1.7-h6, 11.1.10-h25, 11.1.13-h5, 11.1.15 and later |
| PAN-OS 10.2 | Affected | 10.2.7-h34, 10.2.10-h36, 10.2.13-h21, 10.2.16-h7, 10.2.18-h6 and later |
| Prisma Access 11.2 | Affected | 11.2.7-h13 and later, rolled out by Palo Alto on a customer schedule |
| Prisma Access 10.2 | Affected | 10.2.10-h36 and later, rolled out by Palo Alto on a customer schedule |
| Cloud NGFW | Not affected | No action |
| Panorama | Not affected | No action |
Each hotfix line covers its own maintenance train. A device on 11.1.9, for example, needs 11.1.10-h25 or 11.1.15, not 11.1.6-h32. Read the Solution table in the advisory for your exact train. Older PAN-OS releases that are out of support have no fix; Palo Alto says to move to a supported fixed version.
Unit 42's investigations span education, financial services, healthcare, government, manufacturing, utilities and many other sectors. In practice, any organisation that runs GlobalProtect is a candidate.
How it works, without the exploit
GlobalProtect can issue a cookie after a user signs in, so the client can reconnect later without asking for credentials again. That is the authentication override feature. Palo Alto classifies the weakness as CWE-565, reliance on cookies without validation and integrity checking. In plain terms, under the affected configuration the gateway could accept a cookie it should not trust, and an unauthenticated attacker could get a VPN connection.
Rapid7 reports that the May attacks targeted a local administrator account. In 8 of its 10 affected MDR customers, authentication was accepted but no full VPN session followed. In the others, the attacker got a VPN address on the internal network.
The fix changes how override cookies are generated and validated. Palo Alto says every GlobalProtect user must sign in again once after the upgrade, even with a valid cookie. That is expected, so warn your help desk.
From VPN session to ransomware
The interesting part of this incident is what happens after the edge device. A VPN session is the start of an intrusion, not the end. The reports describe a familiar chain.
- Access. The attacker establishes an unauthorised GlobalProtect session. Unit 42 says the session sidesteps multi-factor authentication. To the network, it looks like a remote user.
- Reconnaissance. Unit 42 describes dual-use remote monitoring and management tools for internal discovery. ReliaQuest saw Cobalt Strike, BloodHound and SharpHound, according to Infosecurity Magazine.
- Persistence. Arctic Wolf found registry Run keys, a scheduled task tied to MeshAgent, and remote access tools such as AnyDesk, Ngrok and LogMeIn.
- Credential theft. Arctic Wolf describes LSASS memory dumping and extraction of the Active Directory database (NTDS.dit), which exposes every domain credential.
- Lateral movement. RDP and SMB, per Unit 42. Arctic Wolf saw PsExec over administrative shares.
- Defence evasion. Event log clearing and disabling of Microsoft Defender real-time protection in some cases, per Arctic Wolf.
- Backups and virtualisation. Unit 42 calls the "direct pivot to the virtualization layer" the most significant change in tactics: attackers reached a vCenter appliance and disabled security controls on ESXi hosts. Unit 42 also saw access chained with tools that target Veeam backup infrastructure, including CVE-2023-27532.
- Exfiltration. Arctic Wolf saw data moved mainly to MEGA with Rclone, with ProtonDrive and FileZilla in other cases. Some intrusions skipped exfiltration.
- Encryption. Arctic Wolf found a password-gated payload staged in
C:\PerfLogs\and a per-intrusion file extension it describes as typical of Qilin.
Arctic Wolf does not give dwell times. It says some intrusions moved to encryption "with minimal dwell time", while others involved longer reconnaissance and theft. Its Qilin attribution is an analytical judgement, and it notes the varying tradecraft suggests more than one affiliate.
Two lessons follow. If an attacker can reach vCenter and Veeam from a VPN address, your restore plan is part of the attack surface. And a patched firewall does not end any of this. Infosecurity Magazine sums up the warning: "Patching alone may not remove access established before remediation."
What to do now
Follow Palo Alto's advisory and Unit 42's brief for your environment. The checklist below orders their guidance and adds the hunting steps Arctic Wolf and Rapid7 recommend.
-
Read the version on every firewall. On each device, or from Panorama for managed firewalls:
> show system info | match sw-versionCompare the result with the fixed builds in the table above and the advisory's Solution table.
-
Check whether authentication override is in use. In the web interface, the advisory points to the portal's Agent configuration, Authentication tab ("Generate cookie for authentication override" and "Accept cookie for authentication override") and the gateway's Client Settings, Authentication Override tab ("Accept cookie for authentication override"). From the CLI:
> set cli config-output-format set > configure # show | match authentication-overrideIf nothing comes back, override cookies are most likely off; confirm in the web interface and upgrade anyway.
-
Upgrade to a fixed build. Upgrade all portals and gateways that generate or accept override cookies, internal and external, as one change. The advisory warns that mixing old and new builds breaks cookie compatibility. For phased rollouts, Palo Alto documents a temporary setting on already upgraded firewalls, then a return to strict validation when everything is done:
set global-protect enable-auth-override-cookie-hmac no # after every portal and gateway is upgraded set global-protect enable-auth-override-cookie-hmac yes -
If you cannot upgrade today, apply a workaround. Palo Alto lists two: disable authentication override on portals and gateways, or generate a new certificate used only for override cookies. A certificate that was ever used for anything else must be replaced, even if you removed it from those services.
-
End existing sessions. Arctic Wolf and ReliaQuest advise terminating active GlobalProtect sessions after patching. List current users first:
> show global-protect-gateway current-userPalo Alto's XML API documents a client logout per user, gateway and computer:
curl -X POST 'https://<firewall>/api?type=op&key=<api-key>&cmd=<request><global-protect-gateway><client-logout><gateway>GW-NAME</gateway><user>USERNAME</user><reason>force-logout</reason><computer>HOSTNAME</computer></client-logout></global-protect-gateway></request>' -
Hunt in GlobalProtect logs. Unit 42 lists nine IP addresses from pre-proof-of-concept activity to search for successful logins, plus suspicious MAC addresses and device names to search in gateway-connected events from any source IP. Rapid7 adds cookie-based logins to local admin accounts, logins from hosting provider ranges, default or unexpected hostnames, mismatched OS strings and a spoofed MAC address. ReliaQuest flagged the hostname "kali", according to Infosecurity. Take the indicator values from those pages directly; they get updated.
-
Check management interface exposure. Unit 42's 20 October update says organisations often mapped GlobalProtect profiles to HTTP and HTTPS services on their management interfaces. From a network outside yours, try ports 4443 and 3879 on the management IP:
curl -skI --max-time 5 https://<mgmt-ip>:4443/ curl -skI --max-time 5 https://<mgmt-ip>:3879/Any answer other than a timeout means the interface is reachable. Restrict it with Interface Management profiles, as Unit 42 recommends. This is also the exposure that made CVE-2026-0322 dangerous.
-
If you find a match, start incident response. Unit 42 says to activate it for any successful gateway-connected event that matches the indicators. Do not wipe the firewall first. Preserve logs and a tech support file.
-
Hunt inside the network. Look for what Arctic Wolf and Unit 42 describe. On Windows hosts, cleared security logs (Event ID 1102), unexpected files in
C:\PerfLogs\, and new services from PsExec:Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} -MaxEvents 20 Get-ChildItem -Path C:\PerfLogs -Recurse -Force -ErrorAction SilentlyContinue Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} -MaxEvents 50 | Where-Object { $_.Message -match 'PSEXESVC' }Also check RMM installs you did not approve, Rclone or large uploads to cloud storage, logins to vCenter and ESXi from VPN address pools, and access to your Veeam servers.
-
Rotate credentials if anything looks wrong. Arctic Wolf recommends rotating domain admin and service accounts and resetting the KRBTGT account twice. Rotate the local GlobalProtect accounts that Rapid7 saw targeted, and any credentials stored on the firewall.
-
Isolate backups. Confirm that backup servers and the hypervisor management plane are not reachable from VPN address pools, and that at least one backup copy is offline or immutable.
What would have helped
We do not know the configuration or patch history of any affected organisation, and none are named. These are practices that reduce damage for any team running a VPN gateway.
Practices any team can use
Patch KEV entries on edge devices first. This flaw was fixed on 13 May and in KEV by 29 May. The ransomware use came months later. A rule of "every KEV entry on an internet-facing device gets fixed within days, with an owner and a date" would have closed the door for most organisations.
Know your feature flags, not just your versions. Exposure here depended on authentication override and certificate reuse. Keep a record of which risky features each firewall has turned on, and why. Remove the ones nobody can justify.
One certificate, one job. The workaround is a certificate used only for override cookies. The same habit applies to every appliance: do not reuse a TLS certificate across services that have different trust needs.
Treat VPN users as untrusted until proven otherwise. Give VPN address pools access only to what remote staff need. The domain controller, vCenter, ESXi and the backup server should not be reachable from a generic VPN pool.
Keep the management plane off the internet. Unit 42's latest guidance is about management interfaces exposed through GlobalProtect profiles. The same rule appears in our edge device post.
Make patching end with a hunt. Patch, end sessions, hunt, rotate. Our October incident roundup uses the same order.
Backups the attacker cannot reach. Arctic Wolf and Unit 42 both saw Veeam targeted. Keep an offline or immutable copy, patch the backup server like an edge device, and test restores. Our IDCF Cloud ransomware post covers backup independence.
Control remote access tools and keep logs off the host. AnyDesk, MeshAgent, Ngrok and LogMeIn all appeared in Arctic Wolf's cases; allow list the ones you use. Forward Windows and firewall logs to a central store and alert on Event ID 1102.
Where Safeguard fits
Limits first. Safeguard does not scan vendor firewall firmware. It would not have flagged a PAN-OS version, read your GlobalProtect settings, detected a forged session or stopped ransomware. It does not watch network traffic or manage backups. For the firewall itself, rely on Palo Alto's advisory and your network team's inventory.
Where it helps is the software you build and run behind that firewall, which you will be checking and rebuilding during recovery.
Inventory and SBOMs. Safeguard generates SBOMs and scans dependencies in repositories, container images and existing SBOM files: safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>, with JSON results under ./output. After an intrusion, that gives you a record of what each internal service should contain, and the platform shows which projects carry a given component and version.
Prioritised patching. Components are matched against vulnerability databases, with reachability analysis, so you fix the internal apps that matter first while the network team works on the edge. Policies and gates, evaluated in the platform, can stop a rebuilt service from shipping with a known exploited flaw.
Approved changes during recovery. The Safeguard CLI's assistant can edit code and run commands with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. Use Ask or Strict during an incident. Autonomous fix PRs exist and are off by default. safeguard exec runs in CI. The desktop and phone apps can send work to a computer running the CLI and ask you to approve each command, which leaves a record of who allowed what.
None of this would have prevented the initial access in this incident.
Zero-Day Discovery and Gold
Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. Firewall operating systems such as PAN-OS are outside that scope, and it played no part in finding this flaw.
Gold Open Source (gold.safeguard.sh) is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or above, Sigstore-signed, with evidence pages. An artifact loses its badge if it regresses.
Gold does not replace a firewall vendor's advisory. The habit it supports is the one that matters after a ransomware intrusion: rebuild internal services from patched, signed components from a curated source, instead of restoring images that were running while an attacker had domain admin.
Common mistakes
- Patching and stopping there. Sessions and stolen credentials outlive the fix. Rapid7, Arctic Wolf and ReliaQuest all say to look for prior access.
- Upgrading one gateway at a time without the HMAC setting. Mixed builds break override cookies. Plan the upgrade as one change or use Palo Alto's phased setting.
- Keeping the old certificate. The advisory says a certificate ever used elsewhere must be replaced, not just removed from other services.
- Confusing this with CVE-2026-0322. That flaw needs management interface credentials. CVE-2026-0257 needs none, if override cookies and the certificate condition are present.
- Treating "not exploited at our site in May" as safe now. Unit 42 and ReliaQuest describe exploitation continuing into October, and ReliaQuest expects it to go on.
- Restoring from backups without checking them. Attackers went after Veeam. Verify backup integrity and restore into a clean network.
FAQ
What is CVE-2026-0257?
An authentication bypass in the GlobalProtect portal and gateway of PAN-OS. Under a specific configuration, it lets an unauthenticated attacker establish a VPN connection. Palo Alto rates it 7.8 under CVSS v4.0 and fixed it on 13 May 2026.
Which ransomware groups are using it?
Unit 42 names Spikey Scorpius, also known as Qilin, and Tarnished Scorpius, also known as Inc. ReliaQuest reports Qilin and Settra. Arctic Wolf documented June intrusions that ended in Qilin ransomware.
Is CVE-2026-0257 in CISA's KEV catalog?
Yes. Rapid7, BleepingComputer and Infosecurity Magazine report it was added on 29 May 2026 with a federal deadline of 1 June. Unit 42's brief gives 13 May.
Are we affected if we do not use authentication override cookies?
Palo Alto's advisory ties exposure to authentication override cookies plus a specific certificate configuration. Without override cookies, the described condition is not met. Upgrade anyway, because configurations change and fixed builds carry other fixes.
Is Panorama, Prisma Access or Cloud NGFW affected?
Panorama and Cloud NGFW are not affected. Prisma Access 11.2 and 10.2 are, and Palo Alto is upgrading those tenants on a schedule it shares with customers. Hybrid deployments need their on-premises firewalls upgraded too.
How is this different from CVE-2026-0322?
CVE-2026-0322 is an authenticated code injection flaw in the PAN-OS management interface, added to KEV on 14 October. CVE-2026-0257 targets GlobalProtect and needs no credentials under the affected configuration. Unit 42's newest guidance touches both, because GlobalProtect profiles mapped to management services expose the management interface.
We patched in May. Do we still need to do anything?
Check your logs from 13 May to the day you patched, because Rapid7 saw exploitation from 17 May. If you see a match, treat it as an incident and hunt inside the network.
Would Safeguard have prevented this?
No. Safeguard does not scan firewall firmware or detect VPN intrusions. It helps you inventory, patch and rebuild the software behind the firewall, with approvals on each change.
Fix it without waiting for upstream
In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.
1. Autonomous remediation: pull requests, not tickets
When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.
2. Gold Open Source: the safe version in seconds, free
gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.
3. Gold Registry: start from components that are already fixed
registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.
When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.
| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | The Gold scan GitHub Action in CI, plus Safeguard policies and gates |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch (early access) |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |
One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.
See how Safeguard would have helped
None of these demos show this incident or a firewall. Each shows a real flow you would use while rebuilding the services behind it.
The first demo is a CLI session that fixes a lodash CVE: it reads the finding and the advisory, asks before each command, edits package.json, runs the install and tests, and pushes nothing. After a ransomware intrusion, you would run the same scan against each internal service you plan to rebuild and ask the assistant to bump vulnerable components, approving each command.
Click through it at your own pace, or open it full screen.
The second demo is a desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then approve or deny each command and file edit until the upgrade is done and tests pass. During recovery, an engineer on a clean machine would work the same way, and the approvals record what changed before a service goes back on the network.
Click through it at your own pace, or open it full screen.
The third demo is an Android session that sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. In an incident where credentials may be stolen, keeping a human approval on every change matters, and the incident lead can give it from anywhere.
Click through it at your own pace, or open it full screen.
To try it on your own repositories, download Safeguard and follow the CLI docs.
Quick check
Which two settings does Palo Alto give as workarounds if you cannot upgrade yet?
Disable authentication override on GlobalProtect portals and gateways, or use a new certificate dedicated only to override cookies and not shared with any other service.
Why is patching not enough on its own?
An attacker who already had a VPN session may have stolen credentials, installed remote access tools or reached backups. Researchers advise ending sessions, hunting for prior access and rotating credentials after the upgrade.
Sources
- Palo Alto Networks: CVE-2026-0257 PAN-OS GlobalProtect Authentication Bypass Vulnerabilities
- Unit 42: Threat brief on active exploitation of PAN-OS CVE-2026-0257
- Rapid7: Observed exploitation of PAN-OS GlobalProtect authentication bypass (CVE-2026-0257)
- Arctic Wolf: Cookie Crumbles, how exploitation of CVE-2026-0257 leads to Qilin ransomware
- Palo Alto Networks: Show and manage GlobalProtect users (API)
- BleepingComputer: Palo Alto GlobalProtect VPN auth bypass flaw now exploited in attacks
- Infosecurity Magazine: Months-old Palo Alto VPN vulnerability remains a target for ransomware groups
- Security Affairs: CISA adds Palo Alto Networks PAN-OS flaw to its Known Exploited Vulnerabilities catalog
Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.