September 2026 Patch Tuesday: What Your Pentest Must Cover
On the Wednesday after release, someone on the Windows team had the September 2026 Patch Tuesday spreadsheet open: close to a thousand rows. Sorted by "Exploited", two lines floated to the top. Both were Windows privilege escalation bugs, both scored CVSS 7.8, and both were already in CISA's Known Exploited Vulnerabilities catalog.
Then the security lead asked the question that matters more than the patch schedule: "Would our last pentest have caught either of these?"
The honest answer is no, and that is not a failure of the tester or the vendor. Both zero-days are local privilege escalation flaws, so an attacker must already be running code on the machine before either is useful. An external penetration test, ours included, starts from the internet without that foothold.
More than three weeks after the 8 September release, the patching should be done. The scope question is not, and it returns every time Microsoft ships an exploited local bug. Below: what shipped, what each type of test can and cannot see, and scope language you can reuse for October's release.
What Microsoft Shipped on 8 September
September's release is the largest Microsoft has published. BleepingComputer counted 966 flaws, not including cloud and other fixes Microsoft published earlier in the month. That is roughly 70% more than the previous record of 570, set only two months earlier in July. By type (BleepingComputer's counts):
- Elevation of privilege: 438 CVEs, roughly 45% of the release
- Remote code execution: 258 CVEs, roughly 27%
- Information disclosure: 173 CVEs, roughly 18%
BleepingComputer counts 105 as Critical. Nearly half the release is privilege escalation: bugs that matter once an attacker already has some access.
Why the count is the least useful number in the release
A record count makes a good headline and a poor triage tool. Nobody patches nearly a thousand CVEs in priority order; they deploy one cumulative update per Windows version and argue about which servers go first. The useful questions are which bugs are exploited now and which are reachable from where an attacker already is, the argument we made about August in our QUIC RCE post. Through that lens, two CVEs stand out.
The Two Zero-Days, in Plain English
Both are exploited in the wild, and CISA added both to the Known Exploited Vulnerabilities catalog on 8 September with a due date of 22 September. They affect different Windows versions. Before you brief anyone, check each record with our CVE lookup tool or the Microsoft Security Response Center entry, because vendor wording shifts after release.
The location of CVE-2026-81963 is what makes it uncomfortable. The Update Stack installs every other fix, runs with the highest privileges by design, and supplies the installed-update status that much Windows patch-compliance reporting relies on. It still scores only 7.8 because the base score reflects the attack vector and privileges required, not urgency.
Why "Important, 7.8" outranks "Critical, 9.8"
Sort by CVSS and CVE-2026-69730 sits near the top: a 9.8 use-after-free remote code execution bug in Windows DNS Server, reachable over the network with no authentication or user interaction. Microsoft's own CVSS record marks its exploit code maturity as "unproven", and it was not in KEV as of CISA's 29 September catalog. The two 7.8s are already being used against real targets, and a confirmed exploit at 7.8 beats a hypothetical one at 9.8.
In practice you are not choosing between CVEs. On each Windows version, one September cumulative update fixes whichever of the three applies, so the real choice is which hosts go first. Our advice: workstations and servers where users run code, and any Windows DNS server (above all a domain controller or anything internet-reachable), in the same first wave.
How These Bugs Get Used in Practice
Nobody breaks into an organisation with a privilege escalation bug. They break in with something else, then use the escalation to finish the job. Which of September's zero-days fits depends on the Windows version the foothold lands on:
The zero-days decide how bad a foothold becomes; they do not create it, which is why initial access is the real question when deciding what to test. And as our 48-hour exploit window post showed, the gap between disclosure and exploitation is now measured in days; both of these were exploited before a fix existed.
One more possibility deserves a careful caveat. Microsoft has not published post-exploitation details for CVE-2026-81963, and we are not aware of any report of attackers using it to falsify patch status. Treat patch-reporting tampering as a risk to plan for, not a documented technique. Any attacker with SYSTEM on a host can alter what that host reports about itself, and this bug sits inside the machinery that produces the "installed" status. That does not make every compliance report suspect. It means that for this CVE, a self-reported "installed" is weaker evidence than usual.
Which raises the most practical question of the September release: how do you know the patch actually landed?
See what your external surface exposes, mapped to the controls it touches.
Run a free External Security Check →Patched Is a Claim; Verified Is a Fact
"We deployed the cumulative update" describes an action, not an outcome. Deployments fail silently, reboots get deferred, and some hosts were never enrolled. When one exploited bug sits inside the update stack, verify independently:
CurrentBuild and UBR values under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion, not Windows Update's own reporting. This is independent of the update tooling, not of the host: once an attacker has SYSTEM, any local value can be forged, so a host you suspect was compromised belongs in incident response.Compliance frameworks point the same way. PCI DSS v4.0.1 requirement 11.4.3 calls for external penetration testing at least once every 12 months and after any significant infrastructure or application change, and 11.4.2 applies the same trigger internally. Whether an emergency patch cycle counts as "significant" is a judgement your assessor will want documented; our PCI DSS 4 pentest requirements guide covers how to frame it. In Australia, the Essential Eight "patch operating systems" strategy sets windows as short as 48 hours where a working exploit exists, varying by maturity level and by whether a system is internet-facing, so check the current ACSC Maturity Model wording before quoting a deadline to your board.
Verification tells you whether the patch landed, not what an attacker could have done with the gap. That is a testing question, and different tests answer it very differently.
What Each Type of Test Can Actually See
Every test starts from a vantage point and can only observe what is reachable from there:
| Bug class | External pentest | Internal/network pentest | Assumed-breach test | Authenticated vuln scan | EDR / purple team |
|---|---|---|---|---|---|
| Local privilege escalation (CVE-2026-81963) | Not without a foothold | Only if tester gains a foothold | Yes, the escalation path is the primary objective | Detects missing patch, does not test exploitability | Can detect exploitation attempts |
| Local privilege escalation (CVE-2026-85880) | Not without a foothold | Rarely in scope | Yes, when scoped to attempt local escalation | Detects missing patch | Can validate detection of the chain |
| Unauthenticated network RCE (e.g. DNS Server, SMB) | Exposure and advertised version, if the service is internet-exposed | Yes, for internal exposure | Partially, as a lateral-movement path | Detects missing patch | Limited, depends on telemetry |
| Client-side Office RCE | Not visible | Not usually | Only if phishing simulation is scoped | Detects missing patch | Can validate detection |
| Exposed unpatched service | Yes, core purpose | Yes, internally | Incidental | Yes, if host is in scan scope | No |
So, plainly: an external test, from any vendor, cannot exercise CVE-2026-81963 or CVE-2026-85880 unless it first gains a foothold and is scoped to go further. An independent external assessment answers the perimeter questions, the systematic part of the work; an assumed-breach engagement answers the local ones. Our post on when automated pentesting is enough covers that boundary in detail.
An assumed-breach engagement tests whether a standard user can become SYSTEM, whether credentials can be harvested and reused, and whether your detection alerts before the tester reaches a domain controller. Be realistic: on a fully patched host a tester will not reproduce these two zero-days, and in-the-wild exploits are rarely made public. What the engagement measures is whether escalation is possible at all and whether you would see it, which outlasts September's CVE numbers.
- Tests whether a standard user can reach SYSTEM by any route an attacker would use post-foothold
- Validates whether your EDR detects the technique classes these bugs belong to, such as link-following abuse of privileged file operations
- Produces evidence of exploitability, not just presence
- Can form part of PCI DSS 11.4.2 internal penetration testing when scoped to the cardholder data environment
- Requires provisioning a test endpoint and user account
- More complex scoping and rules of engagement
- Higher cost than an external-only test
- Needs careful out-of-scope controls to avoid disrupting production
Where the external test still earns its place in the September release
None of that makes an external test irrelevant. It is the right tool for several of the release's most important questions:
- Windows DNS Server exposure (CVE-2026-69730). A CVSS 9.8 unauthenticated remote code execution flaw affecting Windows Server 2012 to 2025, which CISA's enrichment of the CVE record rates "automatable", the property closest to what people mean by wormable. Windows DNS Server commonly runs on domain controllers. An external test is built to find anything answering on port 53 from the internet; confirming it is Windows DNS Server takes a fingerprinting step or a check against your inventory, which is why the scope clause below asks for it.
- Exchange surface. Where Exchange is internet-facing, an external test shows what is listening and what version it claims to be.
- RDP and SMB exposure. Still common initial-access routes, and neither should be reachable from the internet.
- Build banners that contradict the CMDB. A service advertising an older build than your records say means patching and inventory have drifted apart.
To find hosts you forgot you had, start with our subdomain finder on your own domain. Our DNS analyzer shows your DNS records and configuration; it does not detect CVE-2026-69730. As in our Fortinet authentication bypass post: know what is exposed before arguing about what is patched.
Neither September zero-day is reachable from the outside. The gap is in scope documents that describe an external test and get read as if they covered everything, and fixing that is mostly a matter of writing things down.
The Scope Language for Your Next Pentest
Scope documents are where coverage gaps are either named or quietly assumed away. Here are six scope clauses for your next request for proposal or statement of work. Each is labelled with the engagement it belongs in, as a starting point to adapt with your tester, assessor and advisers:
The first two clauses give the tester the foothold an external engagement never has and make the result measurable: did escalation succeed, how, and did EDR notice? Where the estate mixes Windows 10 and Windows 11, consider a test endpoint of each, since escalation paths differ by version. The third forces a clear answer on CVE-2026-69730 exposure, the fourth matches the "significant change" language in PCI DSS 11.4.2 and 11.4.3, and the fifth closes the loop, because a finding is not fixed until a retest confirms it. The last is the one most scopes miss: it stops anyone reading the report as proof that local escalation was tested.
MSP operators can reuse one scope template across client tenants; we covered that model in MSP penetration testing economics.
What to Do Now
The priority list is short, and items 3 and 5 apply to every release:
- Confirm every Windows host has its September cumulative update, verified by build number from an independent source. That closes CVE-2026-81963 on Windows 11 and Server 2025, and CVE-2026-85880 on Windows 10 and Server 2012 to 2022.
- Find any Windows DNS servers in your own estate that answer on port 53 from the internet. Patch CVE-2026-69730 on those hosts immediately, then ask why they are reachable at all.
- Search your last pentest report for "privilege escalation" and "assumed breach". If neither appears, your testing has never examined the part of the chain these zero-days sit in.
- Brief the board with three numbers: two KEV-listed zero-days, one unauthenticated DNS Server RCE, and the total you patched.
- If your scope has never addressed internal privilege escalation, add it to the next request using the clauses above. It is cheaper to scope it deliberately than to discover it during an incident.
October's release will bring its own zero-days, and some will be local again. The teams that handle it calmly are the ones whose scope documents already say what each test covers and what it does not.