Every small business that has ever hired a security consultant has received the same artifact: a scan report with several hundred findings, colour coded, sorted by CVSS score, with no indication of which four things to do on Monday. It is technically accurate and practically useless, and the reason is that a severity score describes how bad a bug is if someone exploits it, not whether anyone is going to.

In June the US government formally gave up on that model for its own agencies. The replacement is worth stealing, because it is four questions and you can answer all four without buying anything.

What changed

Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk,” was issued on June 10, 2026. It revokes two things:

  • BOD 19-02, which gave agencies 15 days to fix anything CVSS-critical and 30 days for anything high. That is the “sort by severity score” model.
  • BOD 22-01, which created the Known Exploited Vulnerabilities catalog and required agencies to remediate everything on it by a flat due date.

In their place, BOD 26-04 uses the SSVC method (Stakeholder-Specific Vulnerability Categorization) and asks four yes-or-no questions about each vulnerability:

  1. Is the affected asset publicly exposed? Can something unauthenticated and untrusted reach it from the internet?
  2. Is the vulnerability on the KEV catalog? Is there evidence somebody is actually exploiting it in the wild?
  3. Is exploitation automatable? Can an attacker script every step, from finding targets to landing the payload, with no human judgment in the loop?
  4. What is the technical impact? Does a successful exploit give the attacker partial control of the asset, or total control?

The answers map to a deadline. As practitioners have read the tier table, publicly exposed plus on KEV plus automatable plus total control gets three calendar days and mandatory forensic triage. Other high-risk combinations get 14 days. Internal systems with automatable exploits get 60 days. Everything else gets fixed when the system is next upgraded, which is a polite way of saying it goes in the backlog and that is fine.

Note what is not in that list. Nowhere does an agency sort by CVSS score.

We checked whether it actually changed anything

Directives are one thing. We wanted to know whether CISA’s behaviour changed, so we pulled the machine-readable KEV feed directly and counted the gap between the date each vulnerability was added and the remediation deadline attached to it. Catalog version 2026.08.21, retrieved this morning.

For entries added between January 1 and June 9, 2026, before the directive, there were 133 entries, and the deadlines were spread out:

Days to remediate Entries
2 or 3 days 33
5 days 1
14 days 55
21 days 44

Three quarters of everything, 99 of 133, got two weeks or three.

For entries added on or after June 10, there are 57 entries, and every single one of them cites BOD 26-04 in its required-action text. The spread collapsed:

Days to remediate Entries
3 days 49
14 days 8

86 percent now get three days. Nothing gets 21 days any more. This is not a policy that was announced and quietly shelved; it is visible in the data on every entry added since.

Some context for the volume, from the same feed. The catalog holds 1,674 entries in total. 273 were added in the last twelve months, 72 in the last 90 days, 21 in the last 30. And 352 entries are flagged as having been used in ransomware campaigns, which is a little over one in five.

Twenty-one genuinely exploited vulnerabilities a month, most of them now carrying a three-day clock, is the actual tempo of the problem. It is also completely unmanageable if your triage method is a severity-sorted list, which is exactly why the directive exists.

Why this is the right framework for a small business

The four questions are not federal-specific. They encode a piece of reasoning that scan reports systematically get wrong, which is that exposure and automatability matter more than severity.

A CVSS 9.8 on a database server that only accepts connections from your own application, on a private network, with no public route to it, is a thing to fix eventually. A CVSS 7.5 on the login page of your public website, with a working exploit on GitHub and a botnet already spraying it, is a thing to fix tonight. Severity ranks those the wrong way round. The four questions rank them correctly, and it takes about fifteen seconds per item.

Question three is the one people underrate. “Automatable” is what separates a vulnerability that gets exploited against a few dozen chosen targets from one that gets exploited against every host on the internet within 48 hours. A bug that needs a valid login, a specific unusual configuration, or a human deciding you are worth the effort will almost certainly never be aimed at a nine-person company in Scarborough. A bug that a script can find and exploit in one unauthenticated request absolutely will, because the attacker is not choosing you, they are choosing everyone and you are in the range.

The wp2shell chain in WordPress core is the textbook case, and it is why CISA gave it three days. Publicly exposed, yes, it is a website. On KEV, yes, within four days of the patch. Automatable, yes, one unauthenticated HTTP request to a REST endpoint that exists on every install. Total control, yes, it produces an administrator account and then arbitrary code. All four boxes. That is the profile of a vulnerability that finds you rather than the other way round.

Running the four questions on a real small business stack

Here is the same triage applied to the kit an actual twenty-person Toronto company runs, using the security stories we have covered over the past few weeks.

