Patch Tuesday August 2026: 398 fixes, one driver bug in use

Wednesday morning ACST, the MSRC feed pings. I grab my coffee, open the release notes, and start counting rows. 398 fixes. One of them, a Windows driver bug, was already being used against real machines before the patch existed. The volume is not the story. The 398 is the camouflage for the one that matters, and if you are the one person triaging this for an SMB fleet, your two evenings are already spoken for.

TL;DR

• Microsoft shipped 398 fixes on 11 August 2026, the biggest monthly release I can remember.
• One of them, CVE-2026-68820, a Windows driver local privilege escalation at CVSS 7.0, was being actively exploited before the patch shipped. That one goes first.
• Same week, the ShieldBreak proof-of-concept landed claiming a Microsoft Defender patch bypass with SYSTEM access. Defender updates ride a separate train, so treat it as its own work item, not part of the 398.
• CVSS is the wrong axis for a two-evening sprint. Patch on (a) is it exploited, (b) blast radius, (c) rollback cost.
• Plenty of the 398 can wait a month. I name the categories below.

What you need to do: patch the exploited driver bug tonight, ring-fence your internet-facing and identity boxes tomorrow night, and schedule the rest by component exposure, not by score.

By The Numbers

The order to patch in two evenings

Forget the CVSS-sorted spreadsheet. Here is the sprint.

Evening one: the exploited one, plus whatever it touches.

1. CVE-2026-68820 first. It is a driver-level LPE being used in the wild. On its own it is "only" local escalation, which means it is the second half of somebody else's intrusion chain. Attackers love these because they turn a foothold into full control quietly. Patch every Windows box that can run the affected driver, starting with anything users log into interactively: workstations, RDS hosts, jump boxes.
2. Anything with RDP, SMB, or identity exposure next. Domain controllers, file servers, anything listening on the internet or reachable from a VPN. Not because a specific CVE demands it, but because if the driver bug is the escalation half of a chain, the entry half is probably one of these.
3. Verify the Defender platform and signature updates actually applied. Defender updates on its own cadence and I have seen fleets where the OS patch went out and the AV engine sat three versions behind. With ShieldBreak floating around, that gap matters more than usual.

Evening two: remote code execution by reachability, then browsers.

4. RCEs in network-facing services, ordered by whether the service is reachable in your environment, not by score. A 9.8 in a role you do not install is below your action threshold. A 7.5 in something on every laptop is not.
5. Browser and Office fixes. These are your phishing-delivered attack surface. They patch cleanly, they rarely break anything, and they close the front door the driver bug needs to walk through.
6. Reboot enforcement. Nothing counts until the reboot happens. If your users defer reboots for a fortnight, that is a policy problem, not a patching problem, and this is the month to fix it.

That is the sprint. Two evenings, roughly six work items, everything else queued.

What the already-exploited driver bug actually is

CVE-2026-68820 is a local privilege escalation in a Windows driver, CVSS 7.0, and Microsoft confirmed active exploitation at release time. Krebs flagged it in his Patch Tuesday coverage and The Hacker News named it as the exploited item in the 398.

The mechanics matter for how you prioritise. An LPE is not an entry point. Nobody pops your network with 68820 alone. What it does is convert "I have a shell as a standard user" into "I am SYSTEM", and driver bugs are prized for this because they run in kernel space, below where most EDR products have their best visibility.

So the honest mental model is: this bug is the second domino. If your entry controls are solid, patching it quickly still buys you a broken kill chain for whoever tries next. If your entry controls are shaky, it is the difference between a contained phish and a domain-wide incident.

Microsoft issued the patch on Tuesday. Microsoft issued it because people were already being attacked through it. If you were going to patch in two evenings, you already had your answer before the second coffee.

One more thing: because it is a driver, the affected component is likely present on every Windows box in your fleet whether or not you ever knowingly use the feature. You do not get to scope this one down by "we don't run that". Check the MSRC update guide entry for your OS versions and assume broad exposure until proven otherwise. Expect it to land in the CISA Known Exploited Vulnerabilities catalog if it has not already, which is the closest thing to an official "patch this now" stamp there is.

The Defender zero-day PoC and what it means for AV

Same week, separate problem. The ShieldBreak proof-of-concept claims a Microsoft Defender patch bypass yielding SYSTEM access, per The Hacker News write-up. I covered Defender's rough run earlier this year in the RoguePlanet Defender 0day post, and the pattern is becoming familiar: the thing watching the door is itself an attractive door.

A few practical notes before anyone panics:

