Your Firewall Has a Front Door. Attackers Found It in May 2026.
On 17 May 2026, attackers started walking through a door that wasn’t supposed to exist. By 29 May, CISA had seen enough to add CVE-2026-0257 to the Known Exploited Vulnerabilities catalogue. That’s the US government’s list of confirmed, in-the-wild exploitation. It doesn’t get updated speculatively.
If your business uses Palo Alto networking equipment, specifically anything running PAN-OS or Prisma Access with GlobalProtect VPN enabled, this is the most important thing you’ll read this week.
What CVE-2026-0257 Actually Is
GlobalProtect is Palo Alto’s VPN product. It’s the thing that lets your staff securely access the office network from home or when travelling. The authentication component is supposed to verify that the person connecting is who they claim to be, before granting access.
CVE-2026-0257 is an authentication bypass. That phrase means exactly what it sounds like: the authentication check can be circumvented entirely. An attacker who knows about this vulnerability doesn’t need a valid username. They don’t need a password. They don’t need to steal credentials or phish your staff. They present a specially crafted request and the system lets them in.
The result is unauthorised VPN access and direct exposure to the internal network sitting behind it.
Why This Was Added to CISA’s KEV List
The CISA Known Exploited Vulnerabilities catalogue is not a speculative list. It is not populated based on theoretical risk scores or vendor warnings alone. CISA adds a vulnerability to KEV when it has verified evidence that exploitation is actively occurring in real environments.
CVE-2026-0257 was added on 29 May 2026. Palo Alto Networks confirmed that exploitation had begun on 17 May, twelve days before the KEV listing. That twelve-day gap matters: it means organisations that weren’t monitoring closely had almost two weeks of exposure before a formal government alert was issued.
The formal CVSS score assigned to this vulnerability is in the medium range. That classification is technically accurate but practically misleading. Medium severity sounds manageable. Active exploitation of a perimeter authentication bypass is not manageable. The gap between the assigned score and the real-world impact is exactly the kind of thing that leaves businesses exposed while their IT teams deprioritise patching.
What This Means for a Small Business Running Palo Alto Kit
Palo Alto’s enterprise-grade firewalls and VPN products are common in businesses that have invested in higher-end network infrastructure. They’re also frequently deployed by managed service providers as part of a standardised stack.
If your MSP manages your network and runs PAN-OS devices on your behalf, you are relying on them to have identified this, assessed your exposure, and either patched or mitigated it already. That reliance is reasonable. It is also, right now, something worth verifying explicitly.
The specific question to ask your MSP is straightforward: “Have you assessed our exposure to CVE-2026-0257, and if we are running affected PAN-OS versions, what action has been taken and when?”
A competent MSP should be able to answer that question with a version number, a patch date, or a documented mitigation. Vague reassurance is not an answer.
How to Turn This Into a Competitive Advantage
Businesses that respond to confirmed exploited vulnerabilities quickly demonstrate something that’s genuinely hard to fake: operational security discipline.
If you’re in a sector where clients or prospects ask about your security posture, being able to say “we identified CVE-2026-0257 within 48 hours of the CISA KEV listing and confirmed remediation” is concrete evidence of a functioning security process. It’s the difference between checking a compliance box and actually having the capability the box is supposed to represent.
More practically: if your MSP proactively contacted you about this without being asked, that’s a data point about the quality of that relationship. If they didn’t, that’s also a data point.
How to Make the Case to Your Management or Directors
Three arguments that don’t require any technical knowledge to evaluate:
The regulator will ask. The ICO’s GDPR enforcement guidance is explicit that technical and organisational measures must be appropriate to the risk. Running unpatched perimeter devices with a confirmed active exploit on them is not an appropriate measure. If a breach follows and this vulnerability contributed to it, the failure to patch a CISA-listed KEV will be relevant to any regulatory assessment.
The attacker’s cost is near zero. Authentication bypass vulnerabilities are particularly dangerous because exploitation doesn’t require significant attacker resources. There’s no need to invest in credential theft or social engineering. Any attacker aware of the vulnerability can attempt it. That means the threat isn’t limited to sophisticated nation-state groups; it’s accessible to lower-capability actors as well.
Insurance may not pay out. Cyber insurance policies increasingly contain exclusions for losses resulting from known, unpatched vulnerabilities. A vulnerability listed on CISA’s KEV catalogue is, by definition, known. Document your remediation. If you can’t remediate immediately, document your compensating controls and the timeline for remediation.
What to Do This Week
1. Identify whether you run affected products. The affected products are PAN-OS (multiple versions) and Prisma Access. If you don’t know what your network perimeter runs, ask your MSP or IT provider now, not later.
2. Check Palo Alto’s security advisory. Palo Alto publishes version-specific guidance. The patch is available. Check your current version against the affected versions listed and confirm whether you need to update.
3. Apply the patch or the documented mitigation. If you cannot patch immediately due to change control processes or operational constraints, Palo Alto has documented a temporary mitigation. Apply it. Document that you’ve done so and set a firm date for full patching.
4. Review VPN authentication logs from 17 May 2026 onwards. Active exploitation began on 17 May. If your systems were running an affected version during that period and you have log data, review it for anomalous authentication events: unexpected source IP addresses, authentication attempts at unusual times, or sessions that don’t correspond to known users.
5. Confirm the conversation with your MSP in writing. If your MSP manages this for you, confirm their actions in an email. Ask specifically what version you were running, when the patch was applied, and whether log review was conducted. Written confirmation protects you if questions arise later.