Every second Tuesday of the month, a small ritual plays out across IT departments worldwide: coffee gets cold, change-management tickets pile up, and someone quietly hopes nothing on the list is already being exploited. This August, that hope is misplaced. Microsoft's August 2026 Patch Tuesday shipped fixes for 107 vulnerabilities, and three of them are confirmed zero-days already seen in active attacks.
Here is the uncomfortable stat that should shape your afternoon: according to multiple incident-response retrospectives, the median time from a public Patch Tuesday disclosure to mass exploitation attempts has collapsed to roughly five days. For zero-days that are already weaponized on release day, that window is zero. You are not racing a clock that starts when you finish testing. The clock started before Microsoft published the advisory.
This article breaks down the three zero-days you must prioritize before anything else on the August 2026 list, gives you a concrete triage order with real CVSS numbers, walks you through a defensible patch-deployment sequence, and shows how to protect the web-facing assets that attackers usually hit first while your Windows patches roll out. Let's get to work.
Key Takeaways
- Three confirmed zero-days lead the August 2026 list: a Win32k elevation-of-privilege bug, a Windows LSA remote code execution flaw, and a scripting-engine memory-corruption issue. Patch these first.
- The LSA RCE (CVSS 8.8) is the crown jewel for attackers because it can be reached over the network with no user interaction. Prioritize domain controllers and internet-adjacent hosts.
- Elevation-of-privilege zero-days rarely make headlines but enable ransomware. They turn a foothold into full domain compromise. Do not deprioritize them because the CVSS looks "only" 7.8.
- Web-facing CMS and e-commerce sites are the softest entry point. Harden WordPress, Joomla, and PrestaShop in parallel with your OS patching, not after.
- Stage before you deploy. A 48-hour ring rollout with rollback snapshots beats a panicked all-at-once push that breaks production.
What Makes the August 2026 Patch Tuesday Zero-Days Different
A zero-day is a vulnerability that is being exploited in the wild before, or at the same time as, a patch becomes available. The "zero" refers to the number of days defenders had to prepare. Not every high-severity CVE is a zero-day, and not every zero-day is high severity. The dangerous overlap is when a flaw is both critical and already exploited.
August 2026 gives us three such cases. Out of 107 total fixes, roughly 13 are rated Critical, and the rest split between Important and Moderate. But CVSS alone is a poor prioritization tool. A CVSS 9.8 that requires a rare, unpatched third-party service to be installed matters less than a CVSS 7.8 that any local attacker with a phishing foothold can trigger on every Windows machine you own.
The three zero-days this month share a nasty property: they chain. An initial phishing email delivers a payload, the scripting-engine bug executes code in the browser or Office context, the Win32k bug escalates that code to SYSTEM, and the LSA flaw lets it spread laterally to other machines. Any one of them is a problem. Together they are a ransomware playbook.
How to read a Patch Tuesday advisory in under two minutes
- Filter the CVE list to entries flagged "Exploitation Detected" or "Exploitation More Likely." Those are your zero-days and near-zero-days.
- Note the attack vector: Network (worst), Adjacent, Local, or Physical. Network-reachable bugs jump the queue.
- Check privileges required and user interaction. "None/None" means it can fire without any human doing anything wrong.
- Map the affected component to your actual estate. A Hyper-V bug is irrelevant if you run no Hyper-V hosts.
- Cross-reference against your internet-facing surface. External-facing first, internal second.
The 3 Zero-Days to Patch Before Anything Else
Here are the three, in the order I would deploy them across a typical mixed Windows environment.
1. Windows LSA Remote Code Execution (CVSS 8.8) — patch first
The Local Security Authority handles authentication and credential storage. A remote code execution bug here is close to a worst-case scenario because LSA runs with high privilege and is reachable during authentication flows. The advisory lists the attack vector as Network with low complexity and no user interaction required.
Translation: an attacker who can reach the authentication service, which on a domain controller means effectively the whole internal network, can run code without tricking a single employee. Domain controllers, RADIUS servers, and any host exposing authentication endpoints go to the front of the line.
2. Win32k Elevation of Privilege (CVSS 7.8) — patch second
Win32k is the kernel-mode graphics and windowing subsystem, and it is a perennial favorite for privilege escalation because it is huge, old, and reachable from low-privilege code. This zero-day lets an attacker who already has a foothold, say through a malicious document, jump to SYSTEM.
It sounds less scary than an RCE, and the CVSS is lower. Do not be fooled. Nearly every human-operated ransomware incident includes a privilege-escalation step, and Win32k bugs are the go-to. Roll this out to workstations and any machine where users open email or documents.
3. Scripting Engine Memory Corruption (CVSS 7.5) — patch third
This one enables the initial code execution when a user views crafted content in a legacy scripting context, which still lurks inside Office previews, HTA files, and some embedded webviews. It is the "front door" of the chain. Patch it alongside the Win32k fix on endpoints, since the two are usually delivered in the same cumulative update anyway.
Priority comparison at a glance
| Zero-day | CVSS | Attack vector | User interaction | Priority target | Deploy order |
|---|---|---|---|---|---|
| LSA RCE | 8.8 | Network | None | Domain controllers, auth servers | 1st (0–24h) |
| Win32k EoP | 7.8 | Local | None | Workstations, RDS hosts | 2nd (24–48h) |
| Scripting Engine | 7.5 | Local | Required | Endpoints with Office/browsers | 2nd–3rd (24–48h) |
A Worked Example: Triaging a 220-Machine Environment
Abstract advice is easy to nod along to and hard to execute. So let's make it concrete. Say you run IT for a mid-sized company with the following estate:
- 4 domain controllers
- 18 Windows servers (file, print, app, database)
- 2 Remote Desktop Session hosts serving 40 users
- 190 Windows 11 workstations
- 6 internet-facing web servers running WordPress, Joomla, and a PrestaShop store
That is 220 Windows machines plus a web tier. If you tried to patch everything at once, you would risk simultaneous reboots across production and no rollback path. Here is how the sequence actually plays out over 48 hours.
Hour 0–4: containment and staging
- Snapshot the 4 domain controllers and the 2 RDS hosts. Non-negotiable rollback insurance.
- Pull the August cumulative update into your patch tool (WSUS, Intune, or your RMM) and approve it only for a pilot ring of 1 DC, 2 servers, and 5 workstations.
- While that stages, review your web-server logs for exploitation attempts on the CMS tier. Attackers often probe the soft web layer while the OS layer is still exposed.
Hour 4–24: pilot and domain controllers
- Confirm the pilot ring rebooted cleanly and authentication still works. Test a domain login, a file-share access, and an RDS session.
- Roll the LSA-fixing update to all 4 domain controllers, one at a time, waiting for each to return healthy before the next. Four DCs done serially is roughly a 90-minute job including reboots.
- Patch the 2 RDS hosts during a scheduled 15-minute maintenance window. Warn the 40 users a day ahead.
Hour 24–48: servers and the fleet
- Deploy to the remaining 18 servers in two rings of 9, database servers last.
- Push to the 190 workstations in three waves of roughly 63 machines, with a deferred reboot so users aren't kicked mid-task.
- Verify patch status with a compliance report. Chase the inevitable 5–8% of machines that were offline or failed.
The math matters here. Reboots aside, the human bottleneck is verification, not installation. Budget your time around confirming health, not around clicking "install." And keep those web servers in view the whole time, because they are the assets most likely to be attacked during your patch window.
Don't Forget the Web Tier: WordPress, Joomla, and PrestaShop
Here is the gap I see constantly. Teams treat Patch Tuesday as a Windows-only event, patch the OS diligently, and leave a WordPress install running an unpatched plugin that an attacker walks straight through. Your public web servers are usually the first thing scanned and the first thing hit.
The same week as this Patch Tuesday, plugin-level flaws continue to surface. We recently broke down one such issue in our analysis of the WP Maps Pro admin-bypass flaw, and the recurring wp2shell attack that turns a single upload into a full shell is worth reviewing if you run WordPress at all. These are not theoretical.
Practical web-tier hardening while you patch
- WordPress: Enforce update discipline on plugins and themes, restrict the admin surface, and block hostile IP ranges. Tools like the Cover image: Software value feedback loop by jakuza, licensed under BY-SA 2.0 via Openverse.
