Why Wait for the KEV?

# Why Wait for the KEV? 792. That is the number of reported exploit attempts targeting the Progress Kemp LoadMaster command injection flaw (CVE-2026-8037) before it officially landed in CISA's Known Exploited Vulnerabilities catalog. It isn't a massive number in the context of global botnets, but it's a precise one. In my experience, when you see a specific count like that, it means someone (likely a vendor or a dedicated telemetry team) was watching the logs in real-time while the rest of the world was waiting for a PDF advisory to tell them they were in trouble. The timeline here is a textbook example of why relying on official government catalogs for your patching cadence is a great way to get compromised. CISA added CVE-2026-8037 to the KEV on August 7th. They set the federal patch deadline for August 10th. That gives the most disciplined agencies in the world exactly three days to move from "unaware" to "remediated." For everyone else, those three days are a luxury they don't have. Attackers don't check the CISA website for permission before they launch a payload. The flaw is a command injection vulnerability. For the uninitiated, that's essentially giving an attacker a direct line to the underlying operating system of the device managing your traffic. When you compromise a load balancer, you aren't just hitting one server; you're standing at the front door of every application that device services. This is where we find the second-order effect. The immediate victim is the LoadMaster instance. The actual casualty, however, is the downstream infrastructure: the internal web servers and databases that trust the load balancer's traffic. Once an attacker has a shell on the LB, they aren't looking at the device's logs; they're using it as a pivot point to move laterally into the core of the network without ever having to trip a firewall rule. Some will argue that CISA's 72-hour window is a necessary pressure valve to force federal agencies to act. I disagree. A deadline set after 792 attempts have already been logged isn't a proactive security measure; it's an autopsy report with a due date. We saw the same pattern this week with N-able. CVE-2026-18577 and CVE-2026-18556 were added to the KEV on August 3rd and 4th, respectively. The deadlines followed within days. By the time the federal government says a vulnerability is "known," it's already been common knowledge in the telemetry of every major security firm for a week. We're seeing this rhythm repeat across the board, from JetBrains TeamCity (CVE-2026-63077) to Apache Tomcat (CVE-2026-34486). The noise is deafening. There were 399 stories about data breaches this week alone. It's easy to get lost in the headlines about millions of records leaking, like the 3.8 million healthcare patients exposed in the Unlimited Technology Systems breach, and forget that those leaks usually start with a single, unpatched command injection on a piece of edge infrastructure. The parallel here is old and tired. It's the same lag we saw during the early days of the Ivanti exploits, where the gap between "exploit in the wild" and "official mandate to patch" was wide enough to drive a ransomware gang through. The only difference now is that the window is shrinking, and the attackers are getting faster at scanning for those specific version numbers. If you're waiting for a KEV entry to trigger your emergency change window, you've already lost. You aren't managing a vulnerability; you're managing a countdown. I suspect we'll see more "surprises" from the Progress LoadMaster flaw in the coming weeks. The real question is how many organizations think they're safe because their dashboard hasn't turned red yet, while the attackers are already using their load balancer to map out their internal subnet.