Your Firewall Is Part of Your Attack Surface

The Assumption That Gets Organizations Compromised

Firewalls, VPNs, and edge security appliances are usually treated as protective controls. The assumption is that they stand between your network and the internet, filtering what gets in. That framing is correct as far as it goes. But it misses something important about how attackers think about these devices.

From an attacker's perspective, a firewall or VPN concentrator is not a barrier. It is a target. It sits directly on the internet, it runs complex software with a wide attack surface, it holds credentials and session tokens, and it has privileged access to everything behind it. Compromising a perimeter appliance does not mean bypassing your defenses. It means you have already lost them.

Three actively exploited Fortinet vulnerabilities added to the CISA Known Exploited Vulnerabilities catalog in April 2026 illustrate exactly this pattern. CVE-2025-59718, CVE-2025-59719, and CVE-2026-24858 affect FortiOS and FortiGate SSL-VPN. All three are being actively exploited. All three are authentication bypass or remote code execution vulnerabilities in devices your organization almost certainly placed at the network perimeter because they were supposed to improve security.

What the Vulnerabilities Do

CVE-2025-59718 allows an unauthenticated attacker to bypass authentication on the SSL-VPN portal entirely. No credentials. No session. A request to a specific endpoint establishes access as a valid user. This means an attacker on the internet can authenticate to your VPN without having any valid account in your organization.

CVE-2025-59719 goes further. The FortiGate management interface contains a vulnerability that permits unauthenticated remote code execution. An attacker who can reach the management interface does not need to authenticate first. They can execute arbitrary commands directly on the appliance.

CVE-2026-24858 is a heap-based buffer overflow in the SSL-VPN processing path. Exploitation occurs before authentication, allowing a remote attacker to execute code with the privileges of the FortiGate process. On most deployments, that process runs with sufficient privileges to modify routing, capture traffic, and establish persistence.

Chained in sequence or used independently, these vulnerabilities give an attacker the ability to gain initial access to your network, intercept all VPN traffic, harvest credentials from every user who authenticates during the window of compromise, and pivot from the perimeter appliance into the internal network. The device meant to protect your network becomes the vector for full compromise.

Why Attackers Target Edge Devices First

Edge devices are attractive for several reasons that have nothing to do with any specific CVE.

They are always reachable. A workstation might be powered off. A server might be behind additional access controls. A firewall or VPN concentrator is on the internet by definition, listening 24 hours a day. Automated scanning finds these devices within minutes of a vulnerability being published.

They are infrequently patched. Security teams often apply stricter patching cadences to internal systems than to perimeter appliances, partly because patching a firewall or VPN requires a maintenance window that disrupts remote access. This means the window between a vulnerability being published and being remediated is longer on these devices than on almost anything else in the environment.

They hold the keys. A compromised FortiGate has access to VPN session tokens, LDAP credentials for authentication lookups, firewall rules, routing tables, and the full decrypted content of every session passing through it. The blast radius of a single edge device compromise extends across the entire network.

They are rarely monitored. Organizations that have good endpoint detection and logging on internal systems frequently have limited visibility into what their perimeter appliances are doing. Authentication attempts, configuration changes, and unusual traffic patterns on the firewall management interface often go unlogged or unreviewed.

The Pattern Extends Beyond Fortinet

Fortinet is not uniquely vulnerable. The same pattern appears consistently across every major edge device vendor. Palo Alto Networks issued an emergency advisory in April 2024 for CVE-2024-3400, a zero-day command injection in PAN-OS that was being actively exploited before the patch existed. Ivanti has disclosed multiple authentication bypass vulnerabilities in Connect Secure and Policy Secure over the past two years, with active exploitation confirmed in each case. Citrix NetScaler, Cisco IOS XE, SonicWall SSLVPN: all have contributed significant entries to the CISA KEV catalog in the last 18 months.

The common thread is not a specific vendor or product. The common thread is the category: internet-facing systems with privileged network access, running complex software that receives and processes untrusted input, patched on slower cycles than the rest of the environment. These conditions make edge devices a reliable source of high-severity exploitable vulnerabilities year after year.

