In under three weeks, three major security incidents rattled enterprise infrastructure worldwide. It is no coincidence that all three targeted the same category of equipment, the systems sitting at the gate between a company's internal network and the outside world.

On September 1, 2026, SonicWall disclosed two zero-days in its SMA1000 remote-access appliance line, CVE-2026-83548 and CVE-2026-83549. The first is a pre-authentication server-side request forgery flaw with a perfect CVSS score of 10.0, exploitable with no credentials at all. The second, scored 7.8, requires prior access but enables remote code execution. The real danger is that these two "moderate" flaws chain into a complete attack path. An attacker uses the first to breach the outer layer, then the second to take full control, never needing a username or password. CISA added both to its Known Exploited Vulnerabilities catalog just a day after disclosure and set a three-day remediation deadline for federal agencies. This was also not the first time the SMA1000 line was hit by a similar zero-day since December, a track record that alone should prompt anyone still running it to rethink their vendor security review cycle.

Two weeks later, it was Cisco's turn. On September 16, Cisco issued an emergency advisory for Identity Services Engine, the system many large organizations rely on to control who and what devices can get onto their network. The flaw, CVE-2026-76460, also carries a CVSS score of 10.0. The root cause is simple and unsettling at once, a single API endpoint failed to properly enforce authentication, letting an attacker send one specially crafted request and walk straight into the management console with no account whatsoever. From there, the path to root-level command execution was wide open. Once again, CISA set a three-day deadline the moment the flaw entered the KEV catalog.

What makes these two cases weigh even heavier is a third story running in parallel. At the end of October 2026, Extended Security Update support for Microsoft Exchange Server 2016 and 2019 officially ends, with no further extension. Microsoft has confirmed there will be no third period. That means organizations still running these versions, and there are plenty, are racing against the clock not just to patch a known critical flaw (CVE-2026-62911, an authentication bypass Microsoft fixed back in August), but to have an exit plan ready before that date arrives. After October 31, any new vulnerability discovered in Exchange 2016 or 2019 will never receive an official fix again, no matter how severe.

None of these three vendors are unfamiliar names in Indonesia. SonicWall and Cisco form the network backbone at plenty of banks, state-owned enterprises, and mid-to-large businesses here, while Microsoft Exchange still anchors corporate email at many institutions. The exposure from these three incidents reaches into the local technology landscape as well, even though global coverage has focused mostly on North America and Europe.

Four headline numbers from the September 2026 zero-day wave, CVSS 10.0 for SonicWall, CVSS 10.0 for Cisco ISE, a three-day federal deadline, and the end of Exchange 2016/2019 support

The Same Pattern, Three Times Running

Draw a straight line through these incidents and one thread stands out. Attackers are no longer bothering to hunt for flaws in the everyday business applications a company runs. They are targeting the infrastructure that sits at the highest point of trust, remote-access gateways, network access control systems, mail servers, because a single flaw there is equivalent to a master key for the entire internal network, not just one application.

The economics make sense from an attacker's perspective. Breaching one web application usually only exposes the data that application serves. Breaching a VPN gateway or an identity system exposes everything behind it. The payoff is disproportionately larger than the effort required, which is exactly why this category of equipment has become a favored target across the last two years of major attack waves, not just this particular month.

Timeline of four milestones in the September 2026 zero-day wave, from the SonicWall disclosure on September 1 to the Cisco ISE emergency advisory on September 16

Why "We Already Have a Firewall" Isn't Enough

A point easy to miss in the SonicWall case above, the first flaw (SSRF, CVSS 10.0) on its own can only force the server to call internal addresses that should be unreachable from outside, which looks limited when assessed in isolation. The second flaw (RCE, CVSS 7.8) requires prior access, so reviewed on its own it also reads as less alarming. Combined, the two form a complete attack chain requiring no credentials at all.

This is a recurring pattern in security. Risk assessments that only look at one vulnerability at a time frequently miss the real picture, because real attackers do not play one flaw at a time. They look for combinations. A system that appears reasonably secure when evaluated flaw by flaw can turn out to be wide open the moment two or three minor weaknesses are chained together.

Comparison of the two SonicWall SMA1000 flaws, a pre-auth SSRF at CVSS 10.0 and a post-auth RCE at CVSS 7.8, chained into one complete attack path

When Patch Speed Stops Being the Fix

At this point, the standard advice is to patch immediately once a vendor ships a fix. That is correct, and the three cases above show why the window for doing so is now measured in days, not weeks, the moment a flaw lands in the KEV catalog.

But the Exchange 2016/2019 case exposes the limit of that advice. Patch speed only helps for as long as a vendor keeps shipping patches. Once official support ends, no matter how fast an IT team reacts, there is nothing left to patch. What remains is a choice between two paths, migrate to a version still under support, or accept a risk that keeps compounding with no end date.

This is why system security genuinely needs two axes of assessment, not one. The first, how quickly an organization patches known flaws. The second, often overlooked, whether the systems in use are still inside a vendor's support lifecycle at all. An organization that patches fast but is still running end-of-life systems is actually in the most fragile position, because its reaction speed does not matter once the fix simply never arrives.

A two-axis risk matrix, patch speed against vendor support status, four quadrants from a false sense of security to the highest risk

What Business Leaders Should Do, Not Just IT Teams

These three incidents are not a reason to panic, but they are a good reason to revisit a few fundamentals.

First, maintain a clear inventory of every system facing the outside network, VPN gateways, identity systems, mail servers, along with each one's official end-of-support date. Without an inventory that is kept current, it is difficult to know which risk is actually being carried.

Second, actively monitor the Known Exploited Vulnerabilities catalog and official vendor advisories, rather than waiting for a story to go viral. A flaw entering KEV means it is already being exploited in the real world, not a theoretical risk, and that is the strongest possible signal to prioritize patching.

Third, set internal patch SLAs based on severity, not a routine monthly maintenance window. A CVSS 10.0 flaw that has entered KEV should be patched within days, not held for the next scheduled update.

Fourth, run independent security testing on a regular cadence, not just once before a release. Patch management closes flaws that are already publicly known. Security testing uncovers flaws and dangerous combinations that no one has reported yet, including chains as dangerous as the one seen in the SonicWall case above.

Four steps for business leaders, inventory gateway-facing assets, monitor the KEV catalog, set severity-based patch SLAs, and run independent security testing

How XETUP Can Help

The four steps above sound straightforward on paper, but running them consistently, on top of an already demanding operation, is a discipline of its own. XETUP's Cybersecurity team helps businesses embed security testing across the entire development lifecycle rather than running it once before go-live, alongside auditing the infrastructure facing the outside network to map risk before it becomes the next headline like the three cases above.