Microsoft’s August 2026 Patch Tuesday, released 11 August 2026, addresses 398 new CVEs.

The severity distribution:

  • 62 Critical
  • 336 Important
  • 1 Moderate

One vulnerability is under active attack: CVE-2026-68820, a Windows Ancillary Function Driver for WinSock elevation of privilege vulnerability, rated CVSS 7.0 and classified by Microsoft as Important.

No vulnerabilities were listed as publicly known at release time.

There is a documented oddity worth noting: Microsoft designated CVE-2026-68820 as actively exploited while rating its exploit code maturity as “Unproven” — a combination that is internally contradictory, since exploitation in the wild is by definition proof that exploit code exists. It is a metadata inconsistency, not a technical one, but it matters for anyone whose prioritisation tooling ingests exploitability ratings automatically.

This release follows July 2026’s record of more than 600 CVEs, which included three zero-days, two of them actively exploited. Taken together, the two months make an argument that vulnerability management programmes need to absorb.

The decoupling

Across July and August 2026, Microsoft patched roughly 1,000 CVEs. Across the same two months, the number confirmed as exploited in the wild at release was three.

That is an exploitation rate of approximately 0.3 percent.

Meanwhile, the vulnerabilities that actually caused compromises in this period were largely not Microsoft CVEs at all. In the past two weeks alone:

  • CVE-2026-9198 in IBM Langflow — a CVSS 9.8 unauthenticated RCE, exploited from 6 July with 650 attempts from 244 addresses before it reached the KEV catalog on 4 August.
  • CVE-2026-18577 in N-able N-central — exploited on the day of disclosure to deploy StormEncryptor ransomware.
  • CVE-2026-34486 in Apache Tomcat — added to KEV in the same batch.

The pattern is unambiguous. Volume is concentrated in the operating system. Exploitation is concentrated in internet-exposed third-party infrastructure.

A patch management programme that consumes its entire capacity working through 398 Microsoft CVEs by severity rating is spending that capacity on the population least likely to be exploited, while the internet-facing management platform, the AI orchestration tool, and the embedded application server wait in a queue.

Why severity-based SLAs stopped working

The conventional programme is built on a severity-driven SLA: Critical within 15 days, High within 30, Medium within 90, and so on. It is encoded in policy, tested by auditors, and reported to boards as a percentage-within-SLA metric.

At the volumes now shipping, that model breaks in three specific ways.

It is arithmetically unachievable. Sixty-two Critical CVEs in a single month, on top of the previous month’s backlog, on top of every non-Microsoft product in the estate, exceeds the testing and change-control throughput of most enterprises. Microsoft’s own guidance suggests a three-day turnaround; as Ivanti’s Todd Schell put it in the pre-release forecast, large enterprises are constrained by testing, change control, and compatibility requirements that make three days unattainable. Programmes respond by silently deprioritising, which converts a policy into a fiction and leaves the deprioritisation decisions undocumented.

Severity is not exploitability. CVE-2026-68820 — the one bug under active attack this month — is rated Important, not Critical, with a CVSS of 7.0. Under a severity-driven SLA it sits in the 30-day queue behind 62 Critical vulnerabilities that nobody is exploiting. The single most urgent patch in the release is not the most urgent patch by the metric that drives the process.

It ignores exposure. A Critical RCE in a component that is not installed, not enabled, or not reachable is not a risk. An Important elevation of privilege on an internet-facing server that an attacker already has a foothold on is. Severity ratings are properties of the vulnerability; risk is a property of the vulnerability in your environment.

The model that replaces it

The alternative is not “patch less.” It is to make prioritisation reflect the two variables that actually determine risk — evidence of exploitation and exposure — and to accept that the remainder is a systematic background process rather than an emergency.

The tiering that works:

Tier 1 — Known exploited, internet-facing. CISA KEV entries, vendor-confirmed in-the-wild exploitation, and credible exploitation telemetry, on assets reachable from the internet. Emergency change authority, hours not days, minimal testing. This tier is small enough to be achievable and is where essentially all real-world compromise originates. CVE-2026-68820 belongs here for any internet-facing Windows host.

Tier 2 — Known exploited, internal. Same evidence, less exposure. Days, standard emergency process.

Tier 3 — Not known exploited, internet-facing, high impact. Pre-auth RCE and authentication bypass on exposed assets. These are the ones that become Tier 1 next week. Prioritise by attack path, not CVSS.

Tier 4 — Everything else. Systematic ring deployment on a monthly cadence. This is where the 336 Important CVEs live, and treating them as a monthly batch rather than 336 individual decisions is the only tractable approach.

