The immediate priority is not every Intel PC. The highest-impact fixes target servers running hypervisors, Intel Trust Domain Extensions (TDX), and newer Xeon platforms, while a smaller set reaches certain 10th- and 11th-generation Core systems. More importantly, Intel issued a follow-up package on August 12 that removed one Meteor Lake microcode image after observing functional issues on some platforms. That makes validation and vendor-specific BIOS release notes more important than simply installing the first firmware build that appears.
Phoronix first reported that Intel’s microcode-20260811 release addresses eight security issues and also adds initial microcode images for Bartlett Lake and Wildcat Lake. Intel’s published release record confirms eight security advisory numbers, plus a long list of functional fixes and newly supported processor entries.
Eight Intel advisories actually contain nine CVEs
“Eight security issues” is accurate only when counting Intel advisory numbers. Intel’s August 11 release notes list eight advisories: INTEL-SA-01379, INTEL-SA-01404, INTEL-SA-01423, INTEL-SA-01428, INTEL-SA-01435, INTEL-SA-01441, INTEL-SA-01442, and INTEL-SA-01443.
But INTEL-SA-01442 contains two separate CVEs: CVE-2026-20713 and CVE-2026-20901. In practical terms, the release addresses nine CVE records across eight advisories, not eight individual vulnerabilities. That distinction matters to vulnerability-management teams matching scanner output and exception records against Intel’s bulletin set.
Intel rates two of the advisory groups High severity. INTEL-SA-01379, CVE-2025-31936, is a 7.0 CVSS 4.0 escalation-of-privilege issue involving overlap between protected memory ranges on some Xeon 6 processors using Intel TDX within System Management Mode. INTEL-SA-01435, CVE-2026-20716, is a 7.2-rated privilege-escalation flaw described as improper access control in Ring 3 user applications on Xeon 6 platforms.
The remaining advisories are rated Medium, though “Medium” should not be casually dismissed in a shared infrastructure environment. Most require local access, authenticated access, elevated privileges, specific attack conditions, or substantial technical knowledge. Several of the flaws live at the boundary between guest, hypervisor, kernel, firmware, and trusted-execution features—the places where multi-tenant server operators have the least room for ambiguity.
The Windows exposure is narrower, but not zero
For conventional Windows desktops and laptops, the most relevant August advisory is INTEL-SA-01423, CVE-2026-20917. Intel describes it as an information-disclosure issue caused by incorrect data forwarding during transient execution in Ring 0—the kernel and hypervisor privilege layer. The affected product list includes certain 10th Generation Core mobile processors, 11th Generation Core processors, 3rd Generation Xeon Scalable systems, Xeon D hardware, and Xeon E-2300 systems.
This is not evidence that any Windows 10 or Windows 11 machine with an Intel sticker is vulnerable. Intel’s affected-product table is tied to CPU IDs and platform IDs, not broad marketing generations. A 10th-generation Core device is in scope only where it matches the listed processor family and platform identification. Administrators need a hardware inventory and the OEM’s firmware advisory, not a blanket response based on a laptop’s launch year.
INTEL-SA-01428 has broader client relevance. It covers privilege escalation on Meteor Lake, Arrow Lake, Lunar Lake, Panther Lake, and specified Xeon 6 systems. Intel’s advisory lists Core Ultra Series 1, Series 2, and Series 3 processors, but its stated attack conditions still require local access and an authenticated attacker with privileged-user access. The fix is worthwhile, particularly on managed endpoints with developers, local administrators, virtualization tooling, or sensitive workloads, yet it is not an emergency patch for an otherwise isolated consumer PC.
INTEL-SA-01441 is a denial-of-service advisory affecting specific Core Ultra Series 2 and Series 3 mobile designs—Lunar Lake, Arrow Lake, and Panther Lake—as well as certain platform IDs. It is another reason that fleets moving to newer Core Ultra hardware should establish a repeatable UEFI update process rather than treating BIOS updates as one-off break/fix work.
Xeon, TDX, and virtualization are the real operational priority
The risk is concentrated more heavily in server deployments. Intel’s INTEL-SA-01379 and INTEL-SA-01404 both concern Xeon 6 processors running Intel TDX. The latter, CVE-2025-31938, is an information-disclosure flaw tied to insufficiently granular access control and carries a 4.3 CVSS score. Intel says a Trusted Computing Base recovery is planned for that issue, meaning applying the released microcode should not be treated as the final lifecycle step for TDX environments.
For an operator using confidential VMs or building a cloud service around TDX, that planned recovery is material. Microcode changes CPU behavior, but trusted-execution services also depend on attestation state, firmware versioning, platform configuration, and the Trusted Computing Base tracked by the surrounding stack. Intel has not published the timing or implementation details of the promised recovery in the August 11 advisory. Teams should therefore identify affected Xeon 6 hosts now, apply the vendor firmware when available, and watch for Intel’s subsequent TDX recovery guidance before declaring those hosts fully remediated.
INTEL-SA-01442 spans an unusually wide Xeon range: 4th Generation Xeon Scalable, Xeon W-2400 and W-3400 workstations, 5th Generation Xeon Scalable, and multiple Xeon 6 families. One CVE concerns incorrect control flow in firmware; the other concerns input validation. Meanwhile, INTEL-SA-01443 affects 3rd Generation Xeon Scalable and Xeon D systems, where Intel says an unprivileged Ring 3 attacker could trigger a denial of service through a hardware-logic race condition.
This creates a practical patching split. Newer Xeon 6 systems need attention because of the TDX and firmware privilege-escalation advisories, while older Ice Lake-era server estates should not be overlooked: they appear in both the August security list and the broader functional-update list.
Intel withdrew a Meteor Lake image one day later
The August 11 package was not left untouched. On August 12, Intel published microcode-20260812, whose only release-note entry says it removed the MTL/06-aa-04/c0 microcode image because functional issues were observed when loading it on some platforms.
That follow-up does not identify the symptom, the affected OEM devices, the number of systems involved, or whether the problem is related to a particular security advisory. It also does not say when a corrected Meteor Lake image will return. Intel’s August 11 release had listed an updated Meteor Lake C0 entry, moving microcode from revision 0x28 to 0x2A; the next day’s removal shows why the revision number alone is not a safe deployment target.
The immediate consequence is straightforward: do not manually force the August 11 Meteor Lake microcode payload onto Windows machines. The public Intel repository is designed for Linux distribution integration, and Intel states that BIOS is the preferred application route. Windows administrators should wait for a firmware package from Dell, HP, Lenovo, Microsoft Surface, ASUS, Acer, or the relevant device maker, then check whether its release notes identify the included Intel microcode revision and whether the vendor has absorbed Intel’s August 12 removal.
This also undercuts a common but risky response to CPU advisories: searching GitHub for a microcode binary and attempting to transplant it into a Windows environment. That bypasses the platform vendor’s BIOS validation, board-specific initialization, rollback protections, and release gating. It may also leave the system running a microcode revision Intel has already pulled.
What administrators should do now
For Windows endpoint teams, the response should be measured and documented rather than improvised:
- Inventory Intel systems by exact processor family, CPU ID where your management tools expose it, device model, current BIOS/UEFI version, and hypervisor role.
- Prioritize Xeon 6 servers running TDX, virtualized workloads, or multi-tenant services; then assess affected 3rd through 5th Generation Xeon deployments and Core Ultra fleets.
- Obtain updates through the OEM’s firmware channel or enterprise tools such as Dell Command, HP Image Assistant, Lenovo System Update, or the vendor’s managed update catalog.
- Read the OEM release notes for the Intel microcode revision rather than assuming a BIOS package incorporates the August 2026 release.
- Test firmware on representative hardware before broad deployment, especially Meteor Lake systems, because Intel has already withdrawn one August image for functional reasons.
- Plan reboot windows. A BIOS-delivered microcode update takes effect through the platform boot process, and production hosts may need coordinated maintenance, capacity migration, and post-update health checks.
- Track INTEL-SA-01404 separately in TDX environments because Intel says a TCB recovery remains forthcoming.
Intel’s August release is a substantial patch set, but its practical message for Windows shops is more specific than “install the latest microcode.” Patch the systems Intel identifies, obtain the firmware from the system vendor, and do not deploy the withdrawn Meteor Lake payload while Intel and OEMs sort out the functional regression.
