Zero of 1,748: every deadline in CISA’s KEV catalog has now expired!

One thousand four hundred and thirteen vulnerabilities moved this week-the largest number Microsoft has ever patched in a single month, surpassing its total for all of 2025. But the number that should actually shape your Monday is zero.

The clock: seven days to Oct 19

• 9: Added to CISA KEV in seven days
• 7: Of those already past deadline
• 0: Deadlines with clock left in all 1,748

This week's deadlines landed in quick succession: two on October 16, four on October 17, one on October 18, and two more today. After today, there are no more deadlines left to meet. Seven are already past due, two are due now, and for the first time, there are zero with time remaining.

Remediation window minus median days between date Added due Date 2026: January 21, February 21, March 14, April 14, May 14, June 3, July 3, August 3, September 3, October 3. BOD 26–04 takes force between May and June. One series, one measure, across all 1,748 entries grouped by the month each was added. The median has sat at 3 since June, but October is the first month in which it is also the only value: 18 of 18 additions, with no 14-day tier assigned at all. See Governance Corner.

This morning, not a single entry in the Known Exploited Vulnerabilities catalog has time left on the clock. That's not zero out of nine; it's zero out of 1,748. Every vulnerability CISA has ever marked as exploited is now either past its federal deadline or comes due tonight.

This is less a feat than simple arithmetic. The catalog dropped Friday afternoon, the remediation window is three days, and the weekend took up the entire clock. For most of us, by the time we check on Monday, there's no live deadline left to act on. That's not a flaw in the catalog; it's a shift in its purpose.

KEV was once a queue: you tracked due dates, planned your work, and reported progress. Now, with a three-day window, it functions more like a receipt. By the time you review it on Monday, it simply records whether you met the deadline on your own or missed it without realizing. Sorting remediation by due date no longer gives you a useful order-it sorts by nothing at all.

So the real lesson this week isn't the 1,413 vulnerabilities. It's a line from Volexity's Ivanti investigation: the compromised appliance was fully patched. Patch speed wasn't the deciding factor. On the Cisco email gateway, the fix had shipped a month earlier, but under a different CVE. On BeyondTrust, the attacker had been present since late August and erased the logs before leaving. In each case, the critical question wasn't how quickly you patched, but whether you could still reconstruct what happened. And in each, the appliance was left unable to answer. If deadlines no longer drive your planning, you need a new instrument.

Sources: SecurityWeek · Dark Reading on the Ivanti chain · CISA KEV catalog

What happened. CVE-2026–102764 is an authentication bypass in BeyondTrust Remote Support, CVSS 9.3, caused by an internal messaging component failing to validate where messages came from. It affects every Remote Support release up to and including 26.2.3. Mandiant and Google Threat Intelligence Group attribute the exploitation to Armory Castle, formerly UNC5221, tracked by CrowdStrike as Warp Panda, a China-nexus espionage group that has used it as a zero-day since August 29. The chain is fast and tidy: the SAWFLY PHP webshell landed roughly eleven minutes after the flaw was weaponized, then root via SUID, the BARECLAW SOCKS5 tunneller, a search of the appliance's secrets database, an administrator credential dump, deletion of system, web server, and application logs, and lateral movement using the stolen accounts. BeyondTrust identified the defect on September 28, had a patch by the 30th, and released it on October 8 as BT26–05-RS. CISA added it to KEV on October 16, set the forensic triage flag, and set a federal deadline of today.

Why does this matter? Remote Support is the system that holds privileged access to everything else you manage. If it's compromised, attackers don't need to exploit anything downstream-they simply log in. BeyondTrust reports over 20,000 customers, including 75 of the Fortune 100, and Shadowserver found more than 1,400 Remote Support instances exposed to the internet. That's exposure, not confirmed victims, and it's an important distinction. GTIG reports only a small number of known affected organizations, but with this attacker's dwell times, that means known, not necessarily few. And the attacker's last move? Deleting the logs. The appliance was intentionally left unable to answer the very question the deadline is supposed to address.

What to do this week: Before the end of today, make a clear inventory of every Remote Support and Privileged Remote Access appliance you operate, including self-hosted systems, and note their versions. Any system at or below 26.2.3 needs BT26–05-RS; anything below 24.3.1 must be upgraded to that version first, then patched. But don't stop at patching. Since on-device logs may be gone, look for evidence elsewhere: NetFlow or firewall records for outbound traffic from these appliances since August 29. Focus on long-lived sessions, or SOCKS5-like flows to unfamiliar addresses. Rotate every credential stored in the appliance and every administrator account used through it. Finally, document the date you checked, what you reviewed, and what you found, even if the answer is, 'could not determine, retention insufficient.' That record is your deliverable, not just a closed patch ticket.