Your public website. Publicly exposed by definition. Everything else depends on what it is built with, but a CMS with an unauthenticated attack surface answers “yes” to automatable more often than anything else you own. This is your highest-priority asset every single time, and it is the one most likely to be maintained by nobody in particular.

Your VPN or firewall appliance. Publicly exposed, and almost always fully automatable, because it is a network appliance answering unauthenticated requests on port 443. The Cisco ASA flaw we wrote up on August 14 had a three-day CISA deadline for precisely this reason. Perimeter appliances are the second thing to check, always, and they are the ones nobody looks at because they have been working fine for four years.

An on-prem server running SharePoint, or a self-hosted dashboard, or a git runner. The question that decides this is whether it is genuinely internal. If it is reachable from the internet, treat it like the firewall. If it is truly behind a VPN with no public route, it drops to the 60-day tier and you can schedule it like a normal maintenance task. Most small businesses are wrong about which of those two they have, so verify rather than assume. The SharePoint cluster from July hurt the businesses that thought their server was internal and had a public DNS record pointing at it.

Your managed service provider’s tooling. You cannot answer any of the four questions about software you do not run, which is the entire problem with the N-central breach. The substitute is to ask your provider the questions directly and note whether they can answer them.

Staff laptops and phones. Rarely publicly exposed, rarely automatable at scale, usually reached through a person clicking something rather than a scanner finding them. That does not make them safe, it makes them a different problem, one that is solved with multi-factor authentication and email authentication rather than with a patch deadline.

The five-line version you can actually use

Write these down somewhere your IT provider will see them, and apply them to every alert:

  1. Can somebody on the internet reach this thing without logging in?
  2. Is it on CISA’s KEV catalog? The catalog is free, public, and the single best signal available on whether a vulnerability is theoretical or real.
  3. Could a script do the whole attack, or does it need a person who has decided to target us specifically?
  4. If it works, do they get everything, or just a piece?
  5. Four yeses means tonight. Three means this week. Anything internal and not on KEV goes in the queue with everything else, and that is a legitimate answer rather than negligence.

The last line is the point of the whole exercise. Formally deciding not to fix something is what makes the list of things you will fix short enough to actually finish. Every vulnerability programme that treats its backlog as a to-do list ends up with a backlog nobody works, which is strictly worse than a triaged queue of six items that get done.

One caveat worth stating

BOD 26-04 binds US federal civilian agencies. It does not bind a Canadian business, it does not bind a US contractor directly, and the deadlines in it are not your legal obligations. Federal agencies have until December 7, 2026 to be operating fully under the new timelines, with policy updates due earlier in the process.

What it is useful for is the reasoning. When CISA attaches a three-day deadline to something, that is the US government’s threat intelligence apparatus stating that this specific bug is being exploited at scale right now, and it is telling you so for free, in a machine-readable file, before the story reaches the trade press. If you are looking for one input to your security decisions and you have no budget, the KEV catalog is the one to take.

Update, August 25, 2026. We ran the same exercise on the catalog again three days later, this time counting 2026 entries by product rather than by deadline, and the result was not what we expected. The third most-listed product name of the year, behind Windows and CISA’s generic “Multiple Products” bucket, is Langflow, an open-source AI workflow builder with five entries. That is ahead of SharePoint, ahead of Microsoft Office, ahead of every Cisco product. n8n, Ray, MLflow and Metabase are on the same list. It is the clearest worked example we have of the four questions above pointing somewhere nobody’s asset inventory was looking, and it has its own post.

Update, August 28, 2026. Another clean worked example landed three days later. CISA added CVE-2026-60004, a 9.8 remote code execution flaw in the self-hosted Git server Gitea, to the catalog on August 25 with a remediation deadline of August 28. Three days again, and for exactly the reasons the four questions ask about: it is internet-facing, it needs no authentication on a default install, exploit code is public, and it was already being used to drop payloads. The pattern in the data above is holding, and the Gitea case is written up in full.

Update, August 29, 2026. The batch CISA added on August 26 is the best illustration yet of what “risk-based” actually means, because it splits the deadlines inside a single day’s additions. Six vulnerabilities went on the list. Four of them are old: CVE-2015-3246 in Red Hat’s libuser, CVE-2015-5287 in the Automatic Bug Reporting Tool, CVE-2021-23758 in Ajax.NET Professional, and CVE-2022-0995 in the Linux kernel. Two are the ones that matter this week: CVE-2019-1068 in Microsoft SQL Server and CVE-2026-8452 in Citrix NetScaler ADC and Gateway.

