Patch Tuesday August 2026: ANZ SMB Priority List

TL;DR: Microsoft's August 2026 Patch Tuesday drops Tuesday 12 August (US time) - that's Wednesday 13 August morning ACST for ANZ shops. Six critical CVEs. One Windows kernel privilege-escalation needs an emergency-track reboot. One SharePoint RCE chain (two CVEs working together) is the highest-risk item for any SMB running SharePoint Server on-prem or hybrid. The remaining four critical CVEs can ride your normal maintenance window if you're not internet-exposed on those surfaces.

What you need to do: Prioritise the kernel patch and SharePoint chain. Get a test environment validation done before your Wednesday morning production push. Have a rollback snapshot ready on your SharePoint server before you touch it.

By The Numbers

The Setup: Why This One Matters More Than Most

I was checking the MSRC RSS feed on a Tuesday morning - coffee still hot, Teams notifications already piling up - when the advance notification for August came through. Six critical CVEs is not unusual for a Patch Tuesday. What caught my eye was the combination: a kernel priv-esc and a chained SharePoint RCE in the same release.

Those two together are a problem. The kernel CVE means any local user or process that can run code can escalate to SYSTEM. The SharePoint chain means an unauthenticated remote attacker can potentially get code running in the first place. If you're running SharePoint Server on-prem with any external access at all - even just hybrid connector traffic - that's a path from the internet to SYSTEM on your SharePoint box in two steps.

For ANZ SMBs specifically, this is worth paying attention to. A lot of shops in the 50-500 seat range are still running SharePoint Server 2019 or 2016 on-prem, sometimes with a hybrid config bolted on to M365. That's exactly the attack surface this chain targets. CISA flagged it in their advisory on 9 Jul 2026, and BleepingComputer's preview on 11 Jul 2026 called the SharePoint chain one of the higher-priority items in the release.

The good news: this is not a zero-day. There's no confirmed in-the-wild exploitation at time of writing. You have a week to test and stage. Use it.

ANZ Timezone: When Does This Actually Land?

Patch Tuesday is always the second Tuesday of the month in US time. That's 12 August 2026. Microsoft typically releases updates around 10:00 PST / 17:00 UTC.

For ANZ:

ACST (Adelaide, Darwin): Wednesday 13 August, approximately 02:30-03:00 ACST
AEST (Sydney, Melbourne, Brisbane): Wednesday 13 August, approximately 03:00-03:30 AEST
AWST (Perth): Wednesday 13 August, approximately 01:00-01:30 AWST

Plan your maintenance window for Wednesday 13 August evening ACST/AEST if you want a full day of testing first. That gives you Wednesday morning to grab the patches, test in a non-prod environment during business hours, and push to production Wednesday night.

If you're on Intune or WSUS with automatic approvals, double-check your deferral settings now. You do not want the kernel patch auto-deploying to production servers at 3am Wednesday before you've validated it.

The Six Critical CVEs: Priority Order

Here's how I'd stack these based on the advance notification detail. Note that full CVE numbers will be confirmed on 12 August when MSRC publishes the full update guide - the below reflects advance notification detail (ATTRIBUTION-ONLY).

Priority 1 - Windows Kernel Privilege Escalation (Patch Immediately)

This is the one that needs an emergency-track response. A local privilege escalation in the Windows kernel means any low-privileged code running on the box - malware, a compromised service account, a rogue script - can escalate to SYSTEM. Kernel priv-esc CVEs are the backbone of almost every post-exploitation chain.

Action: Patch all Windows Server instances and Windows 10/11 endpoints. Reboot required - plan for it. On servers, coordinate with your teams for the reboot window. Don't defer this one past your first available maintenance window.

Testing note: Kernel patches occasionally cause driver compatibility issues. If you have any legacy hardware drivers or third-party kernel-mode software (some AV products, backup agents), test on a representative machine before broad deployment.

Priority 2 - SharePoint Server RCE Chain (Patch Before External Exposure)

Two CVEs working in sequence. The first allows an unauthenticated attacker to reach a vulnerable endpoint. The second allows code execution in the context of the SharePoint application pool. Chained together, this is a pre-auth RCE against SharePoint Server.