Sources: SecurityWeek · Dark Reading · BleepingComputer · CyberScoop · BeyondTrust advisory BT26–05, via the KEV entry

What happened. CVE-2026–76519 is an unauthenticated arbitrary file write in Cisco Secure Email Gateway, CVSS 9.8, in the way the Advanced Malware Protection feature handles email attachments. An attacker emails a crafted attachment through the gateway and can run commands as root on it. Two conditions must both hold: File Reputation must be enabled and assigned to a mail policy, and Content Scanner Tools must be older than 25.3.0.5525. Here is the detail that matters more than the score. The fixed AsyncOS builds, 15.5.5–014 and 16.5.0–780, shipped on September 14 under a different CVE, CVE-2026–76440 Cisco updated that same advisory on October 14 to record active exploitation and issued the new identifier. There is no workaround, and AsyncOS 16.0 has no fixed build, so migration is the only route. CISA added it on October 14 with a deadline of Friday, which has just passed.

Why does this matter? This is the kind of failure that trips up careful teams, not careless ones. If you applied the September advisory and closed the ticket, you might see a new critical Cisco email gateway CVE and assume you're protected, since your build matches the fixed version. But the real exposure depends on the Content Scanner Tools version, which updates separately and doesn't require an upgrade or restart. Saying 'we applied the September advisory' is not the same as confirming 'we are not vulnerable.' Only the latter is a real check. And losing control of an email gateway is serious-it sits inside the trust boundary for every message your organization receives, and Cisco warns that an attacker with root access could erase any trace of their presence.

What to do this week: Don't just check the AsyncOS version. Check the Content Scanner Tools version and make sure it's 25.3.0.5525 or later. Since this installs independently, there's no change window to wait for; do it now. Then run Cisco's compromise check as recommended. grep "System Security" system_logs Treat a clean result as unproven, not proof of safety; follow Cisco's guidance, not just mine. Cross-check with external firewall and network logs. If you suspect a virtual appliance, preserve forensic data, deploy a new VM on a fixed release, and rebuild the configuration manually instead of importing the old file. Since cluster members authenticate with SSH keys, a single compromised member means you'll need to restore every member in the cluster. Plan for that now, not after the fact.

Sources: SecurityWeek · The Hacker News · Cisco advisory, via the KEV entry · SANS NewsBites 28.77 for the Murray commentary, quoted as plain text because NewsBites links are click-tracked and useless to a reader.

What happened. From around October 13, attackers used the application identities of ConnectWise's Cloud Backup service, the product formerly sold as SkyKick Cloud Backup, to reach customer Microsoft 365 tenants. The attacker signed in directly as the backup application using its own secret, so multi-factor authentication never came into play. Microsoft classified it as an active supply-chain attack and assessed that the attacker likely abused the Directory.ReadWrite.All permission. ConnectWise cut customer access at 05:01 UTC on October 17 and disabled seven application identities; by its October 18 update, scheduled backups were not running and restore was unavailable. Huntress identified at least 162 compromised tenants and observed service principals granting themselves directory roles, mostly Exchange Administrator. Indicators are a source address of 144.172.64.128 and an application ID 506e08f9–6e9a-4da4–942b-a099a03644ae. No CVE exists. No KEV entry exists, because there is nothing to put in one.

Why does this matter? Compared to items 01 and 02, this incident shows the limits of deadline-driven security. It likely had the widest impact of the week, yet it didn't involve a vulnerability or trigger any remediation clock. The permission was granted correctly during onboarding, probably years ago, by someone following the process. There was no misconfiguration. The consent and token were both valid, and multi-factor authentication doesn't apply to service principals; they aren't people and have no second factor. If your vulnerability management is organized by due dates, this kind of event won't even register.

What to do this week: List every third-party service principal in your Entra ID tenant, and identify those with application permissions of the following types: Directory.ReadWrite.All, Mail.ReadWrite or Files.Read.All class, application, not delegated, because those work with no user present and no sign-in prompt. Put a vendor name and a business reason beside each; any you cannot name is itself the finding. Then query sign-in logs for the application ID 506e08f9–6e9a-4da4–942b-a099a03644ae and for 144.172.64.128 from October 13 onward. Review every directory role assignment granted to a service principal in the past two weeks. Rotate client secrets for backup and managed-service integrations. There's no deadline for this one-so you'll need to remind yourself.

Sources: BleepingComputer · This item rests on a single outlet. The victim count of 162 is Huntress's, reported by BleepingComputer; a separate Hacker News headline puts it at 173, and the discrepancy is unresolved.