The two with the three-day deadline of August 29 are the seven-year-old SQL Server bug and the brand-new NetScaler one. The other four, spanning 2015 to 2022, got September 9, a fortnight out. Age is doing nothing here. Exposure and automatability are doing everything: NetScaler is a perimeter appliance answering unauthenticated requests, and reporting on the campaign describes web shells named x.php and z.php being dropped along with discovery commands, across dozens of exploitation attempts from a dozen attacker IP addresses in under two weeks. The Red Hat and kernel bugs are local privilege escalations that need a foothold first, so they get the longer clock.

If you ever wanted proof that sorting a vulnerability list by CVSS or by publication date is the wrong instinct, this is it. In one batch, on one day, a 2019 bug got three days and a 2022 bug got fourteen.

Update, September 23, 2026. A reminder that “not in the catalog” is a statement about the last day or two, not about the vulnerability. cPanel disclosed a root escalation on September 22 that any logged-in hosting customer can reach, and as of today none of its three CVEs is in KEV. We pulled the catalog to check. What the same pull shows is that the cPanel ecosystem already has four entries this year, one of them flagged for known ransomware campaign use, and that one went from the vendor’s advisory on April 28 to a KEV listing with that flag on April 30. Two days. The four questions above are the right way to evaluate the new one today, precisely because the catalog cannot tell you about it yet. The cPanel root escalation is written up in full.

Update, September 24, 2026: the clearest example yet of the lag, because this one is confirmed. Yesterday’s note was about a vulnerability with no reported exploitation. Today there is one with reported exploitation, and the catalog still does not have it. WordPress shipped an emergency release on September 22 for CVE-2026-87902, an unauthenticated flaw that becomes remote code execution, and Patchstack’s firewall logged the first attempt at 11:49 UTC that day and the first successful arbitrary file write at 15:34 UTC. We pulled the catalog this afternoon, version 2026.09.23, 1,721 entries: CVE-2026-87902 is not in it, and neither is CVE-2026-93485 from five days earlier. The count has not moved since the 2026.09.22 version either. Sharper still, CISA’s own enrichment on the CVE record, timestamped 16:56:15 UTC on September 22, records Exploitation: none and Automatable: no. The first value was written eighty two minutes after the first file write, and a named Nuclei template for the CVE entered circulation the following day. Neither value has been revised. This is not a criticism of the process, which has humans and review in it for good reasons. It is the strongest available argument for the point this article makes: the catalog is a lagging indicator, it is the right tool for deciding what you are behind on, and it is the wrong tool for deciding what is happening today. The full write-up on that flaw is here.

Update, September 25, 2026: day three, and the catalog moved without moving on this. We pulled the feed again today. Catalog version 2026.09.24, released September 24 at 19:00:55 UTC, 1,723 entries. Two were added yesterday: CVE-2026-5430 in WSO2 and CVE-2026-71362 in Adobe Commerce and Magento, both with a three-day deadline of September 27 and both flagged for forensic triage. So the process is working normally and at the usual tempo. CVE-2026-87902 is still not in it, three days after confirmed exploitation, and neither is CVE-2026-93485. The useful reading is not that CISA is slow. It is that the catalog answers a different question than the one you are asking on the day a flaw lands. It answers “what is confirmed exploited and overdue”, which is the right question for a backlog and the wrong one for this morning.

A second example from today, and a cleaner one because it involves no exploitation at all. Next.js shipped an out-of-band release on September 22 for a flaw its own advisory rates 9.5 critical and that chains into remote code execution through a memory-corruption bug in a C library underneath it. Three days on, the identifier it is published under, CVE-2026-94545, has no record in the CVE Program at all: the API returns CVE_RECORD_DNE. Not “no NVD analysis”. No record. The identifier exists on two GitHub advisories and in a dozen vendor write-ups, and the database that is supposed to define it has never heard of it. If your triage process begins by looking a CVE up, this one is invisible to it. We took that chain apart in full here.

Update, September 1, 2026: we re-ran the count, and the headline number moved. Catalog version 2026.08.31. The pre-directive figures above reproduce exactly, which is the point of publishing the method. The post-directive window has grown from 57 entries to 70, and the split is now 55 at three days and 15 at fourteen. That is 79 percent on the three-day clock, not 86. Nothing was revised; the fourteen-day tier simply got more use over the following ten days than the first six weeks suggested it would.

That is worth more than the correction, because the fifteen entries in the fourteen-day tier have a clear shape once you list them. Cisco Catalyst SD-WAN Manager. Microsoft ADFS. The KNX building automation protocol. MLflow. TrueConf Server. JFrog Artifactory. PaperCut NG/MF. Plus the four Red Hat and Linux local privilege escalations from the August 26 batch above.