• It is a PoC claim, not a confirmed in-the-wild campaign. Treat it as "raise readiness", not "drop everything". The exploited driver bug outranks it until Microsoft or a credible third party confirms weaponisation.
• It is not part of the 398. Defender ships engine and platform updates on its own channel. Your Patch Tuesday runbook does not automatically cover it. Check your Defender platform version explicitly.
• Do not let this be the excuse to disable Defender. I have already heard the "AV is the attack surface, rip it out" take. For an SMB, Defender plus tamper protection plus cloud-delivered protection is still the best cost-to-coverage ratio available, and the attacker who uses an AV bypass against you is the same attacker who walks through an unprotected host on the way in. Keep it on, keep it current, layer it.

My contrarian hill this month, and I will die on it: CVSS-sorted triage is for conference slides, not for a two-evening sprint. A 9.0 in a component you do not run is below your action threshold. A 7.0 driver bug under active exploitation in a driver you cannot uninstall is the top of the list. The three questions that matter are: is it being exploited, what is the blast radius if it pops, and what does it cost me to roll the patch back if it breaks something. Everything else is decoration.

What you can defer to next month

Yes, you can skip things. Here is what I would comfortably push to the September cycle for a typical SMB fleet:

• CVEs in server roles and optional components you do not have installed. Sounds obvious, yet I see teams burn evenings scoring vulnerabilities in Hyper-V, IIS features, or legacy print components on boxes where the role was never enabled. Confirm absence, document it, move on.
• Pure denial-of-service fixes on internal-only services. Annoying, not urgent, unless the service is customer-facing.
• Information disclosure bugs with no known exploitation and no public PoC. Queue them for the regular ring rollout.
• Third-party and non-Windows items in the release that do not touch your stack.

The discipline is writing down what you deferred and why. "We looked, it does not apply, here is the ticket" is fine. "We never got to it" is not.

ANZ timezone: when it lands

Microsoft pushes at roughly 10:00 Pacific on the Tuesday, which puts the practical landing in the small hours of Wednesday for us:

• AEST (Brisbane/Sydney/Melbourne): around 03:00-03:30 Wednesday 12 August
• ACST (Adelaide/Darwin): around 02:30-03:00 Wednesday 12 August for the rollout window as it settled
• AWST (Perth): around 01:00-01:30

If you run rings, your pilot ring should have been pulling updates Wednesday morning and your broad ring should be targeting Thursday night through the weekend. If you are reading this on the morning of the 15th and the driver patch is not deployed, that is your weekend sorted.

FAQ

Does this change the priority list from the August advance-notification posts? Yes, materially. The advance notification had roughly 85 CVEs and 6 criticals, and both the earlier preview and the follow-up were built on that. The released bundle is nearly five times bigger and includes an exploited zero-day the preview could not have known about. Use this post's order, not the old one.

Should I patch with Driver Verifier off, or does it matter? Driver Verifier is a debugging tool, not a mitigation. It will not protect you from 68820 and you should not be running it in production anyway. The fix is the patch. If you are asking because a vendor suggested Verifier as a workaround, treat that advice as "we do not have a real answer yet".

Is ShieldBreak a Defender problem or a kernel problem? From what is public, it is a Defender platform problem: a claimed bypass of Microsoft's own fix reaching SYSTEM through the AV stack. The kernel only enters the picture because Defender components run there. The action item is the same either way: confirm your Defender platform version and watch for Microsoft's response.

We are an MSP with 40 tenants. Do we patch 68820 across all of them at once? Patch it everywhere, but not simultaneously. Run one representative tenant per hardware/driver profile through the pilot ring first, watch for boot and stability issues for 24 hours, then roll broad. Driver patches are where boot loops live, and 40 simultaneous boot loops is how you lose a weekend and two clients.

Does this interact with the BitLocker zero-day from May? Only in the sense that your fleet should already be patched for it. If you missed that one, the May write-up is here, and it belongs in evening one next to 68820, because an unpatched May zero-day plus a fresh LPE is a complete chain.

Microsoft says "exploitation detected". Detected by whom, against whom? Microsoft does not always say, and this release is no exception. It usually means their telemetry or a reporting partner saw it used in a real intrusion. You do not get to wait for victimology. "Someone, somewhere, got hit with this" is the whole briefing you need.

Further Reading

• MSRC Security Update Guide - the source of truth for the 398, filterable by product and exploitability
• CISA Known Exploited Vulnerabilities Catalog - check whether 68820 has been catalogued
• Krebs on Security - Brian's same-day Patch Tuesday coverage, as reliable as ever
• The Hacker News: Microsoft Patches 398 Flaws - the release summary naming the exploited driver bug
• The Hacker News: ShieldBreak Zero-Day PoC - the Defender bypass claim
• Patch Tuesday August 2026: advance notification - what we knew before the release, for comparison
• Windows Defender RoguePlanet 0day - Defender's earlier 2026 wobble
• Patch Tuesday May 2026: the BitLocker zero-day - the chain partner if you missed May

Mathew Clark Founder, SecureInSeconds Currently: watching the pilot ring reboot counter hit 100 percent and not trusting it until Monday.