Why CVSS Is Not Enough Here

All three Fortinet CVEs score 9.6 or higher. Those scores are accurate in the sense that the technical severity is very high. But CVSS scores do not answer the questions that determine your actual exposure.

The questions that matter:

1. Is this device internet-facing, or only reachable internally?
2. Is the management interface exposed to the internet, or restricted to known management IPs?
3. What version is running? Has the vendor confirmed this version is affected?
4. Is there active exploitation confirmed, or just a published PoC, or just a theoretical disclosure?
5. Is this device in CISA KEV? Federal agencies have a 21-day patch mandate. That is a proxy for how seriously the government treats the real-world risk.
6. What does this device have access to? A compromised edge device is different from a compromised workstation.
7. Does your existing security tooling have visibility into this device? If not, you will not detect exploitation after the fact.
8. When was the device last patched? A device that was patched last month requires a different response than one that has not been patched in a year.
9. What compensating controls exist? Is there a WAF, network segmentation, or separate monitoring in place?

A CVSS 9.8 on an internet-facing device running an affected version with active exploitation confirmed in the wild and no network monitoring in place is an emergency. The same score on a device that is not internet-accessible and is fully patched is not urgent at all. CVSS is a starting point. It is not a remediation strategy.

What to Do Now

1. Identify every internet-facing device in your environment. Firewalls, VPN concentrators, remote access gateways, load balancers, unified threat management appliances. If it sits on the network perimeter and connects to the internet, it belongs on this list. Many organizations do not have a current, accurate inventory of these devices.
2. Check versions against affected ranges. For the three Fortinet CVEs above: affected versions are all FortiOS releases prior to 7.4.5 (for CVE-2025-59718 and CVE-2025-59719) and prior to 7.4.6 (for CVE-2026-24858). Check your running version via the CLI with get system status or through the management interface under System > Firmware.
3. Patch immediately if affected. Fortinet has published patches for all three CVEs. CISA designation means these are confirmed exploited. There is no acceptable waiting period. If you cannot patch immediately, take the management interface offline and restrict SSL-VPN access to known IP ranges while you schedule the maintenance window.
4. Restrict management interface access. The management interface of any perimeter device should never be reachable from the internet. Use firewall rules or ACLs to limit access to the management port to specific internal or VPN-only IP addresses. This is a compensating control, not a substitute for patching, but it reduces the attack surface significantly.
5. Review authentication logs for exploitation indicators. Look for authentication successes that did not originate from known user IP ranges, configuration changes made outside normal change windows, new administrator accounts, and outbound connections to unfamiliar external addresses. If CVE-2025-59718 was exploited in your environment, the indicator is an authenticated session with no corresponding successful credential exchange in the logs.
6. Treat a compromised perimeter appliance as a full network compromise. If you have evidence of exploitation, the scope of investigation must extend to every system that device had access to. Credentials harvested through an SSL-VPN bypass should be assumed compromised across all systems where those credentials are valid. Reset credentials, invalidate sessions, and treat internal systems as potentially affected until proven otherwise.

The Posture Problem

What the Fortinet CVEs illustrate is not primarily a patching problem, though patching is the correct immediate action. The deeper issue is posture: the security controls an organization deploys are themselves part of the attack surface, and they require the same vulnerability tracking discipline as everything else in the environment.

A firewall with an unpatched critical vulnerability sitting on the perimeter is not a security control. It is a liability with a privileged network position. The fact that it is also filtering traffic and blocking port scans does not change the calculus if it can be compromised before authentication occurs.

The organizations that find out about this kind of compromise quickly are the ones that have visibility into what their perimeter devices are doing, track vulnerability status on those devices continuously, and treat a CISA KEV entry as an immediate response trigger rather than a backlog item. The organizations that find out late are the ones that applied strong monitoring and patching practices to their workstations and servers and assumed the security appliances were taking care of themselves.