Intel AMT and Intel Standard Manageability firmware (current CSME generations): Out-of-bounds write in AMT/ISM firmware

CVSS 8.6CVE-2025-32008Firmware, BMC & network fabricINTEL-SA-01315CVE-2025-20080CVE-2026-20715INTEL-SA-01427curated

Impact

Out-of-bounds write in AMT/ISM firmware reachable by an unauthenticated network adversary, with a companion null-pointer dereference in the same advisory and a further unauthenticated network denial-of-service in the August 2026 batch. The immediate effect is that anyone on the management path can knock the manageability engine of a node over; memory corruption in the ME is also the standard precursor to code execution in it. The operator-facing point is that AMT is still, in 2026, an unauthenticated network attack surface on the management VLAN - and losing the ME on a node loses your out-of-band recovery path exactly when you need it.

Who can reach it

Network adversary, unauthenticated, reaching the AMT/ISM listener on the node. Same exposure as the 2017-era AMT bugs: management VLAN, or tenant space if the manageability path is not fully isolated.

What to do

CSME firmware flash from the OEM (Dell, HPE, Supermicro, Lenovo, Gigabyte, Quanta) with a host reboot and job drain. The lasting control is the same one operators keep skipping: unprovision AMT on every SKU where you do not actively use it, disable it in the BIOS profile, and block 16992/16993/623/664/5900 anywhere a tenant-reachable segment could touch it. If you do use AMT, put it behind TLS with mutual auth and a dedicated segment.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-32008 https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01315.html https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01427.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.