Firewall CVE Watch: Five KEV Entries in 90 Days — and the Config Change That Blunts Each One

Between May 6 and July 27, 2026, CISA added five vulnerabilities in perimeter security products to its Known Exploited Vulnerabilities catalog: two in Palo Alto PAN-OS, two in Check Point, and one in Fortinet FortiOS. Every one of them is being exploited in the wild. That is roughly one confirmed-exploited firewall flaw every two and a half weeks, in the exact class of device whose job is to be reachable from the internet.

Patch. That is always step one and this post is not an argument against it. But patching is a schedule problem, and the interesting question after an advisory drops is a different one: was the vulnerable service even reachable from the internet, and did our configuration decide that? For three of these five, the vendor's or CISA's own guidance names a configuration control that blunts or entirely prevents exploitation. One is patch-only. One cannot be fixed in configuration at all — and that one is the most instructive of the set.

Here is each entry, what it actually does, the mitigation as the vendor states it, and how you would verify the mitigation is in place across a fleet rather than on the one gateway you happened to check.

1. CVE-2026-0300 — PAN-OS User-ID Authentication Portal, unauthenticated root RCE

What it is: a buffer overflow in the User-ID Authentication Portal (the service most people still call Captive Portal) that lets an unauthenticated attacker execute arbitrary code with root privileges on PA-Series and VM-Series firewalls by sending crafted packets. NVD scores it CVSS 3.1 9.8 and CVSS 4.0 9.3. Prisma Access, Cloud NGFW, and Panorama are not impacted. KEV-listed May 6, 2026.

The mitigation is a config change, and CISA wrote it into the required action: restrict User-ID Authentication Portal access to trusted zones only, and disable the portal entirely if you are not using it. Palo Alto's own advisory says the risk is "greatly reduced" when portal access is restricted to trusted internal IP addresses. Patches followed on May 13 and are the complete fix — but an organization that had already scoped the portal to internal zones was not exploitable during the window before the patch existed.

How to verify: this is a policy-and-zone question, not a version question. You are looking for any rule that lets an untrusted zone reach the portal service, and for the portal being enabled on a device that has no business running it. That is exactly the kind of thing that is obvious in a single config and invisible across thirty.

2. CVE-2026-0257 — PAN-OS GlobalProtect authentication bypass

What it is: authentication bypass in the GlobalProtect portal and gateway that lets an attacker bypass security restrictions and establish an unauthorized VPN connection. CVSS 3.1 9.1, CVSS 4.0 7.8. Panorama and Cloud NGFW are not impacted. KEV-listed May 29, 2026 — and this is the one entry in this set that CISA flags for known ransomware campaign use.

The mitigation is the patch. There is no configuration switch that makes an internet-facing GlobalProtect portal unreachable — being reachable is the product. What configuration decides here is the blast radius on the other side of the bypass: what a VPN session can actually touch once established. A remote-access tunnel that lands users into a flat internal zone with a permissive rule turns one auth bypass into full lateral movement. The same tunnel terminating into a restricted zone with explicit destination rules turns it into a much smaller incident.

How to verify: patch first, then read your VPN posture as an attacker would — what does the VPN zone reach, is MFA enforced on every group rather than most of them, is split tunneling scoped or set to everything. Those are the controls that were still doing work while the bypass was live.

3. CVE-2026-16232 — Check Point SmartConsole authentication bypass

What it is: an authentication bypass in the SmartConsole login process that lets an unauthenticated remote attacker obtain an application login token and authenticate with full administrative privileges — enough to modify security policies and configuration. CVSS 3.1 9.1. Check Point has confirmed exploitation affecting a small number of customers. KEV-listed July 22, 2026, with a three-day federal remediation deadline. Vendor guidance is in sk185169.

The configuration is a stated precondition of the attack. Read the NVD description closely: remote exploitation "requires internet access to the Management Server IP address and a configuration that does not restrict Trusted Clients." In other words, two configuration facts have to be true before an attacker can reach this at all — the management server is reachable from the internet, and the Trusted Clients list is not restricting who may connect. Fix either one and the remote path closes, patched or not.

How to verify: this is the single most valuable question to ask about your own fleet this quarter, and it is not specific to Check Point. Is any management plane — SmartConsole, the FortiGate GUI, an ASA on SSH, a PAN-OS web interface — reachable from an untrusted source, either directly on an interface or through a policy someone wrote at 6pm two years ago? Management-plane exposure is a finding CRWLR raises as high severity on every vendor it parses, precisely because it is the precondition that turns an admin-authentication flaw into a remote compromise.

4. CVE-2026-50751 — Check Point IKEv1 VPN authentication bypass

What it is: CVSS 9.3, unauthenticated remote access VPN bypass through the deprecated IKEv1 key exchange, exploited since early May and KEV-listed June 8 with ransomware-campaign association. We covered this one in detail when it landed — see the full write-up.

The mitigations are configuration: disable legacy Remote Access clients that depend on IKEv1 and run IKEv2 only; require machine-certificate authentication, which per Check Point makes the vulnerability inapplicable. Both are things you either did or did not do years ago, and both are visible in the config file. It belongs in this list because it is the cleanest example of the pattern: a deprecated protocol nobody turned off became an unauthenticated path into the network.

5. CVE-2025-68686 — FortiOS symlink persistence patch bypass

What it is: the odd one out, and the reason this post is not a sales pitch for config auditing. It is an information-exposure flaw (CWE-200, CVSS 3.1 5.9) affecting FortiOS 7.6.0–7.6.1, 7.4.0–7.4.6, and all versions of 7.2, 7.0, and 6.4. It allows a remote unauthenticated attacker to bypass the patch Fortinet developed for the symbolic-link persistency mechanism seen in post-exploitation cases — via crafted HTTP requests. Critically, per the advisory, the attacker must already have compromised the device at filesystem level through some other vulnerability. KEV-listed July 27, 2026, federal due date August 10. Vendor advisory: FG-IR-25-934.