Almost none of those is a thing a federal agency exposes to the internet. They are management consoles, internal servers and building systems. So the fourteen-day tier is not “less serious”, it is “not normally publicly exposed”, which is the first of the four questions and evidently the one carrying most of the weight in the tiering. Read that way, the deadline attached to a KEV entry is telling you something about the typical deployment of the product, not only about the bug.

Which means the tier is a default you are expected to override. CISA says so in the entry text itself: the required action on the newest additions ends “Stakeholders are responsible for evaluating each asset’s internet exposure and ensuring adherence to BOD 26-04 patching guidelines.” If your JFrog Artifactory or your PaperCut server is reachable from outside, your clock is three days regardless of what the catalog printed, because you have answered question one differently than the average.

The cleanest illustration is a pair we have already written about. On July 21, CISA added two WordPress vulnerabilities on the same day. CVE-2026-63030, the wp2shell chain, got three days. CVE-2026-60137, a SQL injection in the same WordPress core, got fourteen. Same product, same catalog batch, a clock four times longer, decided entirely by how the thing is reached.

The two PaperCut zero-days added on August 31 are the newest fourteen-day entries and the reason we went looking. Both are actively exploited, one is a 9.4, they chain into unauthenticated remote code execution, and there is a working Metasploit module. They still got fourteen days, because a print management server is supposed to be on the inside. Roughly 800 of them are not, which is the subject of its own post.

For completeness, the rest of the catalog as of August 31: 1,687 entries in total, 281 added in the last twelve months, 77 in the last 90 days, 31 in the last 30, and 352 flagged as used in ransomware campaigns. The ransomware count has not moved since August. The monthly tempo has gone up by half.

Update, September 4, 2026: the independent numbers behind the three-day tier. Our analysis above is of CISA’s deadlines. VulnCheck’s State of Exploitation report for the first half of 2026, published July 28, measures the thing those deadlines are responding to, and the two line up better than we expected. VulnCheck tracked 495 vulnerabilities with evidence of exploitation in the period. 23.43 percent showed exploitation on or before the day the CVE was published, which is very close to the share of KEV entries getting the short clock for reasons of speed rather than exposure. The median time from publication to observed exploitation was 80 days, down from 120 in 2025, and roughly 200 CVEs were exploited within 31 days.

Hold those two facts together, because the temptation is to collapse them into one number and you will see other vendors quote a median under five days from different populations. The distribution has two humps. About a quarter of exploited bugs are already in use when you first hear about them, which is what the three-day tier exists for. The rest give you weeks to months, which is what makes the fourteen-day tier defensible and what makes quarterly patching indefensible. The four questions in this post are how you tell which hump a given advisory sits in without waiting for CISA to tell you.

The same report also answers a question we have been asked repeatedly since the frontier AI labs started publishing vulnerability-discovery results: of 1,061 vulnerabilities attributed to AI-assisted discovery, 14 have been confirmed exploited in the wild, roughly matching the overall rate. The discovery volume is up enormously and the exploitation rate has not moved. That, and what it means for how you spend a limited patching budget, is in the post on AI-discovered vulnerabilities.

Update, September 7, 2026: the blind spot in this method, demonstrated live. Everything in this post is keyed off the KEV catalog, and the KEV catalog is keyed off CVE identifiers. That is a dependency, and this week it broke in public.

On September 5, Sansec disclosed StyleSmuggler, an unauthenticated remote code execution chain in Magento Open Source and Adobe Commerce, already exploited in the wild since September 4 and affecting every current version including the latest. As of today Adobe has published no advisory, assigned no CVE, and released no patch.

No CVE means no KEV entry. Run the four questions against it and every answer says emergency: internet-facing, no authentication required, confirmed exploitation, high impact. Run it through any automated process that consumes KEV or CVE feeds, and the store comes back clean. Scanners, insurer questionnaires, managed-service dashboards, all of them will report nothing, because there is nothing to report against.

So the correction to this post is not to the method. The four questions are the right questions and they get StyleSmuggler right immediately. The correction is to the input. KEV is a catalog of vulnerabilities a vendor has agreed to number. Between a researcher publishing and a vendor assigning, your automation has no signal at all, and the only thing that covers that window is somebody reading vendor-independent research directly. For a small business, that means picking the two or three products you actually depend on and following the researchers who specialise in them, rather than waiting for a number to show up in a feed.

We wrote up the Magento case in full, including the indicators and the order of operations.

For completeness, the catalog as of today stands at 1,695 entries, up eight from the 1,687 recorded on August 31: seven added on September 2 (Sangoma Switchvox, Starlette, Kestra, LiteLLM, JFrog Artifactory and two SonicWall SMA1000 flaws) and one on September 4, the actively exploited Chrome V8 type confusion CVE-2026-85046, which carries a September 18 deadline.