On Sunday, SecurityWeek published Kevin Townsend's read of CyberSN's latest Cybersecurity Jobs Report, and the headline figure will circulate: US cybersecurity job postings fell 26.4% year on year, to 235,786 between January and September, down from 320,210 in the same months of 2025, described as a four-year low. Two roles ran hard the other way: AI Security Engineer up 268.3%, Cyber Data Scientist up 203.5%.

Now read the declines against the rest of this edition. Cyber Insider Threat Analyst down 55.6%. Cyber Risk Analyst down 51.5%. Penetration Tester down 45.9%. Cybersecurity Lead down 41.0%. Threat Hunter down 40.0%.

These roles are responsible for forensic triage. BOD 26–04 didn't call for faster patching; it required teams to determine, within three days, whether affected systems had already been compromised. That's investigative work something you can't automate or reduce to a dashboard, because it requires human judgment and accountability. This week, three appliances had their own logs deleted or made unreliable, which is exactly when a skilled analyst proves their value and automated tools come up empty.

I want to be careful with this data rather than wave it around. It is one vendor's report built on one job-listing feed, uncorroborated elsewhere this week, and Townsend is explicit that it describes what is happening and not why. Postings are not hires. A 26% fall could be budget, consolidation, or employers quietly recruiting through networks instead of advertising.

Still, the trend is clear, and it points to a gap. The capability BOD 26–04 demands isn't being hired for directly. If you're building a team, the most valuable requisition may be the one nobody is writing: someone who owns vulnerability operations and triage-the inventory, the deadlines, and the answers. And if you're looking to enter the field, this is the least crowded path. The work is new enough that nobody has a decade of experience, and three days of well-documented evidence gathering is a portfolio in itself.

Sources: SecurityWeek on the CyberSN Cybersecurity Jobs Report · Single vendor, single outlet; no corroborating hiring, salary or layoff data published this week.

BOD 26–04, Prioritizing Security Updates Based on Risk, is built as a tiered instrument. It uses four criteria: publicly exposed asset, fully automated exploitation, attacker takeover, and evidence of active exploitation, and timelines that scale with how many a vulnerability meets. Three days at the top, fourteen or sixty beneath it, with forensic triage attached to the top tier.

Here is what the catalog actually shows. Of the eighteen entries CISA added in October 2026, all eighteen carry a three-day window. Not one fourteen-day deadline was assigned this month, the first time that has been true since the directive took force. And the assignment is not obviously tracking the criteria: CISA's own Vulnrichment data scores this week's Microsoft, Palo Alto and Fortinet entries Automatable = no, and one of the two Ahsay entries Technical Impact = partialyet each of them got three days. CISA also retired its weekly vulnerability bulletin at the end of September and tied that change explicitly to this directive, so the volume view went away in the same quarter the prioritization view flattened.

Document two things this week. First, there are two things to document this week. First, your remediation policy can't rely on tiered timelines anymore; there's effectively only one clock, and it's three days. Any policy that promises a fourteen-day track for lower-risk KEV entries is now out of step with reality. Second, and this is what auditors will care about in December when the 180-day mark arrives, list the asset classes where you can actually perform forensic triage, and those where you cannot. That honest assessment is far more valuable than a patch-compliance percentage, and this week gave you three clear examples to start with. This week on the bulletin retirement · BOD 26–04 · The directive was issued in June 2026 and the bulletin retirement in September; neither is a this-week development. The October tier counts are computed from the catalog for this edition and are not reported by any outlet.

No sponsors. Never any sponsors. Everything here is free, and most of it is already on your machine.

The directive's four criteria read like something only CISA can evaluate on your behalf. Three of the four are published, machine-readable, and free. CISA's Vulnrichment program adds SSVC decision points to CVE records through its Authorized Data Publisher container, Exploitation, Automatable and Technical Impact and those are three of the four criteria, sitting in a JSON file you can read in one command. The fourth, whether the asset is publicly exposed, is the one only you can answer. That division of labor is the entire lesson of this edition in one data structure.

Step 1: Read one record. Records live at /xxx/.json, where the bucket is the CVE number with its last three digits stripped. So CVE-2026–102764 sits under 2026/102xxx/:

That returns Exploitation: active, Automatable: yes, Technical Impact: total — all three top-tier criteria met, which is why today's BeyondTrust deadline is three days and carries forensic triage.

Step 2: Make it a function you will actually use. Paste this into your shell. It handles the bucket arithmetic and, importantly, does not fall over when there is no data:

Run it against the CVEs in your own backlog. You will find things worth arguing about: this week's Palo Alto, Fortinet and Microsoft entries all come back Automatable=no, which is a legitimate basis for putting them second in a queue, and a much better one than a CVSS score.

