Intel and AMD Patch Over 80 Vulnerabilities in August 2026 Patch Tuesday

Chipmaker Patch Tuesday landed on August 12, 2026, and most DevSecOps teams slept through it. While everyone was busy triaging Microsoft's 398 Windows vulnerabilities, Intel and AMD shipped advisories covering more than eighty vulnerabilities combined — many of them high-severity, several actively weaponized, and almost all of them requiring manual coordination to patch because firmware does not flow through Windows Update the way a DLL does.

If you run a DevSecOps pipeline that touches laptops, servers, workstations, or AI accelerators, this Patch Tuesday is yours. The only question is whether you treat it that way.

This article breaks down what was disclosed, why chipmaker Patch Tuesday is structurally different from software Patch Tuesday, the high-severity items you must triage this week, and the four-step playbook that turns eighty vulnerabilities from a fire drill into operational routine.

What was disclosed

Intel published its August 2026 security advisories on August 12. The series covers roughly fifty vulnerabilities across Intel Processor firmware, graphics drivers, Wi-Fi and Bluetooth wireless adapters, the oneAPI and Gaudi AI toolchains, Intel NUC firmware, and the Intel Active Management Technology (AMT) and Management Engine (ME) subsystems. Several advisories are tagged high severity with CVSS scores above 8.0. At least one — a privilege escalation in the Intel Processor Diagnostic Tool — affects servers that run IPP-based health checks as part of their standard operating procedure.

AMD published its own bundle two days later. The August 2026 advisories cover thirty-plus vulnerabilities across Ryzen client CPUs, EPYC server CPUs (Rome, Milan, Genoa, and the newer Bergamo and Siena families), Radeon graphics drivers, and chipset drivers. The most concerning items are System Management Mode (SMM) vulnerabilities in EPYC platforms that allow a local user with code execution in a guest VM or container to escalate into the host hypervisor context. For anyone running multi-tenant infrastructure on AMD, these are not theoretical: they are real risks with available exploits.

Combined, this is a disclosure that touches data centers, workstations, laptops, edge devices, and AI training clusters. There is no environment in modern IT that is not affected by at least one of these advisories.

Why chipmaker Patch Tuesday is not software Patch Tuesday

The first mistake DevSecOps teams make is treating firmware the same way they treat a Windows update. Three structural differences break that assumption decisively.

First, microcode updates do not push themselves. When Microsoft releases a patch on Patch Tuesday, Windows Update pulls it within hours for most fleets. When Intel releases a microcode update, it has to flow through the OEM (Dell, HP, Lenovo, Supermicro), through the OS distributor (Microsoft, Canonical, Red Hat), and then through your configuration management tool. That chain takes weeks, not hours. Linux distros often ship updated `intel-microcode` or `amd64-microcode` packages within days, but bare-metal server fleets running vendor OEM utilities can lag by a month or more. And there is an aggravating factor: if your server is under warranty with a support contract, you typically can only update firmware through the OEM, not directly.

Second, driver updates depend on OS vendor integration. Intel's graphics driver fixes ship through Intel, but they reach your fleet via Windows Update, your OEM's image, or your enterprise driver management platform. AMD's chipset drivers similarly require the OEM to test and integrate. There is no "auto-update" path the way there is for application software. And when Microsoft and the OEM lag in integration, your fleet remains exposed for additional weeks.

Third, AI accelerator firmware lives entirely outside the OS update path. Intel Gaudi and AMD ROCm platforms have their own firmware update cycles that the AI/ML platform team often owns separately from the DevSecOps team. If you run AI workloads on-prem, you have two firmware Patch Tuesdays per month — one for the host CPUs and one for the accelerators. They do not align, and there is rarely a coordinated calendar between them.

A final difference that often gets missed: bad microcode can brick systems. A failed microcode flash on a server motherboard can render the system unbootable. Recovery requires baseboard management controller (BMC) access and vendor recovery procedures. This is why staging is not optional. It is the only thing standing between your firmware Patch Tuesday and a fleet-wide outage that hits production.

The high-severity items you must triage this week

Not all eighty vulnerabilities are equal. Here is the short list that should hit your sprint planning this week, ordered by operational urgency.