Affected versions (ATTRIBUTION-ONLY, confirm against MSRC on 12 Aug): SharePoint Server 2019, SharePoint Server Subscription Edition, potentially SharePoint Server 2016 with extended support.

Action for on-prem/hybrid shops:

Take a snapshot or backup of your SharePoint server before patching.
Test the cumulative update in a non-prod SharePoint farm first - SharePoint CUs have a history of breaking custom solutions.
If you cannot patch immediately and you have SharePoint externally accessible, consider temporarily blocking external access at the WAF or firewall level until the patch is applied.
Apply the patch during a scheduled maintenance window and validate SharePoint search, workflows, and any custom web parts before bringing the farm back online for users.

If you're on SharePoint Online only: You're covered by Microsoft - no action required on your end.

Priority 3 - The Remaining Four Critical CVEs

The other four critical CVEs in this release are lower urgency for most ANZ SMBs, but still need to land in your next maintenance window. Here's the quick rundown based on advance notification detail:

Windows DNS Server RCE - Affects Windows Server instances running the DNS Server role. If your DNS server is internet-facing (it shouldn't be, but here we are), prioritise this one. Internal-only DNS servers can ride the normal monthly cycle.

Remote Desktop Gateway RCE - Affects RD Gateway configurations. If you're running RD Gateway as a remote access solution - still common in SMBs that haven't moved to VPN or Azure AD joined devices - patch this before your next external-access window. Not pre-auth, requires a valid session, but still critical rating.

Microsoft Office Remote Code Execution - The classic Office RCE via malicious document. Affects Office 2019 and Office LTSC 2021. If your fleet is on M365 Apps, you're likely already protected via Click-to-Run automatic updates. Check your update channel settings to confirm. If you have any machines on perpetual Office licenses, get this patch applied.

Windows Hyper-V Escape - A guest-to-host escape in Hyper-V. If you're running Hyper-V on-prem (common in SMBs using Windows Server as a virtualisation host), this is important. A compromised guest VM can potentially affect the host. Patch the host OS.

Important CVEs Worth Noting

Beyond the criticals, a few Important-rated CVEs are worth flagging:

Exchange Server spoofing CVE - If you're still running Exchange on-prem (yes, some of you are), there's a spoofing vulnerability that could be used to bypass email authentication checks. Patch it.
Windows Print Spooler elevation of privilege - PrintNightmare's spiritual descendants keep coming. Patch it, and if you haven't already disabled the Print Spooler service on domain controllers, do that now regardless of this patch.
Azure Arc information disclosure - Lower risk for most SMBs, but if you're using Azure Arc for hybrid server management, apply the update.

The full list will be on the MSRC update guide from 12 August. I'd recommend bookmarking https://msrc.microsoft.com/update-guide and filtering by "Critical" and "Important" on release day.

Testing Checklist Before You Push to Production

I know some of you are reading this thinking "we just approve and deploy, we don't have a test environment." I get it - at 50 seats, a full test lab is hard to justify. But for a release with a SharePoint CU and a kernel patch, you really want at least a minimal validation pass before production. Here's a practical checklist scaled for SMB reality.

Test Environment (Minimum Viable)

If you don't have a dedicated test environment, here's the minimum:

One Windows Server VM (non-production) to validate the kernel patch and confirm no driver conflicts
One SharePoint Server VM restored from a recent backup or snapshot - this is your SharePoint CU test bed
One Windows 10/11 test machine (a spare laptop works) for the Office and kernel patches
WSUS or Intune test group containing only the above machines

If you're on Intune, create a test deployment ring now if you don't have one. Target it at your IT machines and a handful of volunteer early-adopter users. Deploy there first, give it 24 hours, then push to production.

Validation Steps After Patching

Windows Server (kernel patch):

Server reboots cleanly and comes back online
Key services restart correctly (check Event Viewer for errors on startup)
Any third-party kernel-mode software (AV, backup agent) still functioning
No unexpected driver errors in Device Manager

SharePoint Server:

Central Administration loads correctly
At least one site collection loads and renders correctly
Search crawl can be initiated (check Search Service Application status)
Any custom web parts or solutions load without errors
Hybrid connector traffic (if applicable) still flowing - check hybrid picker or hybrid site features
Run the SharePoint Products Configuration Wizard fully - this step gets skipped and causes problems

Office (perpetual license machines):

Office apps open without errors
A test document opens and saves correctly
Outlook connects to Exchange/M365 without re-auth prompts

Rollback Plan

Before you touch the SharePoint server in production, have a rollback path ready:

VM snapshot - Take a snapshot of the SharePoint VM before applying the CU. Keep it for at least 72 hours post-patch.
SQL database backup - Back up the SharePoint content databases before patching. The CU can update the database schema, and a rollback without a database backup is painful.
Document your current patch level - Note the current CU version before you patch. You'll need this if you're calling Microsoft support.
Test the rollback - In your test environment, actually test reverting to the snapshot. Confirm it works before you need it in production.

For the kernel patch on Windows Servers, a VM snapshot before patching is your best friend. For physical servers, make sure your backup is current before the maintenance window.

ANZ Timezone Tracking: Your Patch Tuesday Week

Here's the week mapped out for ANZ IT-pros:

| Day / Date | Event | | - -| - -| | Monday 11 Aug | Final pre-patch checks. Confirm test environment is ready. Notify users of Wednesday night maintenance window. | | Tuesday 12 Aug (US) / Wed 13 Aug ~03:00 ACST | Microsoft releases updates. WSUS/Intune starts syncing. | | Wednesday 13 Aug (business hours) | Grab patches in test environment. Run validation checklist. Check MSRC update guide for any surprises vs. advance notification. | | Wednesday 13 Aug (evening) | Production maintenance window. Kernel patch + reboot on servers. SharePoint CU if test passed. | | Thursday 14 Aug | Monitor Event Viewer, helpdesk tickets, SharePoint health. Keep snapshots live. | | Friday 15 Aug | If all clear, close the maintenance window. Archive your patch notes. |

If you hit a problem with the SharePoint CU on Wednesday evening, having Thursday as a buffer day before the weekend is valuable. Don't schedule this for a Friday night.

Key Takeaways

The kernel priv-esc is your highest-urgency patch - it enables local privilege escalation to SYSTEM on any Windows machine. Reboot required. Get this done in your first available maintenance window.
The SharePoint RCE chain is the highest-risk item for on-prem/hybrid SMBs - two CVEs working together create a pre-auth RCE path. Snapshot your SharePoint server before patching, test the CU in a non-prod environment first.
ANZ production window: Wednesday 13 August evening - patches drop Wednesday morning ACST,
If you're on SharePoint Online only, you're already covered - Microsoft handles patching on their end. No action required.
Check your WSUS and Intune deferral settings now - auto-approval on a kernel patch that requires a reboot can surprise you at 3am. Confirm your rings are configured before Tuesday night.
Snapshot before you touch SharePoint - the CU can update database schema. A snapshot without a SQL content database backup is not a real rollback. Do both.
The remaining four critical CVEs are not emergencies, but they're not optional - DNS Server RCE, RD Gateway RCE, Office RCE, and Hyper-V escape all need to land in your next scheduled maintenance window. Don't let them drift past August.

FAQ

Q: When exactly does Patch Tuesday August 2026 land in Australia?

Microsoft releases around 10:00 PST on Tuesday 12 August, which is approximately 03:00 AEST / 02:30 ACST on Wednesday 13 August. Perth (AWST) sees it around 01:00. Plan your test pass for Wednesday morning and your production window for Wednesday evening.

Q: Is the SharePoint RCE chain being actively exploited right now?

No confirmed in-the-wild exploitation at time of writing (based on MSRC advance notification and CISA advisory dated 9 Jul 2026). That can change after the patch drops on 12 August, since publishing a patch also publishes a roadmap for attackers. Patch before that window opens.

Q: Does the Windows kernel CVE affect Windows 10 and 11 endpoints, or only servers?

Both. The advance notification indicates the kernel privilege escalation affects Windows 10, Windows 11, and Windows Server (multiple versions). Endpoint patching matters here, not just servers.

Q: Do I need to reboot after the kernel patch?

Yes. Kernel patches require a full reboot to take effect. There is no way around this. Plan your reboot window, notify affected users, and don't defer the reboot thinking the patch is applied without it - it isn't.

Q: We're on SharePoint Online only. Do we need to do anything for the SharePoint RCE chain?

Nothing. Microsoft patches SharePoint Online on their end. This vulnerability only affects SharePoint Server on-premises (2016, 2019, Subscription Edition) and hybrid configurations where SharePoint Server is in the chain.

Q: Our SharePoint Server is internal only, not internet-facing. Are we still at risk?

Lower risk than an internet-exposed farm, but not zero. The RCE chain requires reaching the vulnerable endpoint. If an attacker already has a foothold inside your network (phishing, compromised endpoint), an internal SharePoint Server is reachable. Patch it anyway.

Q: We're a small shop with no test environment. Can we just push straight to production?

For the kernel patch on endpoints, the risk of skipping a test pass is manageable if you have a rollback snapshot on servers. For the SharePoint CU, I'd strongly recommend against going straight to production. SharePoint CUs have a history of breaking custom solutions and requiring the Configuration Wizard to be run manually. At minimum, restore a backup to a temporary VM and run through the basic validation checklist above before touching production.

Q: Where do I find the full CVE list when it drops on 12 August?

The MSRC Security Update Guide at https://msrc.microsoft.com/update-guide is the authoritative source. Filter by release date (August 2026) and severity (Critical, then Important). BleepingComputer's Patch Tuesday roundup usually publishes within a few hours of release and is a good plain-English summary alongside the MSRC detail.

My Take

Patch Tuesday gets treated as a fire drill in a lot of SMB shops, and I understand why. You've got one IT person, or maybe a part-time MSP, and a business that needs to keep running. The instinct is to wait a week, see if anyone reports problems, then quietly push the patches when nobody's looking. That approach works fine for a routine month. This is not a routine month.

A kernel priv-esc and a chained SharePoint RCE in the same release is the kind of combination that shows up in post-incident reports. Not because either one alone is necessarily catastrophic, but because together they create a path from the internet to SYSTEM on a box that probably holds a significant chunk of your business's documents and internal communications. The window between Microsoft publishing a patch and attackers reverse-engineering it to build an exploit is getting shorter. It used to be weeks. Now it's sometimes days.

The thing I'd push back on is the idea that patching SharePoint is too risky because it might break something. Yes, SharePoint CUs can break things. That's why you test first and snapshot before you touch production. The risk of a broken SharePoint CU that you can roll back in 20 minutes is not comparable to the risk of an unpatched SharePoint Server sitting on your network for three weeks while someone works out how to chain these two CVEs. One of those risks is recoverable on your terms. The other one isn't.

My honest recommendation: block out two hours on Wednesday 13 August. One hour to test. One hour to patch production and validate. Have your snapshots ready beforehand. That's the whole job for this release. Two hours is a reasonable price for not being the shop that gets owned through a SharePoint exploit in September.

Mathew Clark Founder, SecureInSeconds Currently: sitting in Adelaide with the heater on, waiting for the MSRC RSS feed to update and quietly dreading the kernel reboot on the test box

Patch Tuesday August 2026: ANZ SMB Priority List

By The Numbers

The Setup: Why This One Matters More Than Most

ANZ Timezone: When Does This Actually Land?

The Six Critical CVEs: Priority Order

Priority 1 - Windows Kernel Privilege Escalation (Patch Immediately)

Priority 2 - SharePoint Server RCE Chain (Patch Before External Exposure)

Priority 3 - The Remaining Four Critical CVEs

Important CVEs Worth Noting

Testing Checklist Before You Push to Production

Test Environment (Minimum Viable)

Validation Steps After Patching

Rollback Plan

ANZ Timezone Tracking: Your Patch Tuesday Week

Key Takeaways

FAQ

My Take

Further Reading

You might also like

Three claimed CISA KEV additions: the IT-pro verification and triage checklist

MFA Fatigue: Your 60-Minute IT-Pro Playbook

An Oracle EBS bug just cost Estee Lauder customer data