This is the model CISA’s BOD 26-04 encodes for federal agencies — prioritised remediation of KEV entries on publicly exposed assets granting total control post-exploitation — and which we examined when the 7 August deadline landed alongside Fortinet and Arista entries. The directive is not a federal peculiarity. It is the reference implementation of risk-based prioritisation, published by the organisation with the best available exploitation telemetry.

The compliance problem this creates

Here is the difficulty, and it needs to be handled deliberately rather than discovered during an audit.

Most control frameworks still express patching requirements in severity terms.

  • PCI DSS v4.0.1 Requirement 6.3.3 requires critical and high-security patches within one month of release, with others within an appropriate timeframe.
  • NIST SP 800-53 SI-2 requires remediation within organisation-defined time periods, typically instantiated by severity.
  • ISO/IEC 27001:2022 Annex A 8.8 requires timely action on technical vulnerabilities without prescribing a model.
  • HIPAA Security Rule requires a risk-based approach through the risk analysis and risk management standards, which is actually the most accommodating of the four.
  • CMMC / NIST SP 800-171 requires remediation of flaws in accordance with the assessment of risk.

An organisation that moves to exploitation-and-exposure prioritisation will, by design, exceed a 30-day window on some Critical-rated CVEs. That is a defensible decision and a finding waiting to happen, depending entirely on whether the decision was documented.

What makes it defensible:

  1. Write the risk-based methodology into policy. The prioritisation model, the tiering criteria, the data sources (KEV, EPSS, vendor advisories, exposure data), and the approval authority should be documented before it is applied — not reverse-engineered when an auditor asks why a Critical CVE sat for 60 days.

  2. Keep severity SLAs where frameworks require them, and layer risk-based acceleration on top. The PCI requirement applies to the cardholder data environment. Meeting it there and applying risk-based prioritisation across the wider estate is coherent; abandoning it entirely is not.

  3. Document the exposure determination. “Not internet-facing” is a claim that requires evidence — external attack surface scan results, network policy, segmentation validation. This is the artefact that converts a deprioritisation from a judgement into a control.

  4. Report exploitation-weighted metrics to the board. “Percentage of KEV entries remediated within SLA” and “mean time to remediate exploited vulnerabilities on internet-facing assets” describe risk. “Percentage of Critical patches within 30 days” describes workload.

  5. Maintain a documented exception process with expiry dates. Every deprioritised Critical needs an owner, a compensating control, and a review date.

  6. Include the third-party estate. The reason this month’s exploitation happened outside Microsoft’s product line is that the internet-facing third-party estate is where attackers concentrate. A vulnerability management programme scoped to operating systems and major applications is scoped to the wrong population.

What to do with this release

Concretely, for the August 2026 cycle:

  • CVE-2026-68820 — deploy immediately to internet-facing Windows hosts and to any system where an initial foothold would be consequential. AFD for WinSock elevation of privilege is a post-exploitation privilege escalation, which makes it the second half of an intrusion chain rather than the entry point. Its value to an attacker is precisely that it converts a limited foothold into SYSTEM.
  • The 62 Critical entries — triage by exposure and by whether the affected component is present and enabled. The subset that is both internet-reachable and pre-auth is the real Tier 3 list, and it will be considerably shorter than 62.
  • The remaining 336 — standard ring deployment on the monthly cycle.
  • Do not let the Microsoft cycle consume the third-party queue. The KEV entries from the first week of August — Langflow, N-central, Tomcat — are where exploitation actually occurred, and Patch Tuesday week is exactly when they get crowded out.

The structural observation

The rise in CVE volume is widely attributed to AI-assisted vulnerability discovery, and that attribution appears sound: automated analysis is finding bugs faster than any prior method, and the curve has not flattened.

What has not risen proportionally is exploitation. Attackers remain economically rational. They exploit what is reachable, what yields access to many targets at once, and what has a working exploit — which is why an authentication bypass in an MSP platform is worth more to them than sixty memory-safety issues in a subsystem that requires local access.

Two things follow. For vulnerability management programmes: your patch capacity is finite and your CVE inflow is not, so prioritisation is now the entire discipline — and prioritisation by vendor-assigned severity systematically misallocates that capacity away from where compromise actually happens.

For compliance functions: the shift to risk-based prioritisation is correct and will generate findings unless you document it first. The methodology, the exposure evidence, and the exception register are what separate a defensible risk decision from an unremediated Critical vulnerability with no explanation attached.

This article is provided for informational purposes only and does not constitute legal advice.