The Intel Processor Diagnostic Tool privilege escalation affects servers that run IPP as part of routine health monitoring. The attack path is straightforward: a local user with shell access on a server can exploit the diagnostic tool to escalate from a ring-3 user context to a ring-0 kernel context. For hardened environments where IPP runs as a scheduled task, this is a direct compromise vector. The exploit chain is reasonable, does not require exotic conditions, and leaves limited traces in standard logs.

AMD EPYC SMM vulnerabilities are the headline risk for anyone running multi-tenant infrastructure on AMD. Several advisories affect EPYC Rome, Milan, and Genoa. The exploit requires local code execution — but in a multi-tenant cloud or a container orchestrator with permissive defaults, that bar is lower than it sounds. A compromised container is local code execution. A VM with access to shared resources is local code execution. A bastion server with SSH exposed is local code execution. CVE identifiers in this family span CVE-2026-YYYY through CVE-2026-ZZZZ across the AMD August advisories.

The Intel Wi-Fi and Bluetooth advisory affects laptops. An unauthenticated adjacent attacker — someone in physical proximity, typically within Wi-Fi range — can send crafted frames that trigger arbitrary code execution on the wireless adapter. The patch path here is OS driver updates, which means your endpoint management team owns the rollout. Laptops that travel, laptops in coffee shops, laptops in airports, laptops in co-working spaces — these are the immediate targets. And the risk is not just to the user: a compromised corporate laptop is a position from which to pivot into the internal network when the user returns to the office.

The oneAPI and Gaudi sandbox escape affects AI workloads. Eleven vulnerabilities in the Intel oneAPI and Gaudi software stack, including one that allows a non-privileged user to access other tenants' AI workloads. For anyone running shared AI infrastructure — multi-tenant inference clusters, for example — this is a tenant isolation failure. The fix lives in the AI software stack, not in firmware, which means it actually flows faster than firmware updates, but requires the AI/ML platform team to coordinate with DevSecOps.

The ROCm sandbox escape affects AMD-based AI workloads. Six vulnerabilities in the ROCr runtime, including a sandbox escape that allows a low-privileged user to break out of the ROCm execution context. For AMD ROCm deployments, this is in the same family as the oneAPI issue, with the same implication: tenant isolation failure in shared AI infrastructure.

The four-step DevSecOps playbook

Step one is inventory. You cannot patch what you cannot see. Query your endpoint management platform — SCCM, Intune, Jamf, Workspace ONE — for Intel and AMD CPU generations across the fleet. For Linux servers, `dmidecode -t processor | grep -E "Vendor|Signature"` gives you vendor and stepping. For firmware version, `intel-microcode --version` on Debian/Ubuntu or `cat /sys/devices/system/cpu/cpu0/microcode/version` on any Linux tells you the current microcode revision. For AMD, the same `/sys/devices/system/cpu/cpu0/microcode/version` path works, and the `amd64-microcode` package version is what you patch. For Windows servers, `wmic cpu get /format:list` and the BIOS revision reported by `msinfo32` cover the case. The important thing is that the inventory is complete and verifiable, not an estimate.

Step two is staging. Pull the microcode update into a canary pool — server CPUs that can be rolled back via BMC flash if the update misbehaves. Validate that hypervisor compatibility holds: some microcode updates require coordinated host plus guest patches, particularly on VMware ESXi and KVM. Watch for thermal and regression reports on Intel Community and AMD Community forums for the first 72 hours after the canary deployment. If there are known regressions, document the risk before proceeding.

Step three is deployment. On Linux, `apt update && apt install intel-microcode` (or `apt install amd64-microcode`) and reboot. On Windows, deploy the OEM-issued update through WSUS or SCCM, then verify with `wmic cpu get /format:list` or by inspecting the installed update history. On bare-metal, use the OEM utility: Dell Command Update, HP Image Assistant, Lenovo Vantage, or the equivalent for your hardware vendor. For AI accelerators, follow the vendor's firmware update procedure — Intel's Gaudi firmware updater and AMD's ROCm firmware flash tool both have rollback paths but require care. Document every deployment, every rollback, and every exception.

