// 2 CRITICAL · 4 ZERO-DAY · 6 CVE · 2 EXPLOIT · 1 ADVISORY IN THE LAST 24H
On May 13, 2026, Intel and AMD released 28 advisories covering 69 vulnerabilities. Two critical flaws hit chip software drivers, not the silicon itself.

On May 13, 2026, Intel and AMD released 13 and 15 security advisories respectively, totaling 28 documents covering nearly 70 vulnerabilities across their ecosystems. The silicon isn't cracking; it's the virtualization drivers, GPU monitoring tools, and UEFI firmware expanding the attack surface beyond the die. Two flaws carry CVSS scores of 9.3 and 9.2, both in the software wrapping the chips, not in the core microarchitecture.

Key Takeaways
  • Intel published 13 advisories for 24 vulnerabilities, including 1 critical and 8 high-severity; AMD published 15 for 45 flaws, with 1 critical and 24 high-severity.
  • CVE-2026-20794 (CVSS 9.3): Buffer overflow in Intel's Data Center Graphics Driver for VMware ESXi, enabling privilege escalation and potential code execution.
  • CVE-2026-0481 (CVSS 9.2): AMD's Device Metrics Exporter in the ROCm ecosystem binds port 50061 to all network interfaces, allowing unauthenticated remote access to the GPU control gRPC server.
  • The remaining flaws hit UEFI firmware, Ethernet drivers, endpoint management tools, Secure Processor, RAID drivers, and EPYC platforms: the pattern is growing software complexity around the silicon.

The Two Criticals: When the Driver Becomes the Perimeter

CVE-2026-20794, rated CVSS 9.3 per the source, affects Intel's Data Center Graphics Driver for the VMware ESXi environment. The mechanism is a buffer overflow: an attacker with system access can trigger privilege escalation and, potentially, code execution. The source uses the verb "potentially" regarding code execution, indicating exploit practicality is not documented as a certainty.

CVE-2026-0481, rated CVSS 9.2, hits the AMD Device Metrics Exporter in the ROCm ecosystem. The defect lies in the IP binding address: the gRPC service named GPU-Agent binds to 0.0.0.0, making port 50061 reachable on every network interface without authentication. The source states verbatim that a remote attacker can modify GPU configuration, causing loss of availability.

"Unrestricted IP address binding in the AMD Device Metrics Exporter (ROCm ecosystem) could allow a remote attacker to perform unauthorized changes to the GPU configuration, potentially resulting in loss of availability" — AMD, cited by SecurityWeek

Map of 69 Flaws: Intel Focuses on Virtualization and Firmware

Beyond the ESXi critical, Intel patched 8 high-severity vulnerabilities per the article. Affected products include Vision software, Endpoint Management Assistant (EMA), UEFI Slim Bootloader firmware, QuickAssist Technology (QAT) drivers for Windows. The remaining medium-severity flaws touch AI Playground, the Windows Display Virtualization driver, the 800 Series Ethernet driver for Linux, NPU drivers, other UEFI firmware segments, the Server Firmware Update Utility, additional QAT Windows drivers, and some processor families.

The pattern is recurring: every accelerated function — graphics, networking, AI inference, cryptography — requires an accompanying software layer. That layer, not the silicon, accumulates security technical debt.

AMD: 45 Flaws and the Recurrence of Open Binding by Default

AMD issued 15 advisories for 45 vulnerabilities, including 24 high-severity beyond the ROCm critical. The attack surface is cross-cutting: Secure Processor (ASP), GPIO controllers, Revenera InstallShield, Ionic cloud driver for ESXi, RAID drivers, chipset drivers, Zen 2 CPU operation cache, graphics and datacenter products, EPYC and EPYC Embedded platforms.

The ROCm case reprises a classic pattern in hardware management software: a diagnostic or monitoring service is exposed on the network with permissive binding and no mandatory authentication. The difference from the past is the deployment context: AMD GPUs in ROCm configurations are increasingly present in AI/HPC clusters, where compromising the availability of a single GPU node jeopardizes the entire training or inference job.

Why It Matters

The brief does not document specific remediation measures or patched versions for each product. The source does not specify whether the vulnerabilities are actively exploited, nor does it provide a responsible disclosure timeline for individual CVEs. It is unclear whether Intel and AMD released advisories on the same day for coordination or by coincidence on the Patch Tuesday calendar.

The count of 70 total vulnerabilities is an editorial rounding: 24 plus 45 equals 69. The source does not provide direct access to the 28 original advisories, limiting independent verification of technical details.

No infrastructure overlaps or attributions to specific threat actors emerge in the current dossier. Motive remains undeclared: targets suggest interest in virtualized environments and AI clusters, but this is an editorial reading, not a fact confirmed by the source.

The structural datum that holds is convergence: the security perimeter of computing is no longer just the silicon. GPU virtualization drivers, ROCm ecosystem monitoring tools, and UEFI firmware have become critical supply-chain layers, with direct network exposure and impact on AI infrastructure availability.

Questions and Answers

Do the flaws hit the silicon of Intel and AMD processors?
No. According to the source, the vulnerabilities reside in the software, drivers, and firmware accompanying the chips, not in the core microarchitecture.

What is the technical difference between the two CVSS 9+ criticals?
CVE-2026-20794 (Intel) requires system access for privilege escalation; CVE-2026-0481 (AMD) is remotely reachable via network without authentication, with impact on GPU availability.

Is exploit practicality confirmed for CVE-2026-20794?
The source reports "potentially" code execution: the dossier does not document whether the flaw is exploitable in real-world conditions or only theoretically.

Sources

Information is based on the cited source and current as of publication.

Sources


Sources and references
  1. securityweek.com