Update, September 9, 2026: the clearest worked example of the four questions we have seen, and it arrived in a single batch. We re-pulled the feed at catalog version 2026.09.08. The catalog now holds 1,699 entries, 215 added during 2026, 286 in the last twelve months, 82 in the last 90 days, 37 in the last 30, and 355 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly again, five weeks running. The post-directive window has grown to 82 entries, split 62 at three days and 20 at fourteen, which puts the three-day share at 76 percent. That figure has now moved 86, then 79, then 76 across three counts. The honest read is that our original 86 percent was an artefact of a six-week sample, and the settled ratio is roughly three in four.

The batch itself is the useful part. CISA added four entries on September 8 and gave them two different deadlines:

CVE Product Deadline Days
CVE-2026-75650 Adobe Commerce and Magento September 11 3
CVE-2026-86218 N-able N-central September 11 3
CVE-2026-81963 Microsoft Windows September 22 14
CVE-2026-85880 Microsoft Windows September 22 14

Read that against the four questions and it decodes instantly. The two Microsoft entries are the zero-days from the largest Patch Tuesday in history, and both are local privilege escalations: an attacker needs a foothold on the machine first. Not internet-facing, authentication required, so fourteen days. The Magento and N-central flaws are unauthenticated, internet-facing remote code execution, both CVSS 10.0, both confirmed exploited. Three days.

If you were triaging on severity, the 7.8-rated Windows flaws being exploited on your own staff’s laptops would look less urgent than they are, and the 10.0-rated server flaws would look identical to each other. If you triage on exposure, which is what BOD 26-04 actually asks you to do, CISA’s own deadlines fall out of the four questions without you needing to read CISA’s deadlines. That is the strongest evidence we have found that the method transfers to a business with no security team. We wrote up the Patch Tuesday side of this separately, including why a 964-CVE month resolves to about four actions for most small businesses.

Update, September 10, 2026: it did it again the very next day, and the ratio held. We re-pulled at catalog version 2026.09.09. The catalog holds 1,703 entries, 219 added during 2026, 290 in the last twelve months, 84 in the last 90 days, 38 in the last 30, and 358 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly for the sixth week running. The post-directive window is now 86 entries, split 65 at three days and 21 at fourteen, a three-day share of 75.6 percent. Across four counts the series now reads 86, 79, 76, 76, which is about as settled as this is going to get: roughly three in four.

The September 9 batch is the September 8 batch with different logos on it:

CVE Product Deadline Days
CVE-2026-19490 Citrix NetScaler, authentication bypass September 12 3
CVE-2025-25249 Fortinet FortiOS and others, heap overflow September 12 3
CVE-2026-20079 Cisco Secure Firewall Management Center, authentication bypass September 12 3
CVE-2026-87491 Google Chromium V8, out-of-bounds write September 23 14

Three unauthenticated flaws in appliances that sit at the network edge by definition, three days each, all three additionally flagged for CISA’s forensic triage requirement. One browser flaw that needs the user to visit a crafted page, fourteen days. Same decode, no severity scores required: the three appliances are reachable from the internet without credentials, the browser bug needs a person to do something first. Note also what this batch says about the previous one. A day after the largest Patch Tuesday ever shipped, the newly exploited things were three network edge appliances and a browser, and not one of the 974 Microsoft CVEs. If you spent September 9 triaging Microsoft’s list and ignoring your firewall vendor’s advisory, the four questions would have told you to do the opposite.

Update, September 11, 2026: the third batch in four days, and this one is a router most people forgot they own. We re-pulled at catalog version 2026.09.10. The catalog holds 1,705 entries, 221 added during 2026, 292 in the last twelve months, 86 in the last 90 days, 40 in the last 30, and 359 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly for the seventh week running. The post-directive window is now 88 entries, split 67 at three days and 21 at fourteen, a three-day share of 76.1 percent. The series now reads 86, 79, 76, 76, 76. It has stopped moving.

Both new entries are MikroTik RouterOS, added September 10 with a September 13 deadline:

CVE What it is Deadline Days
CVE-2026-67277 Missing authentication for a critical function. RouterOS accepts bandwidth-test connections before the primary session has authenticated, which can leak kernel buffer contents or crash the device September 13 3
CVE-2026-86060 Argument injection at SSH login. A username beginning with a prohibited character escalates the session to full administrative privileges September 13 3

Run the four questions and both answer the same way. Internet-facing by design, because a router is. No credentials required. Fully automatable, because it is a network service answering unauthenticated requests. Three days, twice.

