Phoenix SecureCore Technology 4 (boot splash screen image parsing): The firmware parses a user-supplied boot logo image

Impact

The firmware parses a user-supplied boot logo image without validating it, giving denial of service or arbitrary code execution in the DXE phase. This is the Phoenix instance of the wider image-parser problem in UEFI firmware: the logo is attacker-replaceable data sitting inside the firmware volume, parsed by privileged code long before Secure Boot has any say. For an operator the uncomfortable part is that a custom boot logo is a supported, documented OEM feature, so the write path exists by design.

Who can reach it

An attacker who can replace the boot logo image in the firmware volume - requiring firmware-write access from the OS (root plus a writable ESP or an unlocked SPI region), then a reboot.

What to do

OEM BIOS update on the fixed SecureCore Technology 4 build. Firmware flash, reboot per node. Config-side hardening that helps immediately: ensure the SPI flash and the logo storage region are write-protected at the platform level, and do not deploy custom OEM boot logos on nodes where that means leaving the region writable. Track this alongside the LogoFAIL family from other IBVs - the same image-parser class was found across Insyde, AMI and Phoenix, so a fleet with mixed OEMs needs all three checked.

References