Palo Alto's CVE-2026-0257 advisory was 149 days old when ReliaQuest warned ransomware groups still use it

149 days from the advisory to the warning

Palo Alto Networks published its advisory for CVE-2026-0257 on 13 May 2026. Infosecurity Magazine reported on 12 October that ReliaQuest had warned on 9 October that multiple ransomware groups, naming Qilin and Settra, "are actively targeting" the flaw to establish unauthorised VPN sessions and reach internal networks. From 13 May to 9 October is 149 days (derived). The US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) catalogue on day 16, 29 May, with a due date three days later, 1 June (derived), and the entry in catalogue version 2026.10.08, released on 8 October, carries "Known" in its field for ransomware campaign use.

The question is not new or clever. It is whether each of your GlobalProtect gateways is on a fixed version of its train, whether authentication override cookies are enabled on it, and whether anyone has read its session logs since 13 May. The record does not say how many gateways are still unpatched. It does not let a reader check ReliaQuest's attribution, because its own advisory was posted on social media and was not read. It names no victim. And it does not say whether multi-factor authentication on the gateway changes anything against this flaw.

A note on the count, because the slug on this briefing asks for it to be checked. 149 days is correct counted from the advisory's publication. It is an upper bound on the age of the fix for any one gateway, because the advisory's own timeline records updates to the "Fix release timeline" of individual versions between 14 and 28 May. Counted from 28 May, the last of those updates, the figure is 134 days (derived). The warning is also not the first tie between this flaw and ransomware: Arctic Wolf reported Qilin intrusions on 20 July, 68 days after the advisory and 81 days before ReliaQuest's warning (derived).

How this was read. Between 11:14 and 11:31 BST on Monday 12 October 2026 the Palo Alto Networks advisory (page and machine-readable record), the National Vulnerability Database (NVD) record and its change history, the CISA KEV catalogue file, the Rapid7, Unit 42 and three Arctic Wolf posts, SOCRadar's report, the Siemens advisory and the UK pages in the UK section were read in full. ReliaQuest's own advisory was not found: Infosecurity says it was a social media post, no ReliaQuest page for it turned up in the company's blog index, its threat research page or a web search, and no social platform was logged into. Everything attributed to ReliaQuest below is Infosecurity's report of it, named as such.

Interest, in one sentence: Palo Alto Networks sells the product and the Unit 42 service, and Rapid7, Arctic Wolf, ReliaQuest and SOCRadar sell detection, response or threat intelligence, so each gains from a finding that more organisations should be watching.

The record on a scale

What the scale shows. Every report about exploitation and scoring in this story except the last four falls in the first 29 days, 29 of 152 days or 19 per cent (derived). The first tie to ransomware arrives on day 68. The warning on day 149 repeats that tie with a second group name. Two of the dots on the axis rest on a source other than the vendor or the agency: the rescore from 4.7 is reported by Rapid7 and Arctic Wolf, and the 20 July date for CISA's ransomware flag by BleepingComputer.

A public proof of concept has existed since 29 May according to Unit 42, which dates its "pre-Proof of Concept" activity to before that day, and Rapid7's post of the same date describes a public script developed by its research arm. Neither is linked or described here. For a defender the practical effect is that exploitation does not need a skilled actor, which fits Arctic Wolf's description of the activity as opportunistic across hundreds of devices.

What each source says about exploitation, and what it leaves out

Infosecurity's article names "attempted exploitation" by Rapid7, Unit 42 and Arctic Wolf. The primaries say more than that, and in places something different. The table follows each primary, not the article.

What each source states about exploitation of CVE-2026-0257 and what it does not. Days are counted from 13 May 2026 (derived). ReliaQuest is as Infosecurity reports it.