The background is worth knowing because it is a good example of coordinated disclosure working and then being overtaken. CERT Polska published six RouterOS vulnerabilities on September 5. MikroTik had already shipped fixes on September 3, in RouterOS 6.49.21 and 7.23.4 on the long-term branches and 7.24.2 on stable, and deliberately withheld technical detail to give operators time. Five days later two of the six were confirmed exploited in the wild, chained under the name MikroTrick into unauthenticated administrative control of any RouterOS device with SSH reachable from the internet.

That is the whole argument of this post in one week. The fix existed before the exploitation did. The gap that decides whether you are affected is not discovery, or severity, or whether anyone told you: it is whether somebody applied an update that was sitting there on September 3. And a MikroTik router is precisely the kind of device that gets installed once, works for six years, and never appears on anybody’s patching list, which is what makes it worth a specific look. If you have one, the answer to “is SSH reachable from outside” should be no regardless of version, and that is a five-minute change.

Update, September 12, 2026: the fourth batch in five days, and it is the remote-access tool your IT provider uses to reach your machines. We re-pulled at catalog version 2026.09.11. The catalog holds 1,709 entries, 225 added during 2026, 295 in the last twelve months, 90 in the last 90 days, 44 in the last 30, and 360 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly for the eighth week running. The post-directive window is now 92 entries, split 69 at three days and 23 at fourteen, a three-day share of 75.0 percent. The series reads 86, 79, 76, 76, 76, 75. Three in four, confirmed again.

Four additions on September 11, and once again two deadlines:

CVE Product What it is Deadline Days
CVE-2026-84869 ConnectWise ScreenConnect Improper privilege management and missing authorization. File transfer and execution through an active remote session without authorization or host confirmation September 14 3
CVE-2026-85706 GitLab CE and EE Path traversal in the repository commits API. Unauthenticated arbitrary file read September 14 3
CVE-2026-42016 JFrog Artifactory Incorrect authorization. The token signature and issuer are validated but the token scope is not, leading to privilege escalation September 25 14
CVE-2026-42018 JFrog Artifactory Improper authentication. An internal anonymous-user token can be returned to an unauthenticated caller even when anonymous access is disabled September 25 14

The decode is the same as the previous three batches and it is getting monotonous in a useful way. GitLab is unauthenticated file read on a service that exists to be reachable, so three days. ScreenConnect is a remote-access server that by design accepts connections from the internet and is the thing an attacker most wants, so three days. Both Artifactory flaws require the attacker to already hold or obtain a token against an artifact repository that is usually internal, so fourteen.

The ScreenConnect entry is the one worth stopping on if you are a small business, because you probably do not run it and you are probably exposed to it anyway. ScreenConnect is what a lot of managed service providers and outsourced IT shops use to take control of client machines. In the wording of the CISA entry, the flaw permits file transfer and execution “through an active remote session without authorization or host confirmation,” which means the abuse path runs from a compromised provider straight onto your desktop, without the prompt that is supposed to ask you first. That is the same shape as the N-able N-central breach we covered, and the action item is the same one: this is not your patch to apply, it is your provider’s, and the only thing you can do is ask them today whether they have applied it. A provider who cannot answer that question by Monday is telling you something.

Update, September 14, 2026: both three-day deadlines expire today, and the GitLab entry is the first 10.0 in any of these batches. We re-read the catalog this morning. It is still at version 2026.09.11, so there is nothing new to add to the table, but two details in the September 11 batch are worth pulling out now that the clock has run.

The first is the score. GitLab assigned CVE-2026-85706 a CVSS of 10.0 on the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Across the four batches we have decoded in this post, that is the only perfect ten. NVD’s copy of the record also carries CISA’s own structured assessment, which reads exploitation active, automatable yes, technical impact total. Those three fields are the machine-readable version of the four questions this whole post is about, and when all three come back at their worst value you get the three-day tier without anyone having to argue about it.

The second is the forensicTriage flag, which is set to Yes on the GitLab and ScreenConnect entries and No on both Artifactory ones. That field is easy to skim past and it is the most operationally loaded thing in the record. A Yes is CISA telling agencies that patching alone does not close the item, because there is expected to be evidence of prior compromise worth going to look for. If you are using KEV as a free triage feed, and you should be, read that field as the difference between “install the update” and “install the update, then check the logs.”

We wrote up the GitLab flaw in full, including the packaging detail that decides how bad an arbitrary file read actually is on a default install, in a separate post.

Update, September 15, 2026: the limit of this method, found in the MikroTik entries. Recounted this morning at catalog version 2026.09.14: 1,710 entries, 226 added during 2026. One new entry since the last count, CVE-2026-76461 in Cisco Secure Email Gateway, an unauthenticated SQL injection that CISA describes as allowing an attacker “to execute arbitrary commands with root privileges on the underlying operating system,” added September 14 with a three-day deadline of September 17 and forensicTriage set to Yes. Across every entry added since the directive took effect, the split is now 70 at three days and 23 at fourteen, so the three-day share sits at 75.3 percent. Nine straight weekly counts, same answer.

