By the time CISA flagged LoadMaster, the patch had been out for 64 days

On 7 August, CISA added CVE-2026-8037 to its Known Exploited Vulnerabilities catalog and set a deadline: 10 August. Three days. That sounds like maximum urgency, and it is. But the Progress patch had been out since 4 June. Sixty-four days. If your patching process fires when a vulnerability lands in the KEV, you have just discovered you have been two months late without knowing it.

The affected box is a Progress Kemp LoadMaster, a load balancer. Which is to say: the appliance sitting in front of your applications, the one terminating TLS, the one that sees all your traffic before anyone else does, and the one that almost never shows up in the patching inventory because "it's network kit". This post is less about LoadMaster than about the criteria you use to decide what gets patched first. It is simply the case that illustrates it best this month.

The four clocks

Every vulnerability like this one has four dates, and hardly anyone tells them apart:

The clock that matters is the second one. Between the bulletin and the public PoC you have a window in which you are the only one who knows where the flaw is; from the PoC onward, anyone motivated can reproduce it. Twenty-five days is a generous window, and it is still easy to burn the whole thing waiting for next month's maintenance slot.

What actually breaks

NVD describes it as OS command injection in the API of Progress ADC products, exploitable without authentication, through unsanitized input in multiple command endpoints. It is classified as CWE-77. Translated: someone who can reach the API can run commands on the appliance.

The interesting detail came from watchTowr opening the binary: the flaw sits in escape_quotes(), the function whose entire job is to prevent this kind of injection. It allocates a buffer with malloc() —uninitialized memory— and never writes the null terminator at the end of the escaped string. The result is an out-of-bounds read that runs into adjacent freed heap chunks, where the attacker has already placed their own data. The entry point is /accessv2, and the patch simply swaps that malloc() for calloc() and terminates the string properly.

The 9.6 and the 9.8 are not measuring the same thing

There is a detail here that deserves more attention than it gets. The NVD entry carries two CVSS 3.1 scores for the same flaw:

Two tenths apart — and yet the vectors disagree on two separate axes. Progress says AV:A: adjacent network, meaning it assumes nobody reaches your balancer's management API from the Internet. NVD says AV:N: network, it is reachable, full stop. Meanwhile Progress marks S:C (the flaw escapes the compromised component) and NVD marks S:U. That the two numbers land almost on top of each other is arithmetic coincidence: two substantive disagreements cancelling out.

The practical consequence is the one that matters: the only person who can settle that disagreement is you, because it depends on whether that API faces the Internet in your installation. A CVSS measures risk assuming an architecture, and the one it assumes is rarely yours. Sorting a list of vulnerabilities without the inventory of what is exposed means sorting by a number that says nothing about your installation. Knowing what you have and how it is reached takes up half the work of a technical and process audit.

792 attempts, 65 IPs, 18 countries

The telemetry circulating alongside the KEV entry, attributed to KEVIntel and reported by The Hacker News, describes 792 exploitation attempts over 41 days from 65 unique IP addresses across 18 countries, with the latest activity logged on 4 August. Counting 41 days back from the advisory lands on 27 June: the window opens in the same week the proof of concept went public, give or take a couple of days depending on where you close the counter. And eSentire, which saw its first attempts on the 29th, arrives at the same date from a different direction.

It is worth being honest about what that number does not say. 792 attempts over forty days is opportunistic scanning, a long way from an organized campaign. eSentire was literal in its advisory: "In cases observed by eSentire, exploitation was not successful, and as such, no post-compromise activity was observed." And the KEV entry itself lists known ransomware campaign use as "Unknown". None of which is an invitation to relax. Opportunistic scanning of a flaw with a public exploit is the pattern that precedes the serious stuff; ransomware operators buy access from whoever already swept the Internet on their behalf.

The KEV is late by design, and that is fine

To be clear: this is not a criticism of CISA. The catalog does exactly what it promises —list vulnerabilities with confirmed evidence of exploitation— and confirming takes time. The 10 August version of the catalog holds 1,662 entries; it is one of the best free tools available for narrowing the universe of CVEs down to what is actually being used.

The failure is in using it as an alarm clock. The KEV is an acknowledgement of receipt, not an alarm: it confirms something has already been going on for a while. If it is your only input signal, your process inherits the whole of its latency — and then lands on your desk with one working day to act on it. Around July's Patch Tuesday and its 622 patches we already said there is no shortage of information; what is scarce is an order of your own for reading it.

How we order the queue

We order the queue with four questions. If all four answers are "yes", that gets patched outside the window, today, and whoever needs to know gets told:

CVE-2026-8037 answered "yes" to all four on 29 June. You did not need to wait until 7 August to know that, and you did not need any paid tooling: you needed an inventory that said "we have two LoadMasters and their management API lives here".

If you were exposed for forty days, patching is not finishing

There is a nuance in CISA's own instruction that tends to get skimmed and says a great deal. Alongside the order to apply the vendor mitigations, the entry points to two things in parallel: the guidance in directive BOD 26-04, "Prioritizing Security Updates Based on Risk", and CISA's Forensics Triage Requirements. Translated: update, and then go and check whether they had already got in.

We already made that argument at length with FortiOS and the symlinks that survived the upgrade, so we will not repeat it here: patching is not cleaning. What is worth adding is the uncomfortable detail specific to this case. An appliance that spent forty days with a public exploit pointed at it does not get signed off by bumping the version and closing the ticket — and yet a load balancer rarely keeps the logs you would need to answer the only question that matters. If you cannot reconstruct what happened on /accessv2 since 29 June, that gap is your first finding.

The short version

The KEV is an excellent catalog and a terrible starting gun. By the time CISA warns you, the vendor has had the patch out for weeks or months and the exploit has been circulating for a while. The clock that orders your queue properly is the day the public PoC appears, crossed against the inventory that tells you whether it applies to you. The first one the researchers hand you for free. The second you have to have built beforehand, because on the day of the warning there is no longer time to build it.

Sources (verified): CVE entry, description and both CVSS 3.1 scores — NVD; date added (7 Aug 2026), due date (10 Aug 2026), required action and the BOD 26-04 reference — CISA KEV catalog, version 2026.08.10; technical analysis, escape_quotes(), /accessv2, versions and PoC (29 Jun 2026) — watchTowr Labs; vendor bulletin and fixed versions — Progress; advisory and the literal quote on unsuccessful exploitation (30 Jun 2026) — eSentire; telemetry of 792 attempts attributed to KEVIntel — The Hacker News. Cover image: "Racks Amravati Data Center", PiDatacenters, CC BY-SA 4.0, via Wikimedia Commons.