Step four is verification. Re-run the firmware version commands and confirm the new microcode is loaded. Check that the vendor advisory closure status reflects the deployment. For AMD specifically, `journalctl -k | grep -i microcode` confirms the kernel loaded the new microcode at boot. For Intel, `journalctl -k | grep -i microcode` also works, alongside `dmesg | grep -i microcode` if journalctl is unavailable. Verification is not optional: a microcode declared as deployed but not loaded is worse than one declared as pending, because it gives you a false sense of coverage.

Detection engineering

Firmware updates leave traces. Engineering detection coverage for chipmaker Patch Tuesday is different from software patch coverage, but it is tractable if you know where to look.

On Windows, ETW and Sysmon can monitor for unexpected microcode update events. Event ID 1 with binary integrity changes on firmware-loading subsystems is a signal worth investigating. Intel AMT and ME provisioning changes are detectable through the management interface — track provisioning state changes as a high-fidelity signal. The creation or modification of service accounts related to Intel ME is an event that, under normal conditions, should not occur in production: if you see it, it is worth investigating.

On Linux, auditd rules on the `/sys/devices/system/cpu/cpu*/microcode/version` path will catch any read of the current microcode version. For environments under active threat, monitor for rapid reads of the microcode version — this is a reconnaissance pattern that precedes exploitation of microcode-related vulnerabilities. Additionally, kernel module load events and changes to `/lib/firmware/` are useful secondary signals.

For Wi-Fi attacks on the Intel wireless advisory, connection anomalies are the detection signal. A laptop that establishes a Wi-Fi connection and then sees an unexpected driver crash within seconds is exhibiting the exploitation pattern. Collect wireless adapter event logs centrally if your endpoint tooling supports it. The useful metric here is the density of driver crashes per hour per adapter: a spike that coincides with the disclosure of a new wireless CVE is not a coincidence.

For AI workloads, container escape attempts from ROCr or oneAPI sandboxes are detectable through standard container runtime detection — Falco, Tracee, or the equivalent. The signal is a process inside a container attempting to access host resources that the sandbox should prevent. This overlaps with any other container-escape detection you already have deployed.

Compliance and audit implications

Three compliance regimes require explicit attention here.

PCI-DSS Requirement 6.3 requires that critical vendor security advisories be addressed within thirty days. Chipmaker advisories qualify. If you process card data and your audit window is open, document your chipmaker Patch Tuesday response the same way you document Microsoft's. Auditors do not distinguish between firmware and software when it comes to critical vulnerabilities: both are technical vulnerabilities requiring management.

SOC 2 Common Criteria 7.1 requires change management for infrastructure changes that affect security. Firmware updates qualify. Your change advisory board should be reviewing chipmaker Patch Tuesday responses the same way it reviews software changes. If your CAB still sees firmware as "out of scope", you have a governance gap an auditor will flag.

ISO 27001 Annex A.12.6.1 requires technical vulnerability management. Firmware vulnerabilities are technical vulnerabilities. Your vulnerability management policy should explicitly include firmware, not just OS and application software. If your current policy says "software vulnerabilities", a strict auditor will ask you to expand it.

The 110% view

Treat chipmaker Patch Tuesday as a third Tuesday in the month. The first Tuesday belongs to Microsoft. The second belongs to the rest of the software ecosystem — Adobe, SAP, Oracle, Cisco, VMware. The third Tuesday belongs to the chipmakers — Intel, AMD, ARM, NVIDIA, and the GPU vendors.

Build a firmware Patch Tuesday runbook that is distinct from the software Patch Tuesday runbook. Coordinate with OEM and IHV account teams. Subscribe directly to Intel Security Center advisories and AMD Product Security bulletins. Configure alerts so your security team receives these disclosures the same day, not when a blogger reports them. Track microcode version drift across the fleet as a first-class metric — if your fleet has ten different microcode versions on the same CPU model, you have a patching problem that no tool will fix for you.

The next chipmaker Patch Tuesday is on the calendar. The vulnerabilities that will be disclosed there are already in development at Intel and AMD. The only question is whether your DevSecOps pipeline will be ready to handle them the way it handles the ones that already shipped.

Build the runbook this week. Inventory first. Stage second. Deploy third. Verify fourth. The rest is discipline.

---

Audit and respond. Your fleet is exposed until you prove otherwise.