Three Edge Appliance Zero-Days in Two Weeks: Why Patching Is Not Enough

In the first two weeks of October 2026, three internet-facing security appliances were exploited before fixes existed:

• FortiMail — CVE-2026-104286, CVSS 9.8, unauthenticated arbitrary file write. Disclosed 1 October, already being exploited.
• Ivanti Connect Secure — CVE-2026-104935, CVSS 8.6. An attacker chained three zero-days to get unauthenticated root on a fully patched appliance. One of the three is still unfixed.
• Cisco Catalyst SD-WAN Manager — CVE-2026-76504, CVSS 9.8, pre-auth admin access, no workaround. Covered separately.

The pattern is not a coincidence, and the response is not only "patch faster".

What to patch, precisely

FortiMail (Fortinet advisory FG-IR-26-175). A path-traversal flaw combined with poor NULL-byte handling — CWE-22 and CWE-158 — lets an unauthenticated attacker write arbitrary files via crafted HTTP or HTTPS requests. Affected: 8.0.0–8.0.1, 7.6.0–7.6.6, 7.4.0–7.4.8, 7.2.0–7.2.9.

CISA added it to the Known Exploited Vulnerabilities catalog on 1 October with a remediation deadline of 4 October. A three-day federal deadline is a strong signal about how fast this one was moving.

Ivanti Connect Secure. Affected: 25.1.1.1 and prior, 25.1.2.2 and prior, 22.8R2.4 and prior. Fixed in 22.8R2.5, 25.1.1.2, 25.1.3.0 and 25.1.3.1. Ivanti acknowledged limited exploitation in the wild on 13 October; Volexity attributes the activity to an actor it tracks as UTA0576, with exploitation starting around 3 October. CISA has urged patching.

Read the Ivanti detail carefully, because it is unusual. CVE-2026-104935 covers two of the three flaws — an authentication bypass and a remote code execution bug. The third has no fix yet. The chain produced root on an appliance that was fully patched at the time, which means "we are up to date" was not a defence and is not a complete defence now.

Why patching is not sufficient here

For all three, exploitation preceded the patch. That ordering has a consequence people routinely miss: a patch closes the door, it does not evict whoever came through it.

If an attacker wrote a web shell to your FortiMail on 2 October, upgrading to 8.0.2 on the 6th leaves the web shell exactly where it is. If an attacker got root on your Ivanti appliance, they may have placed persistence that survives the upgrade — and on appliances you cannot inspect freely, that is hard to rule out.

So the sequence for anything in this category is patch, then hunt, then decide whether you trust the box.

Hunt

• FortiMail — look for files that should not exist in web-accessible paths, unexpected changes to configuration or mail-routing rules, new administrative accounts, and outbound connections from the appliance. An arbitrary file write is usually a route to code execution, so treat it as potential compromise, not as a near miss.
• Ivanti Connect Secure — run the Integrity Checker Tool, and do not stop at a clean result; previous Ivanti campaigns have included tampering with that tool's expectations. Volexity's write-up carries indicators worth feeding into your hunting. Look for new local accounts, altered configuration, unexpected outbound traffic and anomalous VPN sessions.
• Cisco SD-WAN Manager — POST requests to URL-encoded variants of /j_security_check, then device-template and policy changes.

Then decide whether to rebuild

For an appliance where you found anything, or where you cannot establish that you did not, rebuilding from vendor media and restoring a known-good configuration is the only clean answer. It is disruptive and it is frequently the right call — particularly for a VPN concentrator, which holds credentials and sits by definition at the edge of your trust boundary.

Assume credentials passed through a compromised appliance are compromised. For a VPN, that is every user who authenticated through it during the window: rotate the appliance's own secrets and certificates, consider forcing a password reset, and invalidate active sessions. For a mail gateway, it is the service accounts it holds.

The structural point

The equipment we buy to defend the perimeter has become one of the most attractive targets on it. Three properties combine badly:

They must be reachable. A VPN concentrator nobody can reach is useless. The same is true of a mail gateway and a management console. There is no segmenting away the primary function.

They are complex and opaque. A modern security appliance is a large software stack — web server, parsers, management UI, agents — shipped as a closed box. You cannot install your own EDR on most of them, you often cannot read their filesystem, and you are reliant on the vendor's own integrity tooling to tell you whether they have been tampered with.

Everything behind them trusts them. A compromised VPN appliance is not a compromised server; it is a position inside the authentication path for every remote user.

That is why these devices get the attention, and why pre-auth flaws in them are worth an out-of-hours change window.

What actually reduces this risk

Ordered by how much they help:

1. Cut what is reachable. Administrative interfaces should not be internet facing, on any of these products. The data plane has to be — the VPN has to accept connections, the mail gateway has to accept mail — but the management UI does not. Several historic appliance compromises were only possible because the admin interface answered the whole internet.

2. Put the appliance in its own zone. Treat it as semi-trusted, not internal. It should not be able to reach arbitrary internal hosts, and it certainly should not reach your domain controllers or backup infrastructure except on the specific ports it needs. Same reasoning as segmentation generally.

3. Have a patch path you can execute in hours. This is mostly organisational: a known maintenance window, a tested rollback, a change process with an emergency track, and somebody whose job it is to read vendor advisories. See patch management.

4. Collect the logs off the box. Appliance storage is small and rotates fast. If the logs that would prove or disprove compromise live only on the device, you will not have them when you need them. Ship them to a SIEM.

5. Reduce dependence on a single appliance for access. If your only remote access is one VPN concentrator, a bad week for its vendor is a bad week for you. Zero-trust access as an alternative or complement to VPN is worth looking at — not because brokers cannot have vulnerabilities, but because having a second path means an emergency patch is not also an outage.

6. Know your inventory and versions. "Are we affected?" should be a five-minute question. For most organisations it is a two-day question, which is two days of exposure.

A note on judgement

None of this means these products are bad, or that the vendors are negligent. Fortinet, Ivanti and Cisco all shipped fixes, and complex software facing the internet will have vulnerabilities — the realistic question is how fast they are found, fixed and deployed.

It does mean the appliance deserves the same scepticism as any other internet-facing server: patched quickly, logged externally, segmented from everything it does not need, and rebuilt without much agonising if there is a reason to doubt it.

Sources

• Exploited Fortinet FortiMail Zero-Day Calls for Urgent Action — SecurityWeek
• Critical FortiMail Zero-Day Flaw Exploited in Attacks — The Hacker News
• A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days — Volexity
• Attacker Chains Three Ivanti Connect Secure Zero-Days for Root Access — The Hacker News
• CISA Urges Patching Newly Exploited Vulnerability in Ivanti Connect Secure
• Cisco Patches Exploited Catalyst SD-WAN Zero-Day Vulnerability — SecurityWeek