Source and day	Stated	Not stated
Palo Alto Networks advisory, day 0, status updated day 16	"Limited exploit attempts on unpatched PAN-OS devices without mitigations applied". Exploit maturity "Attacked".	Who, how many, whether any succeeded, any victim.
Rapid7, day 16 (post 29 May)	Successful exploitation across "numerous customers"; earliest observed on 17 May (day 4); no successful lateral movement seen. In 8 of 10 impacted managed-detection customers the appliance accepted a forged cookie without a full VPN session.	The actor, and any number of customers beyond "numerous" and the ten.
Unit 42, day 27 (9 June)	Active exploitation by "an unidentified threat actor". Only a small portion of probed devices established VPN sessions. No post-access behaviour or lateral movement identified.	A count of probed devices, a victim, any later update (the brief says it will be updated; the version read is the 9 June one).
Arctic Wolf, days 22 and 29 (4 and 11 June)	A smaller wave on 17 to 21 May, then a rise from 30 May. Successful logins across "hundreds of devices" in several sectors, in Europe and North America. A subset went on to a tunnel and, within about a minute, internal scanning of the Impacket kind. Arctic Wolf says it disrupted this before persistence.	Victims by name, a UK victim, any ransomware (not in these two posts).
Arctic Wolf, day 68 (20 July)	Arctic Wolf investigated "multiple distinct intrusions during June 2026" that ended in domain-wide Qilin encryption, entry through the flaw "confirmed or assessed". Tradecraft varied, "possibly" more than one affiliate. Moderate confidence the activity is ongoing.	How many victims, who they are, which were confirmed and which only assessed.
SOCRadar, day 134 (24 September)	One actor, a fraud operation and not ransomware, with working VPN sessions on 7 gateways in four countries. Scan logs dated three months after disclosure.	A count of vulnerable gateways. The scan list is one actor's, not a census.
ReliaQuest, day 149 (per Infosecurity)	Qilin and Settra "actively" targeting the flaw; offensive tools seen after access (Cobalt Strike, BloodHound, SharpHound); "highly likely" to continue for three months.	Its own page; whether the observation is its customers, its incident response or others' reporting; how many intrusions; any Settra link in another source.

One more row of the story sits outside the table. NVD's record cites a Siemens advisory listing the same CVE for the RUGGEDCOM APE1808, an industrial application-hosting platform that can run a Palo Alto virtual firewall; Siemens says to upgrade the virtual firewall to 11.2.10-h7 and to contact customer support for the patch. A GlobalProtect gateway can therefore sit inside a supplier's hardware that nobody in the firewall team owns.

What the advisory says: trains, fixed versions and the configuration condition

Infosecurity lists the affected versions as PAN-OS 10.2.0, 11.1.0, 11.2.0 and 12.1.0 and two Prisma Access versions, 10.2.0 and 11.2.0. Read against the advisory and its machine-readable record, those are the first version of each train, not the affected versions. Each train is affected up to a fixed version that depends on the minor release a gateway runs. A gateway on 11.2.9, for example, should move to 11.2.10-h7 or 11.2.12, not to the fix numbered for 11.2.4.

Fixed versions listed in Palo Alto Networks' advisory for CVE-2026-0257, as read on 12 October 2026. Counts are derived. Cloud NGFW and Panorama are stated as not affected.

Train	Fixed versions the advisory lists	How many
PAN-OS 12.1	12.1.4-h6; 12.1.7 or later	2
PAN-OS 11.2	11.2.4-h17; 11.2.7-h14; 11.2.10-h7; 11.2.12 or later	4
PAN-OS 11.1	11.1.4-h33; 11.1.6-h32; 11.1.7-h6; 11.1.10-h25; 11.1.13-h5; 11.1.15 or later	6
PAN-OS 10.2	10.2.7-h34; 10.2.10-h36; 10.2.13-h21; 10.2.16-h7; 10.2.18-h6	5
Prisma Access 11.2.0	11.2.7-h13, applied by the vendor on a schedule shared with customers	1
Prisma Access 10.2.0	10.2.10-h36, applied by the vendor on a schedule shared with customers	1

So all four named PAN-OS trains have a fixed version, 4 of 4, and so do both Prisma Access trains, 2 of 2 (derived). Across PAN-OS that is 17 fixed versions, and the advisory tells a gateway on a minor release to take the one built for its line or a later release. Versions older than those lines get one instruction: "Upgrade to a supported fixed version." The advisory's timeline records fix-release-timeline updates for 11 of the 17 PAN-OS fixed versions, dated 14 to 28 May (derived). It does not say whether those dates are the release dates, and it gives no date for the other six, so how old the fix for your line is cannot be read from the page.

The configuration condition is the part most summaries drop. The advisory says the issue affects firewalls with a GlobalProtect portal or gateway "when authentication override cookies are enabled and a specific certificate configuration exists", and it gives menu steps for checking the first part. It does not describe the certificate condition. Its mitigation does: use a dedicated certificate for authentication override cookies and do not reuse the portal or gateway certificate. Rapid7 and Arctic Wolf both read that as the condition, and say authentication override is not enabled by default. That reading is theirs, not the advisory's.

