On 19 October, Palo Alto Networks’ Unit 42 updated its threat brief on CVE-2026-0257, a flaw that lets attackers bypass authentication on the GlobalProtect VPN component of PAN-OS firewalls. The flaw is not new. What changed is who is trying to use it, and what the brief says happens after the VPN door opens.
For a board, the useful question is not “are we patched?” It is “how far could someone get if we were not, and how would we know?”
What the update says
Unit 42 names two ransomware groups, Qilin and Inc, as attempting to exploit the flaw. It stops short of confirming a completed attack by either group, and it notes that only a small portion of the devices probed actually established VPN sessions. Unit 42 also cites public reporting linking a third ransomware family to the flaw, which it does not confirm.
The brief describes what happens after access is gained: attackers bypass multi-factor authentication to establish a VPN session, scout the network with remote management tools, move between systems, and prepare to steal data and deploy ransomware. In one case they moved from the VPN gateway to the server that manages the organisation’s virtual machines, switched off protections on the virtualisation hosts, and copied credentials from a copy of a domain controller’s disk. Attackers have also been seen combining this access with a known flaw in Veeam backup software.
In plain terms: one unpatched or misconfigured entry point can lead to the machines that run everything, and to the backups that would normally let you recover.
Question 1: How long did we take to fix it, and who confirmed it?
The flaw has been exploited since late spring. Ask management for the dates: when the fix was available, when it was applied to every firewall, and who verified it. “We patched” should mean evidence from a scan or configuration review, not a ticket status. Unit 42 also advises checking whether management interfaces are reachable from the internet, a separate exposure that patching does not remove.
Question 2: What would we see if someone had already logged in?
Unit 42 publishes specific indicators, including IP addresses and device names tied to successful logins, and recommends starting incident response for any match. Ask whether the security team has searched for them, over what time period, and what the result was. A “no matches” answer is good. “We have not checked” is not.
Question 3: How far could an intruder get from the VPN?
The most serious step in the brief is the move to the virtualisation management server. Ask whether the systems that control virtual machines are reachable from the VPN, whether they require separate credentials and multi-factor authentication, and when that separation was last tested. This is a design question as much as a patching question. If remote access leads straight to the control layer for the whole estate, the impact of any single entry point is much higher.
Question 4: Can we recover if the backups are targeted?
Attackers combining VPN access with a Veeam flaw are going after recovery capability. Ask when the backup software was last patched, whether backup systems are isolated from the main network, and whether at least one copy is offline or cannot be altered. Ask the last time a full restore was rehearsed and how long it took. Recovery time is a number the board can compare with its tolerance for downtime.
Question 5: Who decides, and how fast, when something is found?
If indicators match, someone has to decide whether to take the VPN offline, which affects remote staff and perhaps customers. That decision should be made in advance. Ask who holds the authority, what the trigger is, and whether regulators, insurers and counsel have been briefed on the notification route. Many disclosure and reporting obligations run on short clocks from the point of awareness, which is a further reason to settle this before an incident.
What to expect from management
A good answer to these five questions fits on one page and includes dates, owners and evidence. A weaker answer relies on assurances without proof. Watch for these signals:
- Patch status reported as a percentage, without naming the exceptions.
- No timeline for remediation.
- Confidence in a defence, such as MFA, that the brief says was bypassed in this case.
- Backups described as “in place” without a recent restore test.
What this does not tell us
We have not seen victim names or an estimate of how many organisations were affected, and Unit 42 does not provide one. Nothing in the brief says that any specific company, sector or region is being targeted more than another. The risk to your organisation depends on whether you run the affected product, whether it is fixed and configured safely, and how your network is designed behind it. The score and fixed-version details are in the vendor’s advisory, which your technical team should treat as the reference.
The takeaway
Ransomware groups are not waiting for new vulnerabilities. They use the ones that organisations have been slow to close, and they invest their effort in what comes after the first login. A board that asks about reach and recovery, not only about patching, is asking the question that decides how bad a breach becomes.
Sources
- Palo Alto Networks Unit 42, “Threat Brief: Active Exploitation of PAN-OS CVE-2026-0257” (updated 20 October 2026): https://unit42.paloaltonetworks.com/active-exploitation-of-pan-os-cve-2026-0257/