Edge Devices Are the Front Door: What This Week's FortiMail, Cisco SD-WAN and NetScaler Zero-Days Say About Your Perimeter
Between 27 September and 1 October 2026, critical flaws in Citrix NetScaler, Cisco Catalyst SD-WAN Manager and Fortinet FortiMail were confirmed exploited. What each allows, what to do this week, why patching is only half the response, and how to assess the perimeter.
Threat Intelligence
Between 27 September and 1 October 2026, critical vulnerabilities in internet-facing appliances from three vendors were confirmed exploited and added to CISA's Known Exploited Vulnerabilities catalogue: Citrix NetScaler, Cisco Catalyst SD-WAN Manager and Fortinet FortiMail. Here is what each one allows, what to do this week if you run any of them, why patching is only half the response, and what the pattern says about how the perimeter should be assessed.
In short. All three flaws are reachable without credentials from the network the device faces. If you run an affected device, look for signs of compromise before you patch, because CISA warns that patching can remove the forensic evidence, then patch or apply the vendor's mitigation, then assume anything the device held, such as credentials, sessions and keys, may be in someone else's hands. The longer-term lesson is that edge devices are a tier of their own: inventoried, isolated from the internet on their management side, monitored like servers, and tested like any other way in.
Five days, three vendors
| Date | Product | CVE | What it allows |
|---|---|---|---|
| 27 Sep | Citrix NetScaler ADC and Gateway | CVE-2026-88771 | Unauthenticated remote command execution through improper input validation. Affects all NetScaler ADC and Gateway deployments, including default configurations. |
| 27 Sep | Citrix NetScaler ADC and Gateway | CVE-2026-88772 | Memory overflow leading to remote code execution or denial of service when DTLS is enabled, which it is by default on VPN virtual servers. |
| 30 Sep | Cisco Catalyst SD-WAN Manager | CVE-2026-76504 | Authentication bypass: a crafted HTTP request to the API gives access as the admin user. CVSS 9.8. No workaround; fixed software is available. |
| 1 Oct | Fortinet FortiMail | CVE-2026-104286 | Unauthenticated arbitrary file write through path traversal with null-byte handling, via crafted HTTP or HTTPS requests. CVSS 9.8. |
Each was confirmed exploited in the wild by its vendor or by CISA before most organisations had a fix installed. Citrix released fixes for the NetScaler flaws in bulletin CTX697096 on 27 September, the same day CISA added both to the catalogue, and reporting since indicates exploitation began days before public notification. Cisco's advisory and the CISA catalogue entry for the SD-WAN Manager flaw both came on 30 September. Fortinet published advisory FG-IR-26-175 for FortiMail on 1 October, and CISA added it the same day.
The details that matter for each
Citrix NetScaler ADC and Gateway
The bulletin covers eight CVEs, CVE-2026-88771 through CVE-2026-88778, of which the first two are critical and exploited. Either can independently lead to remote code execution, and attackers have used them to install web shells for initial access and persistence. CISA's advice is specific and unusual: check for indications of compromise before patching, and preserve forensic evidence before updating, because the update may remove the evidence you need to know whether you were breached. Citrix makes indicators of compromise available through NetScaler Console.
Cisco Catalyst SD-WAN Manager
The flaw stems from improper handling of URL encoding and affects the product regardless of configuration. Cisco has said there is no workaround, so the response is the fixed release plus restricting who can reach the management interface. Systems with management ports exposed to the internet are the ones at immediate risk. An attacker with admin access to an SD-WAN manager controls the configuration of the network it manages, which makes this a network-wide problem rather than a single-device one.
Fortinet FortiMail
Affected releases are 8.0.0 to 8.0.1, 7.6.0 to 7.6.6, 7.4.0 to 7.4.8 and 7.2.0 to 7.2.9. Fortinet's advisory lists 8.0.2, 7.6.7 and 7.4.9 as fixed, and tells 7.2 users to move to 7.4 or later; early reports noted the fixed builds were not yet available when the advisory first appeared, so check the advisory for current status. Until you can upgrade, the vendor's workaround is to disable the Identity-Based Encryption feature or restrict management interface access to trusted networks only. Fortinet published indicators including file hashes, IP addresses and log patterns, among them unauthorised archive account creation and cron job execution.
Why the edge keeps being the way in
None of this is new. Firewalls, VPN gateways, application delivery controllers, email gateways and SD-WAN controllers have been among the most exploited targets for several years, and the reasons are structural.
- They face the internet by design. A vulnerability in the part of the device that listens to the world is reachable by anyone, with no phishing email required.
- They sit in a privileged position. They terminate remote access, hold credentials and session tokens, see traffic in clear, and are trusted by the network behind them. Owning one is often better than owning a server.
- They are poorly watched. Most appliances cannot run the endpoint detection that protects servers and laptops, and their logs are often thin, kept locally, or not forwarded to the SOC at all.
- They are hard to patch quickly. Updating a VPN gateway or a load balancer means downtime for everything behind it, so patch windows slip, and CISA's NetScaler alert explicitly acknowledged that complexity.
- They outlive their support. Devices past end of support stop receiving fixes but keep running, because replacing them is a project nobody has funded.
If you run any of these: this week
Step 1 — Confirm exposure, including the devices nobody remembers
List every NetScaler, SD-WAN Manager and FortiMail instance, with version and whether its management interface is reachable from the internet. Check from the outside as well as from the asset register: the test appliance from two years ago and the one a subsidiary runs are where these campaigns land.
Step 2 — Look for compromise before you patch
Run the vendors' indicators of compromise, capture logs and, where feasible, a forensic image or the vendor-recommended collection. CISA's NetScaler guidance is explicit that patching can remove the evidence you need.
Step 3 — Patch, or apply the vendor's mitigation
Install the fixed release. Where none is available yet, apply the documented workaround, which for FortiMail means disabling Identity-Based Encryption or restricting management access, and record when the exposure window closed.
Step 4 — Treat what the device held as exposed
If there is any sign of compromise, rotate credentials stored on or passing through the device, terminate active sessions, review local and administrative accounts for ones nobody created, and check scheduled tasks. Certificates and keys held on the appliance need the same treatment.
Step 5 — Take the management plane off the internet
Management interfaces should be reachable only from a dedicated administrative network. This one change would have reduced exposure to two of the four flaws above and is worth making permanent rather than as an emergency measure.
Step 6 — Hunt behind the device
A compromised edge device is a starting point. Look at authentications originating from it, new connections from it into the internal network, and web shells on any related web-facing component, over the period since the vulnerability was first exploited, not only since disclosure.
What patching does not undo
A patch closes the hole. It does not remove a web shell that was already planted, an administrator account the attacker created, a scheduled job, or credentials that were harvested while the device was compromised. With exploitation beginning before public disclosure, the question for any exposed device is not only "are we patched?" but "what happened between first exploitation and our patch?".
That second question needs evidence: device logs, ideally forwarded and retained elsewhere, network flow records, and authentication logs from the systems behind the device. If those were not being collected before the incident, the honest answer may be that you cannot tell, which is a finding in itself. It is the case for threat hunting over the exposure window and, where indicators are found, digital forensics and incident response.
If you confirm a compromise, check your notification duties straight away. In India, for example, CERT-In's directions require reportable incidents to be reported within six hours, and RBI-regulated entities have their own six-hour clock; see our guides to CERT-In's six-hour rule and RBI's 2026 Cybersecurity Directions.
Treat the edge as its own tier
Governments have been saying this in writing. In February 2025 CISA, Australia's ACSC, the Canadian Centre for Cyber Security, the UK's NCSC and other partners published joint guidance on mitigation strategies and security considerations for edge devices. It covers not using end-of-life devices, phishing-resistant multi-factor authentication, centralised authentication with role-based access, and logging good enough to support forensics. In February 2026 CISA's Binding Operational Directive 26-02 ordered US federal agencies to inventory and remove end-of-support edge devices. Neither applies directly to most private organisations, and both describe what good looks like for everyone.
| Practice | What it looks like | What it would have changed this week |
|---|---|---|
| Inventory and lifecycle | Every edge device known, with version, support status and owner; end-of-support devices on a funded replacement plan | Exposure confirmed in minutes, not days |
| Management plane isolation | Admin interfaces reachable only from a dedicated management network, never the internet | Direct exposure to the SD-WAN and FortiMail management attack surface removed |
| Strong administrative access | Phishing-resistant MFA, central authentication, role-based access, no shared admin accounts | Unauthorised accounts stand out against a known list |
| Logging that supports forensics | Device logs forwarded to the SIEM and retained off the device, with alerting on configuration and account changes | The "what happened before we patched?" question has an answer |
| Configuration review | Rule bases, exposed services and enabled features reviewed against need; unused features such as portals and optional services switched off | Fewer reachable features, fewer flaws that apply |
| Assume breach behind it | Segmentation so a compromised edge device cannot reach everything; internal monitoring of what it connects to | A compromised appliance becomes an incident, not a breach |
What a perimeter review actually checks
A vulnerability scan of your external IP addresses will tell you that a NetScaler exists and, sometimes, its version. It will not tell you whether its management interface should be reachable, whether its configuration matches its purpose, or whether you would notice an attacker using it. A firewall and perimeter review looks at the devices themselves:
- Exposure: what each device presents to the internet, including management, user portals and optional services, compared with what it needs to.
- Currency: firmware versions against vendor advisories and support status, with end-of-support devices called out.
- Rule bases: overly broad rules, unused and shadowed rules, temporary rules that became permanent, and rules nobody can explain.
- Administration: who can log in, how, from where, with what authentication, and whether every account belongs to someone.
- Remote access: VPN configuration, authentication strength, session handling and what a connected user can reach.
- Visibility: whether logs leave the device, whether the SOC receives them, and whether configuration changes raise an alert.
Paired with attack surface management to keep the inventory honest between reviews, and an external network penetration test to see the perimeter the way an attacker does, it turns the edge from a blind spot into a tier you can account for.
Frequently Asked Questions
Click any question to expand the answer.
QWhich vulnerabilities were exploited between 27 September and 1 October 2026?
CVE-2026-88771 and CVE-2026-88772 in Citrix NetScaler ADC and Gateway, CVE-2026-76504 in Cisco Catalyst SD-WAN Manager, and CVE-2026-104286 in Fortinet FortiMail. All four were added to CISA's Known Exploited Vulnerabilities catalogue in that window.
QShould we patch first or investigate first?
For NetScaler, CISA's guidance is to check for indications of compromise and preserve forensic evidence before updating, because the update may remove the evidence. The same reasoning applies to any exploited edge device: capture logs and run the vendor's indicators quickly, then patch without delay.
QIs there a fix for the FortiMail vulnerability?
Fortinet's advisory FG-IR-26-175 lists 8.0.2, 7.6.7 and 7.4.9 as fixed releases, with 7.2 users told to move to 7.4 or later. Early reports said the fixed builds were not yet available when the advisory was first published. The interim workaround is to disable Identity-Based Encryption or restrict management interface access to trusted networks.
QIs there a workaround for the Cisco SD-WAN Manager flaw?
Cisco has said there is no workaround; fixed software is available. Restricting access to the management interface reduces exposure while you upgrade, and systems with management ports reachable from the internet are the ones at immediate risk.
QWe have patched. Are we safe?
Not necessarily. Patching closes the vulnerability but does not remove anything an attacker installed or took before you patched, such as web shells, new accounts, scheduled tasks or harvested credentials. If the device was exposed while the flaw was being exploited, investigate the window between first exploitation and your patch.
QWhy are edge devices exploited so often?
They face the internet by design, sit in a privileged position holding credentials and seeing traffic, usually cannot run endpoint detection, often have thin or local-only logs, are hard to patch without downtime, and frequently stay in service after vendor support ends.
QShould management interfaces ever face the internet?
No. Administrative interfaces should be reachable only from a dedicated management network. It is one of the cheapest, most effective changes available, and it removes a large share of the attack surface that edge-device vulnerabilities depend on.
QDoes BOD 26-02 apply to private companies?
No. Binding Operational Directive 26-02 applies to US federal civilian agencies. It is still a useful benchmark: inventory end-of-support edge devices, replace them on a timeline, and keep a continuous process for finding new ones.
QWill a vulnerability scan find these problems?
A scan can identify a device and often its version, which helps with exposure. It cannot tell you whether the management interface should be reachable, whether the configuration fits its purpose, whether accounts on it are legitimate, or whether you would detect someone using it. That takes a configuration review and testing.
QWhat should the SOC receive from edge devices?
Authentication events, administrative actions, configuration changes, account changes and connection logs, forwarded off the device and retained. Alerts on new administrative accounts and configuration changes outside a change window are the minimum, because they are what an attacker on the device produces.
Related reading
Keeping an accurate picture of what you expose is the foundation; our guide to external attack surface management covers how. On the difference between finding vulnerabilities and managing them to closure, see vulnerability assessment versus vulnerability management. For limiting what a compromised device can reach, our zero trust architecture guide.
About Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, with offensive testing at the centre of what we do. We look at your perimeter the way the people exploiting these devices do, and help you close what we find.
What we can do for you:
- Perimeter review. A firewall and perimeter review of every edge device: exposure, firmware currency, rule bases, administration, remote access and logging, with findings prioritised by what an attacker could reach.
- Knowing what you expose. Attack surface management to find the devices that are not on the register, and network penetration testing of the external perimeter and what lies behind it.
- When it may already have happened. Threat hunting across the exposure window, incident response and forensics, and 24×7 monitoring that receives your edge device logs, not only your endpoints'.
Sources
- CISA, Critical zero-day vulnerabilities exploited in Citrix NetScaler ADC, Gateway, 27 September 2026, revised 28 September.
- Citrix, security bulletin CTX697096, CVE-2026-88771 to CVE-2026-88778.
- CISA, CISA adds one known exploited vulnerability to catalog, 30 September 2026; and Rapid7, analysis of CVE-2026-76504.
- Fortinet PSIRT, FG-IR-26-175, 1 October 2026; and BleepingComputer, Fortinet warns of critical FortiMail flaw exploited in zero-day attacks.
- CISA and partners, joint guidance on edge devices, 4 February 2025; and Reducing the attack surface for end-of-support edge devices, a joint fact sheet published in February 2026, the month CISA issued BOD 26-02.
Affected and fixed versions change as vendors update their advisories. Always confirm against the current vendor advisory before acting.
Adayptus Consulting
Offensive Security and Threat Intelligence, Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, with offensive testing at the centre of its work across networks, applications and cloud.
