Palo Alto Firewall Has an Unpatched Critical RCE Today (CVE-2026-0300)

Published: May 6, 2026

Severity: Critical (CVSS 9.3)

Status: Actively exploited. Patch lands May 13, 2026.

TL;DR

Palo Alto confirmed today that a critical PAN-OS firewall flaw is being actively exploited. An unauthenticated attacker can take full root control of an affected firewall with a single crafted request.

The patch isn't ready until May 13. That's a week-long exposure window with no permanent fix.

The one question your team needs to answer in the next two hours: "Is our User-ID Authentication Portal exposed to the internet?"

If yes, apply the workaround today. If no, plan a controlled patch window.

What's affected

PAN-OS firewalls (PA-Series hardware, VM-Series virtual) running specific versions, but only when the User-ID Authentication Portal (also called the Captive Portal) is enabled.

• Not affected: Prisma Access, Cloud NGFW, Panorama
• Internet-exposed portals are the active targets. Palo Alto's own advisory confirms this.
• CVSS 9.3 if portal is internet-exposed, 8.7 if restricted to trusted networks

Why this one matters more than a typical Critical

Three things separate this from the average "critical CVE Tuesday."

It's already being exploited. Palo Alto says "limited exploitation observed." In vendor language, that means sophisticated actors are already using this. They just aren't at mass-scale yet. The window between "limited" and "widespread" is usually days.

There is no patch yet. Your team needs to manage the exposure window with workarounds, not patches. Most disclosures don't ask for that.

Firewalls are the worst possible compromise. Root on a firewall isn't another compromised server. It's a privileged position between your network and the internet. Every credential, every session token, every internal API call passing through is now visible. This is the kind of incident that turns into a regulatory disclosure.

The pattern worth noticing

This isn't the first time. CVE-2020-2040 affected the same component (Captive Portal), same class of bug (buffer overflow), same impact (unauth root RCE). Six years apart, same product, same component.

In 2024 alone, seven PAN-OS vulnerabilities were exploited in the wild. CISA's KEV catalog lists 13 separate Palo Alto product CVEs.

The takeaway isn't "Palo Alto is bad." It's that network appliances at the perimeter are a permanent, recurring attack surface, and "we're patched" is only true until the next disclosure. Treating perimeter appliances like one-time deployments is the mistake.

We've seen variations of this across vendors recently: FortiClient EMS had three critical bypasses in 90 days, and a 9-year-old Linux kernel bug surfaced last week. Same shape every time.

What your team should do

Today (next 2-4 hours):

• Confirm whether the Authentication Portal is enabled and internet-exposed (Device > User Identification > Authentication Portal Settings)
• If exposed: restrict it to trusted networks, or disable it entirely if not actively needed
• Most enterprise deployments don't actually need the portal internet-reachable. Restricting it costs nothing operationally.

This week (before May 13):

• Pre-stage patch deployment: which firewalls, which versions, who can approve emergency change windows without a CAB
• Hunt for prior compromise. "Limited exploitation" means someone has already been hit. If you've had this portal exposed recently, treat it as potentially compromised until proven otherwise. Review auth logs, admin accounts, recent config changes.
• Brief leadership briefly. Suggested language: "Palo Alto confirmed active exploitation of a critical zero-day in PAN-OS firewalls. We're operating under a workaround until vendor patches arrive May 13. Exposure is assessed; we're monitoring for IoCs."

After the patch (next 90 days):

• Review your perimeter-device patch SLA. If it's "30 days," but a vendor needs you to act in 7, you have a posture problem.
• Audit your perimeter inventory. Can someone produce, in 15 minutes, a complete list of every firewall, version, exposed services, and last-patched date? If not, that's the project.

Three questions worth asking your team

1. If our perimeter firewall were compromised tomorrow, what's the actual blast radius? Most haven't modeled this since their last red team. Probably outdated.
2. Are we doing the work to detect compromise of network appliances, or just patching them? Firewalls don't run EDR. Their logs often go unmonitored. A compromised firewall can sit silently for months.
3. What's our actual time-to-patch for critical perimeter CVEs, measured in production? Not the policy. The measured time. If you don't know, that's the gap to close before the next disclosure.

What VulnTracker does in moments like this

Disclosures like CVE-2026-0300 are exactly what VulnTracker exists for. Tell us what you run, and you'd see this in your alerts within hours of disclosure, ranked above the dozens of less-urgent CVEs that landed today, with KEV/EPSS exploitation context to brief leadership.

For teams without centralized tooling, the workflow looks like: vendor advisory drops at 09:00, three different people forward the same Hacker News article between 09:30 and 11:00, someone finally pulls a list of affected versions at 13:00, and mitigation actually starts in the afternoon. The cost isn't the technical work. It's the lost hours between "this CVE exists" and "we know our exposure."

Track CVE-2026-0300 on VulnTracker and we'll alert you the moment the patch lands on May 13 — no checking the advisory page hourly, no missing the release because it dropped during your off-hours.

Start a 5-day free trial, or get our daily digest free without setting anything up.

Quick reference

We hope your company is the one hackers skip.