CyphrQ
Menu

Edge Device Vulnerabilities: Why Firewalls and VPNs Get Exploited

Firewalls, VPNs and routers keep appearing on CISA's exploited list. Why, and what to do: inventory, exposure, patch targets, logging, end-of-life kit.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

12 min read

Edge devices are the firewalls, VPN gateways, routers, load balancers and file-transfer servers that sit between your network and the internet. Attackers hunt for edge device vulnerabilities because these devices are reachable by anyone and trusted by everything behind them. The fix is unglamorous: know every edge device you own, expose less of it, patch it on a short clock, log it off the box, and replace kit the vendor no longer supports.

Remote-access design is covered in the ZTNA vs VPN post. How to rank one flaw against another is in the guide to CVE, CVSS, EPSS and KEV.

What counts as an edge device?

An edge device is any piece of network equipment that faces the internet and decides what traffic gets in or out.

The US Cybersecurity and Infrastructure Security Agency (CISA) gives a working definition in Binding Operational Directive 26-02, issued on 5 February 2026: "all technology devices that reside on the boundary of an agency's network and are accessible from the public internet." Its examples include load balancers, firewalls, routers, switches, wireless access points and network security appliances.

In everyday terms (this list is not CISA's), that usually means:

  • the firewall at your office or data centre
  • the VPN or remote-access gateway staff log in through
  • routers, including small-office and branch routers
  • load balancers and application delivery controllers in front of websites
  • file-transfer servers that partners upload to

How often do edge devices appear in CISA's KEV catalogue?

By an approximate CyphrQ count, about 37 of the 309 entries CISA added to its KEV catalogue between 28 October 2025 and 26 October 2026 were edge devices: roughly 12%, or about 1 in 8.

CISA's Known Exploited Vulnerabilities (KEV) catalogue lists flaws with reliable evidence of exploitation in the wild. The latest vulnerabilities page shows the live feed.

How the count was made. It covers every entry added from 28 October 2025 (the earliest date in the copy used) to 26 October 2026, catalogue version 2026.10.26. Entries were classified by product name only, so a different reader could place a borderline product differently. The product families counted were:

  • Firewalls, VPN and remote-access gateways: Array Networks ArrayOS AG, Check Point Security Gateway, Cisco ASA and FTD, Fortinet FortiOS, Ivanti Connect Secure and Ivanti Sentry, Palo Alto Networks PAN-OS, SonicWall SMA1000, WatchGuard Firebox.
  • Application delivery, load balancers and web application firewalls: Citrix NetScaler ADC and Gateway, F5 BIG-IP and BIG-IP APM, Fortinet FortiWeb, Progress LoadMaster.
  • Routers, switches and cellular gateways: Arista EOS, Cisco IOS, D-Link routers, DD-WRT, MikroTik RouterOS, Sierra Wireless AirLink ALEOS, Zyxel GS1900 switches.

Left out: management consoles and SD-WAN managers, email gateways, remote-support tools and file-transfer servers. Also left out: seven entries listed only as "Multiple Products" by Fortinet, Check Point and Cisco, and two product lines that could not be placed from the name alone (Ubiquiti UniFi OS and Lantronix device servers).

Group (CyphrQ classification, by product name) KEV entries (approx.) Share of 309 (approx.)
Firewalls, VPN and remote-access gateways about 16 about 5%
Application delivery controllers, load balancers and web application firewalls about 11 about 4%
Routers, switches and cellular gateways about 10 about 3%
Edge devices, total about 37 about 12% (1 in 8)

Source: CyphrQ count of CISA KEV catalogue version 2026.10.26, made 27 October 2026.

Read the table with these limits in mind:

  • It is a floor, not a ceiling. The exclusions above mean some exploited edge-device flaws are not in the total.
  • Edge devices are not the majority. Entries with Microsoft as the vendor number 42 in the same window. The point is not volume. It is what one exploited edge device gives an attacker.
  • More scrutiny means more findings. Widely deployed products attract more researchers and more attackers, so they produce more entries. A product with few entries may simply be less studied.
  • KEV is one government's view. It lists what CISA has evidence for, not every flaw ever exploited.

Why do attackers go after edge devices?

CISA puts it in one line in BOD 26-02: "Edge devices are attractive targets due to their extensive reach into an organization's network." In the February 2025 announcement of joint edge-device guidance with its international partners, CISA wrote that "foreign adversaries routinely exploit software vulnerabilities in network edge devices."

Four traits explain it:

  1. Anyone can reach them. A firewall or gateway has to answer the internet. That makes it testable at scale, by anyone, all the time.
  2. They hold privileged access. They see traffic, store credentials and configuration, and often connect to identity systems.
  3. They are hard to inspect. Most run a closed vendor operating system, so the usual security tools on laptops and servers do not run on them.
  4. They live a long time. Network kit often stays in the rack for years, including past the date its maker stops shipping fixes.

How quickly attackers move once a flaw is public is covered in the post on time to exploit and emergency patching.

Which firewall and VPN flaws have been exploited recently?

Two recent cases show the pattern: Cisco ASA and FTD firewalls, the subject of CISA's Emergency Directive 25-03 from September 2025, and the Palo Alto Networks PAN-OS flaw CVE-2026-0322, published in October 2026.

In practice: Cisco firewalls, September 2025 to April 2026.

  • 25 September 2025. CISA issued Emergency Directive 25-03 for Cisco firewalls running ASA or FTD software. It covered CVE-2025-20333, which allows remote code execution, and CVE-2025-20362, which allows privilege escalation.
  • Why it was unusual. The directive says the activity involved "manipulating read-only memory (ROM) to persist through reboot and system upgrade." It also warns that applying the updates "does not necessarily remove an existing threat actor from the compromised device."
  • Who was behind it. In its event response page, Cisco says it assesses "with high confidence" that the activity is linked to the same threat actor as the ArcaneDoor campaign.
  • 30 September 2025. Federal agencies had to permanently disconnect ASA hardware with an end-of-support date on or before 30 September 2025, by that date. Where they could not, they had to apply the latest updates by 26 September 2025 and report the mission-critical need and a decommissioning plan to CISA.
  • 23 April 2026. An update extended the directive to Firepower 1000, 2100, 4100 and 9300 and Secure Firewall 200, 1200, 3100, 4200 and 6100 series devices. Where no compromise was found, agencies had to unplug the power by 30 April 2026, "as a reboot is not sufficient to expunge the malware."

In practice: Palo Alto Networks PAN-OS, October 2026. On 14 October 2026 Palo Alto Networks published CVE-2026-0322, a flaw in the PAN-OS management interface that lets an authenticated attacker with network access run code with root privileges on the firewall. The advisory rates severity high with a suggested urgency of "HIGHEST", says "very limited exploitation has been observed", and states that "no known workarounds exist." CISA added it to KEV the same day, according to the catalogue data. The vendor's main advice beyond patching is exposure: "The risk is highest when you allow access to the management interface from external IP addresses on the internet."

The two cases teach different lessons. The Cisco case shows that patching may not evict an attacker who is already in. The Palo Alto case shows that exposing a management page to the internet turns a serious flaw into an urgent one.

What should you do about edge device vulnerabilities?

Five steps, in order. The first two cost almost nothing.

1. Make a list of every edge device

You cannot patch a box you do not know about. For each device, record the make, model, software version, who owns it, what it is for, and the vendor's end-of-support date. Include branch routers, the old VPN kept "just in case", and anything a supplier installed for you.

2. Expose as little as possible

Every service a device offers to the internet is something an attacker can test. Turn off features you do not use. Above all, keep management interfaces off the internet and reachable only from a small set of trusted internal addresses, as Palo Alto's advisory recommends for PAN-OS.

3. Set a patch target, in days, for edge devices

Edge devices need a shorter clock than desktops. In the Cisco case, ED 25-03 told federal agencies to apply all later Cisco updates "within 48 hours of release" on the devices they kept in service. Not every organisation can match that, but a written target in days, with a named owner, beats "next maintenance window". Treat any KEV-listed flaw in an edge device you run as top priority.

4. Log it somewhere the device cannot touch

Send logs from every edge device to a central store as they happen. A compromised device can edit its own records; a copy elsewhere is harder to erase. Keep enough history to look back weeks, not days.

5. Replace end-of-life kit on a schedule

A device that no longer gets security fixes stays vulnerable to every future flaw found in it. BOD 26-02 exists for this reason: CISA wrote that exploitation campaigns "are often enabled by unsupported devices." Put end-of-support dates in your budget plan, so replacement is planned rather than forced.

Going deeper: for security and IT teams

Scope and lifecycle, using BOD 26-02 as a template. BOD 26-02 defines end of support as "hardware devices, firmware, and software versions that no longer receive timely, supported updates" from the manufacturer, including patches, security updates, hotfixes and defect fixes. It binds US federal civilian agencies only, and excludes operational technology and FedRAMP-authorised cloud products that OMB M-24-15 places out of scope. Its timeline is a usable lifecycle model for any organisation:

BOD 26-02 deadline Required action (federal civilian agencies)
Immediately Update each vendor-supported edge device running end-of-support software or firmware, where that does not harm mission-critical functions
3 months Inventory devices on the CISA EOS Edge Device List and report them to CISA
12 months Decommission listed devices whose end-of-support date falls on or before that deadline; inventory devices going end-of-support in the following 12 months
18 months Decommission all identified end-of-support edge devices
24 months Run continuous discovery of all edge devices and decommission each by its end-of-support date

The 24-month item is the one most organisations lack: discovery that runs continuously, not a spreadsheet updated once a year. Reconcile three sources against each other: external attack-surface scans of your own IP ranges, the asset register, and the configuration backups your network team already holds.

Management-plane exposure. CVE-2026-0322 sits in the PAN-OS management interface and affects PA-Series and VM-Series firewalls and Panorama; Palo Alto says Cloud NGFW and Prisma Access are not affected. Fixed releases span the 10.2, 11.1, 11.2, 12.1 and 12.2 branches, each with specific hotfix builds, so check the exact build against the advisory rather than the branch number. The flaw needs authentication, which makes admin credential hygiene part of the control: unique admin accounts, MFA on management logins where the platform supports it, and no shared service accounts. Palo Alto lists Threat Prevention signatures as "limited coverage" that requires SSL decryption of management traffic. Treat that as a stopgap, not a fix.

Assume patching is not eviction. ED 25-03 is the clearest public statement of this. It required core dumps submitted through CISA's Malware Next Gen portal, using CISA's core dump and hunt instructions. If compromise was found, devices were to be disconnected from the network but kept powered on, which preserves volatile evidence. The directive also links CISA's malware analysis report on the FIRESTARTER backdoor, AR26-113A. A 12 November 2025 implementation note on the directive page said some agencies had marked devices "patched" while installing software that "is still vulnerable to the threat activity outlined in the ED." Verify the installed build against the vendor's fixed-version list; do not trust a ticket status.

Detection signals worth alerting on. For each edge device, alert on: logins to the management interface from addresses outside your admin range; new local administrator accounts; configuration changes outside approved change windows; outbound connections the device itself starts to unfamiliar destinations; unexpected reboots, crashes or core files; and a software version that changes without a matching change record. Test the pipeline: make a harmless configuration change and confirm the alert arrives.

Logging specifications. The February 2025 joint series includes UK NCSC guidance on digital forensics monitoring specifications for network devices, which CISA's series page describes as intended to "enable network defenders to easily detect and investigate malicious activity following a cyber intrusion." Use it as a buying checklist for new devices.

Federal patch deadlines have changed. BOD 26-04 revoked BOD 22-01 on 10 June 2026; the post on time to exploit explains what replaced it.

Questions to ask an edge-device vendor. - Where do you publish end-of-support dates for each model and software train, and how much notice do you give? - Can the device export full logs, including admin actions and configuration changes, to an external collector in real time? - Do you provide an integrity-checking tool or a documented way to collect forensic images and core dumps? - How do you notify customers when a flaw in your product is exploited? - Can the management interface be bound to a dedicated interface or internal address only?

What should an edge device security checklist include?

  1. List every internet-facing device with model, version, owner and end-of-support date.
  2. Scan your own public IP ranges and reconcile the results with that list.
  3. Remove management interfaces from the internet; allow trusted internal addresses only.
  4. Disable features and services you do not use.
  5. Write a patch target in days for edge devices, with a named owner.
  6. Subscribe to your vendors' security advisories and check KEV for each product you run.
  7. Send edge-device logs to a central store and alert on admin logins and configuration changes.
  8. After any exploited flaw, check for compromise as well as patching, following the vendor's and CISA's guidance.
  9. Budget to replace each device before its end-of-support date.

Key takeaways

  • Edge devices are internet-facing network equipment: firewalls, VPN gateways, routers, switches, load balancers and file-transfer servers.
  • By an approximate CyphrQ count, about 37 of the 309 CISA KEV entries added from 28 October 2025 to 26 October 2026 were edge devices, roughly 1 in 8. That is a floor, not a majority.
  • The risk comes from reach: one exploited edge device can open a path to everything behind it.
  • ED 25-03 showed that a patch may not remove an attacker already on a device.
  • Start with an inventory and with taking management interfaces off the internet; both cost little.
  • Plan replacement of unsupported kit before the vendor's end-of-support date, not after.

Sources