Step 3: Measure the coverage, because that is the real finding. Loop it over this week's nine KEV additions. Eight return data. One does not: CVE-2026–21589The Atlassian file-access flaw has no CISA container in its record at all — only Atlassian's own. A vulnerability carrying a three-day federal deadline, with none of the three decision points the deadline is supposed to be derived from. That is not trivia. It is exactly the objection David Lindner of Contrast Security raised when the directive landed in June: the framework depends on exploit and impact metadata that is not yet accurate, current, or comprehensive enough. Ten minutes with curl turns that from an opinion into a measurement you can put in a risk register.

Why does this matter? For practitioners, this approach replaces subjective severity debates with a published decision. Saying 'this is a 9.8' invites argument; saying 'CISA scored this Automatable=no and Technical Impact=total' settles it, and you can check it in seconds.

For governance, risk, and compliance teams, this is rare: an externally published, timestamped, and independently verifiable basis for prioritization. 'We deferred this because CISA's Vulnrichment record scored it Automatable=no, timestamped 14 October' is a sentence you can audit. A CVSS score copied from a vendor bulletin isn't, because it doesn't show when or what you actually reviewed.

If you're entering the field, a simple script that computes BOD 26–04 tiers and reports metadata coverage for current KEV additions is a stronger interview artifact than any certification line on your resume. It shows you can interpret government data standards, understand SSVC and its purpose, and, most importantly, verify the data before relying on it. That last point is the difference between someone who has read a directive and someone who has actually tested it.

Sources: CISA Vulnrichment repository · Vulnrichment documentation · Dark Reading for the Lindner criticism

• Oct 19: today. KEV deadlines for Fortinet CVE-2025–61624 and BeyondTrust CVE-2026–102764, the last two live clocks in the catalog. Behind them, nothing.
• Oct 21: SANS webinar: 2026 Cloud Security Survey insights.
• Nov 10: Microsoft Patch Tuesday, the first test of whether 1,413 was a peak or a baseline.
• Nov 10: SANS webinar: 2026 State of ICS/OT Security Survey insights.
• Dec 7: BOD 26–04 180-day mark: federal civilian agencies must meet the directive's remediation timelines, not merely plan to.
• H1 2027: Proofpoint's $6.3bn acquisition of Varonis expected to close, subject to shareholder and regulatory approval.
• Oct 2027: Free Windows 10 security updates end, after a two-year extension. October 2026 was already the final update for Windows 11 24H2 Home and Pro.

When was the last time you proved-rather than assumed-that an internet-facing appliance in your environment hadn't already been compromised?

If your answer is 'at install' or 'we've never had reason to,' you're not alone, and that's the real finding. The forensic triage requirement in BOD 26–04 isn't just a new burden; it's the first time anyone has formally required a capability that most security programs were never funded to build, and then put a seventy-two-hour clock on it. This week, three exploited appliances-a remote-support gateway, an email gateway, and a VPN, were all reported to have had their own evidence deleted or made unreliable, and the VPN was fully patched when it was compromised. The honest answer leads to a practical step: the control worth funding this quarter isn't another scanner, but off-device log retention for the critical systems at your edge. That way, when this question comes up again, you'll have evidence from a place the attacker couldn't reach.

Computed from the CISA Known Exploited Vulnerabilities catalog, version 2026.10.16, released Oct 16 17:15 UTC and pulled Oct 19, 2026, 1,748 entries, 264 added this year, 1,746 past due and 2 due today, with 87 carrying the BOD 26–04 forensic triage flag. All nine additions above received a three-day window; eight of the nine have SSVC decision points in Vulnrichment, and Atlassian's has none. None of the nine is flagged for known ransomware campaign use, which means unexamined rather than safe. Notably absent, and therefore carrying no federal deadline at all: the ConnectWise Cloud Backup compromise, where no CVE exists because the attacker used a permission that had been granted to it; the Broadcom WPS message-reassembly flaw that lets anyone in radio range run code as root on millions of cable gateways, for which Broadcom declined to register a CVE and CERT/CC closed the case the same day; Microsoft's CVE-2026–70242 (Outlook reading-pane RCE, CVSS 9.8, no user interaction required) and CVE-2026–105016 (QUIC, 9.8), neither exploited; and the European supermarket refrigeration compromises, which CERT-FR has not tied to any vulnerability. KEV is a floor, not a ceiling.

Researched and produced by Devore J. McIntosh · CyberDev

The Friday Cyber Recap explains what the week meant. This brief is about what you should do next.

Keeping you safe, one click at a time.

Originally published at https://www.linkedin.com.