UEFI firmware SMM modules in Intel reference platform firmware (SMM handler, FlashUcAcmSmm, ImcErrorHandler, WheaERST

CVSS 8.7CVE-2025-20105Firmware, BMC & network fabricINTEL-SA-01234CVE-2025-20064CVE-2025-20068CVE-2025-20027curated

Impact

Improper input validation in SMM modules that Intel ships as reference code and that OEMs build into their server BIOS. SMM is the most privileged execution mode on the platform - above the hypervisor - so an escalation here gives an attacker control of the platform beneath every isolation boundary the fleet relies on, including access to the SPI flash write path. The result is a firmware implant that survives reimage and crosses tenant handoff, and that can neutralise measured boot from underneath. Because this is Intel reference code, the same defect propagates identically across every OEM that consumed that code drop, so exposure is fleet-wide across mixed vendors rather than isolated to one supplier.

Who can reach it

A privileged local user on the host - local root or an existing kernel foothold triggering the SMI. On bare-metal GPU nodes, that is the tenant.

What to do

BIOS update from each OEM once they pick up Intel's fixed reference code - Dell, HPE, Supermicro, Lenovo, Gigabyte, Quanta and Wiwynn all ship independently, and for reference-code advisories the lag from Intel's disclosure to a shipped server BIOS routinely runs one to two quarters, longer for ODM whitebox. Requires host reboot and job drain. Track this by OEM BIOS version rather than by CVE, because OEM release notes often reference only their own advisory ID. No runtime mitigation exists for SMM defects.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-20105 https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01234.html

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.