The two workarounds the advisory gives are to use a dedicated certificate for authentication override cookies, or to disable authentication override. Its FAQ adds three constraints that matter for a rollout. Asked whether all GlobalProtect components must be upgraded at the same time, it answers yes for every portal and gateway, internal and external, that generates or accepts cookies, to avoid cookie compatibility problems. A hybrid Prisma Access deployment must have its on-premises firewalls upgraded to a fixed version. After an upgrade, users re-authenticate once, because the fix regenerates the cookie "using a more secure method". For a phased upgrade the FAQ offers a setting that returns an upgraded firewall to the legacy cookie behaviour until the rest are done, and says it must then be switched back on to enforce the fix. A gateway left in that state shows a fixed version number and does not enforce the fix.

What the flaw lets a remote user do, in the advisory's words: "bypass security restrictions and establish an unauthorized VPN connection". Nothing more is stated. Its vector scores the firewall's own confidentiality impact as low and integrity as none, and the systems behind it as high and high, which reads as the vendor placing the harm in what the session reaches (inference). The advisory credits Palo Alto Networks' own research teams with finding it.

"Patched" is a vendor date, not a state of your gateway

The friendly name here is "patched". On the vendor's side it is true from 13 May for some trains and from late May for others, if the timeline entries are release dates. On your side it is a property of each gateway: the version it runs, whether every portal and gateway that shares cookies was upgraded, whether a hybrid tenant's on-premises firewall was included, whether a supplier's embedded firewall was covered, and, after a phased upgrade, whether the strict cookie setting was switched back on. A fleet list that says "PAN-OS upgraded" and a gateway still on an unfixed minor release are both easy to have at once.

Patching also does not end what happened before it. ReliaQuest, in Infosecurity's report, says "patching alone may not remove access established before remediation" and advises terminating all active GlobalProtect sessions after patching. Arctic Wolf gives the same advice and adds that if exploitation is confirmed a defender should assume domain-level compromise. The advisory says users re-authenticate after an upgrade. It does not say an upgrade ends sessions already open or removes anything an intruder left elsewhere.

"High" or "critical": four scores for one flaw, and what each measures

Infosecurity reads as though Palo Alto allocated 7.8 and urgency "highest" when it disclosed the flaw on 13 May, and says NVD's enrichment team gave 9.1. The vendor's page and NVD's change history put the date of the 7.8 later. At publication the vendor's vector carried exploit maturity "unreported" and an urgency of amber. On 29 May at 18:16 UTC the vendor replaced it with exploit maturity "attacked" and urgency red. Rapid7 and Arctic Wolf report the score before that as 4.7, medium, and the advisory's FAQ confirms a change, saying the score "increases when proof-of-concept (PoC) exploits are publicly disclosed or when active attacks targeting the vulnerability are observed". NVD added its own 9.1 at 20:14 UTC the same day. The article follows the vendor page and NVD's record, not the date in the article.

Scores published for CVE-2026-0257 and what differs. Vendor and NVD figures from NVD's record and change history and the vendor advisory; the 4.7 is as reported by Rapid7 and Arctic Wolf and was not recomputed. 9.1 and 9.3 were recomputed from their vectors (derived).

Assigned by	Scale and score	Date	What is different
Palo Alto Networks, at publication	CVSS 4.0, 4.7 medium (reported)	13 May	Exploit maturity "unreported".
Palo Alto Networks, from 29 May	CVSS 4.0, 7.8 high; urgency highest	29 May	Only exploit maturity and urgency changed. Technical impact metrics did not.
NIST NVD	CVSS 3.1, 9.1 critical	29 May	Scope unchanged; confidentiality and integrity both high on the vulnerable component.
Siemens, for its hardware advisory	CVSS 3.1, 9.3; CVSS 4.0, 7.8	Updated 14 July	User interaction required and scope changed in its 3.1 vector.

Read the vectors and the disagreement is narrower than the numbers suggest. Attack vector is network, attack complexity low, privileges required none and user interaction none in the vendor's and NVD's vectors alike, so both agree the flaw is easy to reach and needs no account. They differ in how they count the damage. NVD's 3.1 vector, which has a scope metric, marks confidentiality and integrity high on the same component. The vendor's 4.0 vector, which has no scope metric, separates the firewall (confidentiality low, integrity none) from the systems behind it (high and high). Siemens' 3.1 vector marks scope changed. The gap between 7.8 and 9.1 is 1.3 points (derived), and, reading the vectors, it comes from two versions of the scale allocating impact differently, not from one party thinking the bug harder to exploit (inference).

The move from 4.7 to 7.8 is a different thing. Per NVD's change record only the exploit-maturity and urgency fields moved, from unreported to attacked, which is a statement that attacks were being observed. That is why the same flaw was "medium" on the day it was published and "high" 16 days later without any change in what it does. None of the four numbers measures whether the exposure condition exists on your gateway. A low score on a gateway with the condition present is worse than a critical one on a gateway without it.

