In August, CISA added two vulnerabilities to its Known Exploited Vulnerabilities catalog and gave federal agencies three days to fix each one. Both already had patches. One of them had a patch available seven months earlier.
That is the part worth sitting with. Almost none of the damage done this summer required a secret flaw that nobody knew about. It required a fix that existed and had not been installed yet. If your organization patches on a monthly cycle, that is the gap attackers are living in, and it has gotten dramatically more dangerous in the last twelve months.
What actually happened in August
Four cases tell the story clearly.
Oracle WebLogic (CVE-2026-21962). A CVSS 10.0 flaw that lets an unauthenticated attacker compromise the server. Oracle shipped the fix in January 2026. Attackers began exploiting it on January 22, immediately after proof-of-concept code went public. CISA added it to the KEV catalog on August 24 and set a federal deadline of August 27. Seven months of active exploitation against systems that could have been patched in January.
Citrix NetScaler (CVE-2026-8452). Citrix released the patch on June 30 and described the issue as a memory overflow causing denial of service. On August 14, researchers at watchTowr published an analysis showing it could be chained into full unauthenticated remote code execution. Exploitation started within days, with attackers dropping web shells on internet-facing gateways. KEV listing came August 26, federal deadline August 29.
PTC Windchill (CVE-2026-12569). PTC began releasing patches on June 17 and the flaw hit the KEV catalog on June 25. Cl0p ran a data theft campaign against product lifecycle management systems anyway. Starting August 12, the group publicly named more than 40 victims, including Shell, Philips, Fiserv, Zebra Technologies, Ingersoll Rand, and Toast. These are not companies without security budgets.
SAP Commerce Cloud (CVE-2026-58231). Another CVSS 10.0. Exploitation attempts began roughly three days after disclosure. What makes this one notable is that there was still no public proof-of-concept code at the time. Attackers reverse engineered the patch themselves and moved.
Two clocks, moving in opposite directions
There are two timelines that decide whether you get hit.
The first is time to weaponization: how long between a fix becoming public and attackers having a working exploit. That number used to be measured in months. The Citrix case shows what it looks like now. A published technical writeup on August 14 turned into live web shells on customer gateways within days. The SAP case shows the harder version, where attackers skip the public research entirely and diff the patch themselves.
The second is time to remediation: how long between a fix becoming available and it being installed on your systems. For most small and mid-sized organizations that number has not moved in a decade. It is still tied to a monthly maintenance window, a change approval meeting, and whoever has time on a Saturday.
When the first clock collapses to days and the second one stays at thirty days, the outcome is not a surprise. It is arithmetic.
The uncomfortable part for leadership
Here is the thing that tends to get lost when this gets discussed as a technical problem. In most of the incidents we see, the delay was not technical. Nobody was struggling to install the update. The patch sat waiting for approval, or waiting for a window, or waiting for someone to confirm the vendor application would still work afterward.
Those are business decisions, not engineering decisions. Which means "we patch monthly" is not really a policy. It is an accepted risk, and now it has a measurable number attached to it. Roughly thirty days of exposure on every internet-facing system you own, in a threat environment where the exploit shows up in three.
That is a decision an owner should make knowingly, not one that gets made by default because the calendar was set up that way in 2019.
What we would change first
You do not need to patch everything faster. That is how patching programs die. You need to stop treating all systems as one queue.
Separate internet-facing from internal. Anything reachable from the public internet, firewalls, VPN gateways, remote access appliances, web servers, email gateways, belongs in its own tier with a 24 to 48 hour target for critical fixes. Everything else can stay on the normal cycle. In most SMB environments this tier is a short list, often under twenty devices, which makes it manageable.
Use the KEV catalog as your trigger. CISA maintains a free public list of vulnerabilities confirmed to be under active exploitation. It is not theoretical scoring. It is a list of things attackers are using right now. A KEV listing on a system you own should start an emergency window, not a ticket.
Pre-authorize the emergency path. Decide now, while nothing is on fire, who can approve an out-of-band patch and under what conditions. If that decision has to be made during an incident, you have already lost the days that mattered.
Know what you actually have exposed. Most organizations we assess are running at least one internet-facing service that nobody on the current team remembers standing up. An old appliance, a forgotten test server, a vendor system installed years ago. You cannot patch what is not on the list.
Where this leaves you
None of the companies named by Cl0p in August lacked a security program. They had the patch available and did not get it installed before someone else got there first. That is the entire story, and it will keep being the story through the rest of this year.
If you are not confident how long it currently takes a critical patch to reach your internet-facing systems, that is the number to go find this week. If it turns out to be thirty days, you now know your exposure window, and you can decide whether that is acceptable.
We are happy to walk through your current patch cycle and exposed asset list with you and give you an honest read on where the gaps are. Reach out and we will set up a time.
Want this reviewed against your environment?
We'll walk your stack with you and tell you plainly what we'd change first.