There is no configuration mitigation, and that is the point. This flaw lives in the filesystem and the HTTP daemon, not in your policy set. A configuration audit cannot see a symlink. What it can see is what an intruder left behind in the config — an unfamiliar admin account, a new SSL VPN user or group, a changed certificate, a widened rule — because that part does live in the file you export. We wrote that up separately: Patched Is Not Clean.

The pattern across all five

Line them up and the same four preconditions keep appearing. None of them are exotic; all of them are decisions recorded in a config file:

• → The management plane was reachable from untrusted space. Directly on an interface, or through a policy. This is the precondition CVE-2026-16232 names explicitly.
• → An optional portal was enabled and unscoped. The User-ID Authentication Portal in CVE-2026-0300 is the example; the CISA-published workaround is literally "restrict to trusted zones, or disable if not required."
• → A deprecated protocol was still enabled. IKEv1 in CVE-2026-50751. It worked, so nobody turned it off.
• → Nobody was certain which firmware was actually running where. Every advisory above is scoped to version ranges. If you cannot answer "which of my devices are in range" in minutes, the three-day KEV clock is already lost.

What a config audit can prove — and what it can't

Being precise about this matters more than the marketing version. CRWLR reads an exported configuration — FortiGate, Palo Alto, Sophos, Check Point, or Cisco ASA — and runs 175 checks against it. Against the pattern above, the relevant ones are:

• → Management plane exposure. Admin services reachable through a policy or enabled on a WAN interface, and — on FortiGate — admin accounts with no trusted-host restriction, the direct analogue of Check Point's Trusted Clients.
• → Risky and exposed services. Which services untrusted sources can reach, including cross-referencing exposed ports against services with known exploitable CVEs.
• → VPN posture. IKEv1 and aggressive mode, weak phase-1/phase-2 crypto, SSL VPN on the default port with weak TLS or unrestricted sources, missing MFA on VPN groups, and default or self-signed VPN certificates.
• → Firmware exposure. The running version cross-referenced against CISA KEV, NVD, and vendor PSIRT feeds, plus end-of-life status — which answers "which of my devices are in range" without a spreadsheet.

And the limits, stated plainly: a configuration audit does not prove a hotfix was applied to a binary, it does not see the filesystem, it does not read live traffic, and it cannot tell you a device is uncompromised. CVE-2025-68686 is unreachable by any of it. What it does is answer, in about a minute per device, whether the preconditions that make these advisories exploitable against you are present — before the next one lands with a three-day clock attached.

FAQ

Which firewall vulnerabilities were added to CISA KEV between May and July 2026?

Five entries in products from major firewall vendors: CVE-2026-0300 (PAN-OS User-ID Authentication Portal buffer overflow, added May 6), CVE-2026-0257 (PAN-OS GlobalProtect authentication bypass, added May 29, flagged for known ransomware campaign use), CVE-2026-50751 (Check Point Remote Access VPN IKEv1 authentication bypass, added June 8), CVE-2026-16232 (Check Point SmartConsole authentication bypass, added July 22), and CVE-2025-68686 (FortiOS symlink persistence patch bypass, added July 27). Fortinet also had two FortiSandbox command-injection entries added July 16 — relevant to fleet patching, though FortiSandbox is not a firewall.

Can a configuration change mitigate CVE-2026-0300?

Partly, and CISA published the workaround itself: restrict User-ID Authentication Portal access to trusted zones only, and disable the portal if it is not required. Palo Alto states the risk is greatly reduced when portal access is limited to trusted internal IP addresses. Patches were released on May 13, 2026 and remain the complete fix — the configuration control is what protected organizations during the exposure window, and what protects them against the next flaw in the same service.

What makes CVE-2026-16232 remotely exploitable?

Two configuration conditions, per the NVD description: internet access to the Management Server IP address, and a configuration that does not restrict Trusted Clients. Both are administrator choices rather than product defaults in a well-segmented deployment. Apply Check Point's fix per sk185169, then remove the preconditions — a management interface that is not reachable from untrusted networks, and an enforced Trusted Clients restriction, close the remote path independently of the patch.

Does patching my firewall mean I am safe?

Patching removes the vulnerability; it does not remove exposure or persistence. Exposure is configuration — CVE-2026-16232 is only remotely exploitable when the management server is internet-reachable and Trusted Clients is unrestricted, and CVE-2026-0300 is substantially mitigated by scoping a portal to trusted zones. Persistence is separate again: CVE-2025-68686 concerns a mechanism used after a device was already compromised, so applying the fix on a device that was breached earlier does not, on its own, establish that the device is clean.

How do I find out which of my firewalls are affected by a new CVE?

You need two facts per device: the exact running firmware version, and whether the vulnerable feature is enabled. Both live in the exported configuration. CRWLR extracts the version and cross-references it against CISA KEV, NVD, and vendor PSIRT feeds, and the matching is feature-aware — it does not raise a CVE for a feature your configuration shows is switched off. On a fleet, that is the difference between answering a KEV deadline in an afternoon and answering it in a week.

How often should we audit firewall configuration for this?

The cadence that matches the threat is quarterly at minimum, plus a re-check whenever a KEV entry lands for a vendor you run — PCI DSS requirement 1.2.7 asks for a ruleset review at least every six months, which is a floor rather than a target. In the 90 days covered by this post there were five confirmed-exploited entries in this product class, several with three-day federal remediation deadlines. A semi-annual review would have missed four of them. See our step-by-step firewall rule audit guide for the process.