"Known exploited" is a list, not knowledge

The flaw has been on the KEV catalogue since 29 May, and its entry now says ransomware campaign use is "Known". The entry's required action is to apply mitigations per vendor instructions, follow Binding Operational Directive 22-01 guidance for cloud services, or stop using the product if mitigations are unavailable. Per Infosecurity and BleepingComputer, the 1 June due date is a deadline for US federal agencies. For anyone else it is a signal. This site's briefing on KEV deadlines found that a three-day clock applied to 26 of the 34 additions between 1 and 23 September, so a three-day due date is the common case here, not a special alarm about this flaw.

The KEV entry does not say when its ransomware field changed. BleepingComputer reports that CISA flagged the flaw as used in ransomware attacks on Monday 20 July, the day of Arctic Wolf's Qilin report. A list entry that has been public for 136 days (29 May to 12 October, derived) is not the same as a gateway being known to the people who run it. The earlier case on this site of an edge gateway exploited before its patch existed is the opposite problem, and the same question follows in both: who in your organisation would have known.

What the record does not establish

Five questions a reader will ask, what the sources read state, and what none of them states. Sources are as named in the cells.

The question	Stated	Not stated
How many gateways remain unpatched?	Nothing on patch state. [BleepingComputer](https://www.bleepingcomputer.com/news/security/critical-globalprotect-vpn-bug-now-exploited-in-ransomware-attacks/) reported on 21 July that Shadowserver tracked "over 167,000" exposed GlobalProtect instances and Shodan "over 172,000" IPs with a GlobalProtect fingerprint, and said there is no information on how many are patched or honeypots.	Any count of vulnerable or unpatched gateways, in any source read. Those figures count exposed GlobalProtect instances in July, not instances with the condition, and none is later than 21 July. Shadowserver's own data was not reached.
Does ReliaQuest's attribution rest on its own telemetry?	Infosecurity: ReliaQuest "confirmed" Qilin and Settra are exploiting the flaw and observed Cobalt Strike, BloodHound and SharpHound deployed alongside.	Whether that is its customers' data, its incident response or others' reporting; how many intrusions; any link between Settra and this flaw in any other source read.
Was any victim breached through this flaw?	Arctic Wolf: multiple June intrusions that ended in Qilin encryption, entry "confirmed or assessed". Rapid7: successful VPN sessions at customers, no lateral movement seen. SOCRadar: working sessions on 7 gateways.	A named victim, the number of ransomware victims, a UK victim. Arctic Wolf places impacted organisations in Europe and North America, heaviest in the United States.
What can the flaw do beyond a VPN session?	The advisory: "bypass security restrictions and establish an unauthorized VPN connection". Arctic Wolf and Rapid7 describe sessions established as an administrative account name.	What a session can reach on your network, which depends on your policy and segmentation. The advisory states nothing past the connection.
Does multi-factor authentication on the gateway change anything?	The advisory does not mention multi-factor authentication. Rapid7 says an override cookie is used "in lieu of re-authenticating via credentials". Arctic Wolf's 4 June bulletin says sessions were established "without credentials or multi-factor authentication (MFA)", yet lists enforcing MFA on administrative accounts among its workarounds.	A statement from the vendor that MFA does or does not stop this. SOCRadar says one actor's scanner skipped SAML-configured gateways as not vulnerable, while Arctic Wolf saw SAML redirect events in intrusions; neither is a rule.

The UK position: what an assessor and a regulator will ask

The National Cyber Security Centre (NCSC) is the UK body to look to for an alert on a flaw like this. A web search of its site found no alert for CVE-2026-0257; a search is not a crawl, so treat that as not found, not as absent. It did publish an alert in April 2024 for an earlier GlobalProtect flaw, telling organisations to install the update, apply the temporary mitigation if none existed, and hunt. Its alert of 27 August 2026 is written about operational technology but addresses edge devices directly: keep an accurate inventory of internet-facing systems, understand the function and data flows of edge devices, apply vendor security updates promptly, and monitor for unexpected configuration changes or outbound connections. Its 18 June alert on Fortinet VPN gateways is the nearest UK precedent for an exploited VPN gateway: investigate, isolate if compromised, save logs and configurations before a factory reset because changing credentials alone may not be enough, and check other devices that share credentials. Its VPN guidance recommends client certificates for machine authentication. The advisory does not say whether that would have stopped a forged-cookie session, so treat it as depth, not as a fix.

Cyber Essentials requirements for IT infrastructure v3.3 (April 2026) put firewalls inside its security update management control. Updates must be applied within 14 days of release where they fix vulnerabilities the vendor describes as "critical" or "high risk", where the CVSS v3 base score is 7 or above, or where the vendor gives no detail. Here the test is met whatever the vendor's label on 13 May: NVD's CVSS 3.1 score is 9.1, and the vendor's own label was "high" from 29 May. Fourteen days from 13 May ended on 27 May, from 28 May on 11 June, and from 29 May, the day the label changed, on 12 June (derived). From those dates to ReliaQuest's warning is 135, 120 and 119 days (derived). The standard counts from release, not from the day a label changes, and whether an assessor would accept 29 May as the start is not stated. The vendor's 4.7, a version 4.0 score, would not have triggered the clock on its own, which is the practical cost of the label.

The Information Commissioner's Office (ICO guide) says a notifiable personal data breach must be reported to it within 72 hours of becoming aware, that access by an unauthorised third party is a personal data breach, and that every breach must be recorded whether or not it is notified. An unauthorised VPN session is a security incident at once; whether it is a personal data breach turns on what personal data it reached or put at risk. The practical point is the clock: awareness is what starts it, and the log review since 13 May is how a gateway owner becomes aware.

NCSC's Early Warning service is free to any UK-based organisation, needs a MyNCSC account and the organisation's public addresses and domains, and sends alerts including vulnerability and open-port alerts. The NCSC alert of 27 August says all organisations should register. The service page says it does not scan networks itself and "should not be used as the only layer of defence". Whether it would flag a gateway because of an authentication-override setting is not stated, and since the exposure condition is a configuration, an outside view of a version number could not settle it (inference).

What a UK organisation with a GlobalProtect gateway should be able to show an assessor, where the expectation comes from, and what the record does not settle.

Evidence to hold	Where the expectation comes from	Not settled
Every portal and gateway listed, with owner and version, including Prisma Access, hybrid and supplier-embedded instances	NCSC 27 August alert: accurate inventory of internet-facing systems	Whether Prisma Access and supplier hardware sit inside your Cyber Essentials scope boundary.
The update, dated, with the fixed version for each minor release line	Cyber Essentials v3.3: 14 days for critical or high-risk fixes, firewalls included	The release date of each fixed version; whether an assessor counts from 13 May or a later date.
The authentication override setting and certificate use on each gateway, or the workaround applied	The vendor advisory	What "a specific certificate configuration" means; Rapid7 and Arctic Wolf read it as certificate reuse.
A dated review of gateway logs since 13 May, who did it and what it found	NCSC's Fortinet alert pattern for exploited VPN gateways; no NCSC alert for this CVE was found	How far back your logs go; many gateways rotate them.
Firewall rules approved and documented, multi-factor authentication on administration	Cyber Essentials v3.3 firewall requirements	Whether multi-factor authentication on the gateway matters for this flaw.
A breach assessment record: when you became aware, what personal data was reachable, the decision	ICO: 72 hours from awareness; record all breaches	Whether an unauthorised session alone is a personal data breach.
Early Warning registration	NCSC 27 August alert and the service page	Whether Early Warning covers this flaw.

What to do, in order

What could not be verified

• ReliaQuest. Its own 9 October advisory was not found. Its date, claims and the names Qilin and Settra rest on Infosecurity Magazine. Settra is not named in connection with this flaw in any other source read.
• The 4.7. The vendor's earlier score appears in Rapid7 and Arctic Wolf. It is not on the advisory page, and it was not recomputed. NVD's change history confirms the vector at publication and the change on 29 May.
• Fix release dates. The advisory does not say that its timeline entries are release dates, and gives no date for 6 of the 17 PAN-OS fixed versions.
• The 20 July CISA flag. The KEV file shows "Known" in catalogue version 2026.10.08 without a date. The date rests on BleepingComputer.
• Counts. No source gives a count of unpatched or vulnerable gateways. The 167,000 and 172,000 are BleepingComputer's report of Shadowserver and Shodan exposure counts on 21 July.
• Shown as reported, not run. Public proof-of-concept code exists according to Unit 42 and Rapid7. It was not downloaded, run or linked.
• The Hacker News. Its page was read in a browser for a mention of SOCRadar; SOCRadar's own report was then read in full.
• Version labels. Arctic Wolf's 4 June bulletin labels 7.8 as a CVSS v3.1 score. The advisory and NVD show it as version 4.0.
• Time-stamped. Sources were read between 11:14 and 11:31 BST on 12 October 2026. A page, a score or a catalogue entry could change within hours.

The question that exposes the gap

For every GlobalProtect gateway you run, can you show today which fixed version it is on, whether authentication override cookies are enabled on it, and who has read its session log since 13 May?

Key facts