The more useful thing this week is a failure mode, and it comes out of the two MikroTik entries added on September 10. Those are CVE-2026-67277, a bandwidth-test flaw, and CVE-2026-86060, a privilege escalation. The vulnerability that attackers are actually chaining with 86060 to take over routers is CVE-2026-67276, an SSH authentication bypass, and it is not in the catalog at 2026.09.14. We checked the feed rather than the coverage, several outlets having reported otherwise.

That is not an error in KEV. The catalog records CVEs with exploitation evidence attached to that CVE, which is exactly what it promises. It is a limit of using KEV as your only input: the list names vulnerabilities, and attackers use chains. Read the two MikroTik entries alone and you would reasonably conclude that disabling the bandwidth-test server addresses the exploited flaw, which would leave the half of the chain that does the breaking untouched. The adjustment is small and worth making: when a KEV entry names a product you run, spend two minutes on the vendor’s advisory for that release before you decide what to do, because the fix is usually a version, not a CVE. The full account, including two other things we found in MikroTik’s own release files, is in the MikroTik post.

Update, September 16, 2026: the catalog has not moved, and the second limit of the method. We re-pulled the feed this morning. It is still at catalog version 2026.09.14, released September 14 at 19:00 UTC, still 1,710 entries and still 226 added during 2026, so every count in this post stands unchanged and there is nothing to recount. That itself is worth one line: the useful discipline is pulling the feed, not finding something new in it.

The thing worth adding is a second failure mode, and it points the opposite way from yesterday’s. The MikroTik case was a CVE missing from the catalog because the evidence was attached to its partner in a chain. This one is a CVE missing from the catalog while being attacked at industrial volume.

F5 Labs published telemetry on September 11 covering a scanning campaign against Vite development servers, the build tool underneath most modern website projects. The numbers are documented: over 32,000 file-read attempts in August alone, against a three-month baseline of 1,732, using CVE-2026-39364 to pull .env files and cloud credentials off any dev server that answered. None of the four 2026 Vite CVEs are in the catalog at 2026.09.14.

Again, not an error. KEV is a federal remediation instrument built around evidence CISA can stand behind, and BOD 26-04 applies to federal agencies, who do not typically have thousands of exposed Vite dev servers. But it does sharpen the caveat for anyone borrowing the method: the catalog is shaped by what is exploited against the federal enterprise, and a small business is not that. What it does contain, and this is the tell, is the 2025 version of exactly the same bug, CVE-2025-31125, added January 22, 2026, described by CISA as exposing “content of non-allowed files using ?inline&import or ?raw?import.” The same bug class, one year late.

Two of the 226 entries added this year are developer tooling rather than servers or appliances: that Vite entry, and CVE-2025-11953, an OS command injection in the React Native Community CLI’s development server, added February 5. If your business builds software, or pays somebody who does, the four questions are worth running against the laptops and build machines as well as the servers, and the answer to “is it reachable from a network we do not control” is more often yes than anybody expects. We wrote up that campaign and what we found testing it.

Update, September 18, 2026: a tenth weekly count, and the rarest weakness class in the catalog. Recounted this morning at catalog version 2026.09.16, released September 16 at 18:47 UTC. The catalog holds 1,713 entries, 229 added during 2026, 299 in the last twelve months, 90 in the last 90 days, 43 in the last 30, and 360 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly for the tenth week running. The post-directive window is now 96 entries, split 73 at three days and 23 at fourteen, a three-day share of 76.0 percent. The series reads 86, 79, 76, 76, 76, 75, 75.3, 76.0. It has not moved in two months.

The September 16 batch is three entries and every one of them is on the three-day clock with forensicTriage set to Yes: a Google Pixel flaw, a Cisco Identity Services Engine authentication bypass, and CVE-2026-87886 in the Acronis Backup plugin for hosting control panels. That last one is the interesting entry, and it is interesting for a reason the four questions do not ask about.

It is a local privilege escalation, AV:L and PR:L, and CISA’s own structured assessment marks it Automatable: no. Run the four questions against it honestly and it scores badly: not publicly exposed in the usual sense, not automatable, so not urgent. CISA gave it three days anyway. The reason is that the machine it runs on is shared hosting, where “an attacker with a low-privileged local account” is not a precondition an attacker has to engineer. It is what every tenant on the box already has, and what any compromised website on that box hands over for free. The adjustment worth making to question one, “is it reachable from a network we do not control”: on multi-tenant infrastructure, the answer is yes even when the software only listens on localhost, because the other tenants are the network.

