Patched Isn’t the Same as Protected

Two stories broke within days of each other this month, on opposite ends of the network. Neither one is about a new kind of attack. Both are about the same old problem: the gap between deploying a security control and actually knowing whether it’s still doing the job it was bought to do.

The edge gateway that keeps reopening

On September 2, SonicWall disclosed that attackers were actively chaining two new zero-day vulnerabilities, CVE-2026-83548 and CVE-2026-83549, against its SMA1000 series appliances, the secure remote-access gateways used by large enterprises, government agencies, and critical infrastructure operators to let employees connect in from outside the network. The first flaw is a maximum-severity command injection issue in the appliance’s public-facing WorkPlace interface, rooted in a server-side request forgery weakness; the second lets an attacker with elevated access run arbitrary commands on the device itself.

What makes this notable isn’t the CVSS score. It’s the pattern. This is the second SMA1000 zero-day chain disclosed in seven weeks, following a nearly identical structure, a pre-authentication bypass chained into privilege escalation, that SonicWall patched in July after CISA confirmed ransomware groups were already exploiting it in the wild. Two distinct exploit chains, hitting the same class of weakness, on the same product line, within two months. Customers who patched diligently in July did the right thing, and were exposed to a new variant of the same problem within weeks.

This is the uncomfortable truth about edge devices like VPN gateways: they are, by design, internet-facing, and they sit at the exact seam between “outside” and “inside” that every layered security model depends on holding. When that seam fails, it doesn’t just expose the device; in prior SonicWall incidents, researchers have documented attackers pivoting directly from a compromised appliance into internal Active Directory infrastructure, turning the remote-access gateway into a launchpad for lateral movement rather than a checkpoint that stops it.

The mail server that’s running out of runway

The second story is quieter but arguably more consequential for the number of organizations it touches. In August, Microsoft patched CVE-2026-62911, an authentication bypass affecting Exchange Server 2016, 2019, and the newer Subscription Edition, that lets an attacker take over every mailbox on an affected server, reading email, sending as any user, and pulling attachments, once they’ve gained even basic access. Exploit code is already circulating publicly, according to the Netherlands’ national cybersecurity center, and as of early September, security researchers at Shadowserver had counted nearly 22,000 internet-facing Exchange servers still unpatched, the largest concentrations in the United States and Germany.

Here’s the part that should concern security leaders more than the CVE itself: Exchange 2016 and 2019 are no longer under standard support. Organizations still running them are dependent on Microsoft’s Extended Security Update program, and Microsoft has confirmed that program ends for good in October 2026, with no further extensions, “even if you currently have a Period 2 ESU.” After that date, any future vulnerability discovered in these versions simply will not be patched, at any price, for any customer.

That turns a normal patch-management problem into something else entirely: a fixed expiration date on an organization’s ability to remediate a widely deployed, internet-facing, identity-adjacent system through official means. Compensating controls; network segmentation, web application firewalls, restricted administrative access; can reduce specific risks, but they are, by nature, reactive and partial. They cannot substitute for a vendor patch against a vulnerability that hasn’t been discovered yet.

The common thread

SonicWall and Exchange sit at opposite ends of the environment; one is the front door, the other is deep inside; but both stories illustrate the same failure mode. A security control’s value isn’t fixed at the moment it’s deployed. It’s fixed at the moment it was last tested against current attacker behavior. A VPN appliance that was hardened against July’s exploit chain said nothing about its exposure to September’s. A mail server that was fully supported in 2020 says nothing about its exposure in an environment where the vendor has now committed, in writing, to stop patching it.

This is why “patched” and “protected” are not the same claim, and treating them as interchangeable is where a lot of security programs quietly lose ground. Patch compliance tells you a known issue, as of a known date, has been closed. It tells you nothing about whether a new exploit chain against the same product line is already circulating, or whether the clock has started on a vendor’s support lifecycle that will leave the same device permanently exposed a few months from now.

The organizations that come through stories like these in reasonable shape tend to share one habit: they don’t treat perimeter and infrastructure devices as “set and forget” once a patch is applied. They actively monitor those devices for the kind of anomalous behavior that shows up after a compromise; unexpected outbound connections from an appliance that should never be initiating them, authentication patterns that don’t match normal usage, lateral movement attempts from a system that has no legitimate reason to be talking to a domain controller. That’s a fundamentally different discipline than patch management, and it’s the one that catches the exploit chain nobody has named yet.

Neither SonicWall nor Microsoft did anything unusual here, vendors patch vulnerabilities and eventually retire old software, and both are managing genuinely hard problems at scale. The obligation on the other side of that relationship is for security teams to stop treating the patch cycle as the finish line. It’s the starting gun for the next question: what’s watching this device for the thing the patch didn’t anticipate?