The flaws exploited this week mostly already had a fix

The scariest word in this week's advisories was "exploited," and almost every time it appeared it was attached to a bug the vendor had already fixed. Not a novel zero-day nobody could have stopped. A patched flaw, sometimes patched weeks earlier, that attackers got around to weaponizing only after the security world had moved on to the next headline.

That is the pattern worth naming this week. Of the 2,517 vulnerabilities that reached a logged decision on our threat desk over the past week, around 50 carried a signal of active exploitation by our own tracking. The ones that mattered were not the unknowns. They were the knowns you had not gotten to yet.

What "now exploited" meant this week

For most of the week's exploited flaws the fix was already available, and the exploitation was the fresh event. Sangoma Switchvox is the clearest case. Sangoma shipped the fix, Switchvox 8.4.0.2, on July 14. The flaw, CVE-2026-9586, is an unauthenticated SQL injection in the phone-provisioning path that leads to code execution. Nothing happened for nearly seven weeks. Then on August 30 the security firm Horizon3, working with Defused Cyber, reported real exploitation tripping its honeypots, with roughly 4,000 Switchvox consoles still reachable from the internet. The bug was old; the attack was the new part.

Microsoft Exchange followed the same shape. Microsoft patched CVE-2026-62911, an authentication bypass that lets an attacker replay the Exchange server's own machine-account credentials and act with its privileges, on August 11 as part of Patch Tuesday. Within weeks exploit code was circulating publicly, and the Shadowserver Foundation counted 21,899 unpatched Exchange servers still exposed at the end of August. A fix from Patch Tuesday turned into a live threat once the exploit was public and the exposed population had not shrunk.

JFrog Artifactory compressed the timeline into days. JFrog released patched builds on August 28. Within days, researchers at watchTowr reported attackers forging administrative tokens through the critical flaw CVE-2026-82329, rated CVSS 9.8, and it reached CISA's Known Exploited Vulnerabilities catalog in early September. LiteLLM's model-gateway authentication bypass, CVE-2026-59822, joined the KEV catalog on September 2 with a September 16 federal patch deadline; its fix, version 1.84.0, also predated the exploitation.

The zero-days were the exception

Two stories this week were genuine unknowns, and they are worth separating out. SonicWall's SMA1000 secure-access gateway had a pair of flaws, an unauthenticated server-side request forgery (CVE-2026-83548) chained to command injection (CVE-2026-83549), that SonicWall's own incident response found in use before a fix existed. N-able's N-central console took a maximum-severity, unauthenticated code-execution bug, CVE-2026-86218, its fourth emergency hotfix in five weeks, though whether it was exploited in production is contested between N-able's incident notice and its release notes.

Zero-days get the coverage because they are dramatic, and because there is genuinely nothing you can do about them until the vendor moves. That is the point. They are the slice of your risk you cannot pull forward in time. This week they were the minority of the exploitation we tracked. The volume sat on the other side of the table, in flaws every one of these vendors had already handed you the fix for.

Why the delay is predictable

The gap between a fix and its exploitation is not random. It is the time it takes to diff the patch, rebuild the bug from the change, write a proof-of-concept, and point a scanner at every exposed host. That work is fast now, and increasingly public.

Once a fix ships, the vulnerable code is described by the fix itself: the patch is a specification for the bug it closes. A working proof-of-concept follows, often within days, and then the exploitation is not aimed at anyone in particular. It is mass scanning against whatever is still exposed. That is why the exposure counts matter more than the severity score here. Those 21,899 Exchange servers and roughly 4,000 Switchvox consoles are not the victims of a patient adversary. They are the addressable market for a script.

For a defender, the useful part is that a predictable delay is a window you can plan around, if you can see the scanning begin. Late n-day exploitation leaves a signature on the affected product itself: a spike of traffic to the one endpoint the advisory named, from source addresses you have never seen, right after the technical details go public.

Switchvox: repeated POSTs to the phone-provisioning endpoint from new source IPs, with database-layer errors in the app log
Exchange: NTLM authentication from the Exchange machine account to itself; new .aspx files under the web roots
Artifactory: admin-scoped API calls bearing tokens your identity provider never issued
General: a jump in 4xx and 5xx responses on a single advisory-named path, from many new IPs, in the days after a patch publishes

None of that requires knowing the exploit. It requires knowing which of your systems are exposed, which advisory named which endpoint, and what your own logs looked like before the patch. If watching every product's logs by hand is not realistic, that is the case for continuous vulnerability detection and threat hunting against the exposed edge, rather than a scramble each time a proof-of-concept drops.

Rank the backlog by exposure, not by disclosure date

The takeaway is a re-ordering, not a new tool. The flaws most likely to reach you this week share three traits: the vendor has already shipped a fix, the affected service is reachable from the internet in your environment, and a public proof-of-concept exists. That is a filter you can run today.

• Pull the advisories from the last one to two months for the products you actually expose, and treat a skipped July fix as a live September risk.

• Weight by exposure over raw severity. An internet-facing service with a medium score and a public proof-of-concept outranks an internal-only critical that nobody outside can reach.

• Treat the appearance of a public proof-of-concept as the real deadline, ahead of any federal due date. CISA's September 16 mark on LiteLLM is a floor, not the moment the risk starts.

• For anything you patched late, hunt the exposure window rather than assume the patch settled it. A fix tells you nothing about whether the box was already touched.

The zero-days will keep coming, and you will keep being unable to prevent them. The n-days are the part you control. This week, they were most of the damage.