Two more counts from the same pull, both about how unusual this entry is. CWE-276, Incorrect Default Permissions, appears on exactly five of the 1,713 entries in the catalog’s entire history, and three of those five are hosting control panel software. And only nine entries ever have named a backup product; the previous eight are all network-reachable enterprise backup servers. The full write-up, including the affected control panel that CISA’s entry does not name and whose fix is still not downloadable, is in the Acronis backup plugin post.

Update, September 19, 2026: an eleventh weekly count, and the batch that makes the case for the fourth question. Recounted this morning at catalog version 2026.09.18, released September 18 at 19:00 UTC. The catalog holds 1,716 entries, 232 added during 2026, 302 in the last twelve months, 93 in the last 90 days, 45 in the last 30, and 360 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly for the eleventh week running. The post-directive window is now 99 entries, split 76 at three days and 23 at fourteen, a three-day share of 76.8 percent. The series reads 86, 79, 76, 76, 76, 75, 75.3, 76.0, 76.8. Nine weeks inside a point and a half.

The September 18 batch is three entries and all three are the Linux kernel, on the three-day clock, with forensicTriage set to Yes. That is only the second time in the catalog’s history that three kernel entries have landed on the same date; the other was September 15, 2022. It also puts the Linux kernel at eight entries for 2026, second only to Microsoft Windows at thirteen when you count by product.

Run the four questions against these three and you get an answer the CVSS scores do not give you. CISA’s own structured assessment marks exactly one of the three Automatable: yes, CVE-2025-39682 in the kernel TLS receive path, and it is the only one of the three with a network attack vector in the CNA’s own scoring. The other two are local, need a foothold first, and are marked not automatable. Same product, same day, same deadline, three quite different amounts of urgency, and the catalog’s uniform three-day clock tells you none of it.

That is the limit of reading deadlines instead of vectors, and it cuts the other way too. The kernel entry that is hardest to act on is not the automatable one. It is CVE-2026-53266, the ebtables flaw, because Ubuntu has not published a fixed kernel for 24.04 LTS or 22.04 LTS, so the three-day deadline lands on machines with nothing to install. Question four in this framework is “can we actually do the remediation,” and it is the question people skip because the answer is usually yes. We pulled the package archives to check: the full write-up is here.

Update, September 28, 2026: a twelfth count, and the three-day share has finally moved. Recounted this morning at catalog version 2026.09.27, released September 27 at 21:30:35 UTC. The catalog holds 1,728 entries, 244 added during 2026, 311 in the last twelve months, 98 in the last 90 days, 43 in the last 30, and 361 flagged as used in ransomware campaigns. The pre-directive count of 133 reproduces exactly for the twelfth week running. The post-directive window is now 111 entries, split 88 at three days and 23 at fourteen, a three-day share of 79.3 percent. The series reads 86, 79, 76, 76, 76, 75, 75.3, 76.0, 76.8, 79.3. After two months flat inside a point and a half, it has jumped two and a half points in nine days, and the fourteen-day tier has not taken a single new entry since September 11, its last two being a pair of JFrog Artifactory flaws. Every one of the 19 entries added since is on the three-day clock.

The reason is visible in what September consisted of. Forty one entries went on the catalogue this month, more than any other month of 2026, and seventeen of them are perimeter network devices: firewalls, VPN and remote access gateways, application delivery controllers, SD-WAN controllers, routers, switches and mail gateways, from nine different vendors. That is 41 per cent of the month. Run the same classification over the whole catalogue and the share rises every year: 12 per cent in 2021, 15 in 2022, 16 in 2023, 18 in 2024, 18 in 2025, and 23 per cent in 2026 so far. A perimeter appliance answers question one, publicly exposed, with a yes by definition, so a month weighted towards them is a month weighted towards the three-day tier. The ratio did not change. The mix did.

The month closed with the cleanest example of all four questions answered yes at once. On September 27, a Sunday, Citrix published eight NetScaler flaws and CISA added two of them, CVE-2026-88771 and CVE-2026-88772, with a deadline of September 30 and forensic triage required. CISA’s own structured assessment on both reads exploitation active, automatable no, technical impact total, and the first of the two works against every deployment in its default configuration with no feature enabled. The full write-up is here, including the finding that the 9.5 everyone is quoting for that one is half a point low because a CVSS metric is set backwards against the vendor’s own preconditions table. Which is the argument of this whole post in one worked example: the deadline told you more than the score did.

If you would like someone to run these four questions against your actual setup once and write down the answers, that is a conversation worth having. It is usually a short list and it is usually not the things people expect.

Sources