{"slug": "building-a-patch-prioritization-rule-when-a-single-vendor-ships-970-fixes-in-a", "title": "Building a Patch Prioritization Rule When a Single Vendor Ships 970 Fixes in a Month", "summary": "A developer outlined a five-tier patch prioritization rule for handling Microsoft's September 2026 security update, which contained roughly 970 to 997 CVEs, more than 110 of them critical. The approach ranks confirmed exploitation first, followed by pre-authentication remote code execution on internet-reachable services, mail- and file-triggered RCE, local privilege escalation, and finally a risk-based schedule for everything else. The author argues that sorting a thousand CVEs by CVSS score alone produces a technically ordered but operationally useless list, and cites CISA's KEV catalog as evidence that exploited flaws remain concentrated in familiar defect classes.", "body_md": "For most of the last two decades, a monthly patch cycle meant a few dozen decisions. In September 2026, Microsoft's security update contained roughly 970 to 997 CVEs depending on how third-party components are counted, with more than 110 rated critical. A triage process built for a smaller volume stops producing a defensible answer at that scale.\n\nThis article is about the decision rule, not the individual vulnerabilities.\n\nMicrosoft has fixed approximately 2,750 vulnerabilities in 2026 to date, compared with about 1,250 in all of 2020. Security commentators have attributed a significant part of the increase to AI-assisted vulnerability discovery, which finds bugs faster than the downstream process can evaluate them.\n\nCISA's own review of 2024–2025 exploitation data reached a related conclusion: the vulnerabilities most often exploited were frequently old, well-understood defect classes that had been identified years earlier. The volume of new findings has grown, but the exploitation pattern has not changed as quickly.\n\nThose two observations together define the problem. The number of findings is rising, but the set of findings that actually gets exploited remains concentrated in a familiar set of conditions.\n\nThe following ordering is derived from the evidence in the September 2026 releases and the KEV catalog rather than from CVSS score alone. It is not a substitute for a risk assessment, but it gives a defensible default order.\n\n**Tier 1 — Confirmed exploitation.** Anything in CISA's Known Exploited Vulnerabilities catalog, or with vendor confirmation of in-the-wild use, goes first regardless of CVSS. In September 2026 this tier included the Windows Update Stack and ALPC privilege escalation flaws (CVE-2026-81963 and CVE-2026-85880), the SonicWall SMA1000 pair (CVE-2026-83548 and CVE-2026-83549), the JFrog Artifactory authentication bypass (CVE-2026-82329), the Kestra command injection (CVE-2026-49869) and the LiteLLM authentication flaw (CVE-2026-59822).\n\n**Tier 2 — Pre-authentication remote code execution on an internet-reachable service.** These are the flaws an external attacker can reach without credentials. In the September release, reported examples include Windows DNS Server (CVE-2026-69730), Remote Desktop Services (CVE-2026-69525), RRAS (CVE-2026-69852), SSTP (CVE-2026-73009) and the NFS ONCRPC XDR driver (CVE-2026-70585).\n\n**Tier 3 — Mail-triggered and file-triggered RCE.** The Exchange Server use-after-free, CVE-2026-55007, belongs here. It is triggerable by sending an email with a malicious Visio attachment, and the recipient does not need to open it. Flaws that bypass user action defeat awareness training and therefore deserve a faster timeline than the general cycle.\n\n**Tier 4 — Local privilege escalation without confirmed exploitation.** Lower urgency than Tier 1, but not low. These are the escalation step in a chain, and an attacker with any foothold will use them.\n\n**Tier 5 — Everything else, on a risk-based schedule.**\n\nA 7.8 local privilege escalation flaw and a 9.8 pre-authentication RCE can both be critical, but they are not interchangeable. The LPE requires an existing foothold; the RCE does not. Sorting a thousand CVEs by score produces a list that is technically ordered and operationally useless, because it puts the two exploited LPE flaws in the middle of a long tail of 7.8s.\n\nThe KEV catalog resolves this by encoding exploitation evidence rather than theoretical severity. Its limitation is coverage: it reflects what has been observed, and a vulnerability can be exploited before it is listed.\n\nThis article describes a prioritization approach, not a compliance requirement. The vulnerability counts cited vary between sources because of differing treatment of Chromium and non-Microsoft components. The tier assignments reflect the reporting available at the time of writing and should be re-derived for each release rather than copied forward.", "url": "https://wpnews.pro/news/building-a-patch-prioritization-rule-when-a-single-vendor-ships-970-fixes-in-a", "canonical_source": "https://dev.to/onaeiuspkz/building-a-patch-prioritization-rule-when-a-single-vendor-ships-970-fixes-in-a-month-573g", "published_at": "2026-09-22 04:40:06+00:00", "updated_at": "2026-09-22 04:52:35.302421+00:00", "lang": "en", "topics": ["ai-safety"], "entities": ["Microsoft", "CISA", "SonicWall", "JFrog", "Kestra", "LiteLLM", "Windows Update Stack", "Exchange Server"], "alternates": {"html": "https://wpnews.pro/news/building-a-patch-prioritization-rule-when-a-single-vendor-ships-970-fixes-in-a", "markdown": "https://wpnews.pro/news/building-a-patch-prioritization-rule-when-a-single-vendor-ships-970-fixes-in-a.md", "text": "https://wpnews.pro/news/building-a-patch-prioritization-rule-when-a-single-vendor-ships-970-fixes-in-a.txt", "jsonld": "https://wpnews.pro/news/building-a-patch-prioritization-rule-when-a-single-vendor-ships-970-fixes-in-a.jsonld"}}