MediaTek Chipset CVE-2026-20451

Exploitation requires the attacker to already possess System privilege (UID 0 or equivalent root access) on the device. The vulnerability cannot be exploited from unprivileged contexts, user space without elevation, or remote network access. Additionally, the attacker must have the ability to execute code in the context where slbc is invoked - typically a privileged system service, SELinux domain, or kernel module initialization. The vulnerability is not triggered by default user interactions; the malicious code must explicitly call the vulnerable slbc function with a crafted input that triggers type confusion. This means either the attacker has already compromised the device and obtained root, or the vulnerability is chained after another privilege escalation. No special chipset configuration is required; all 32 affected MediaTek chipset models in their standard deployments are vulnerable.

Risk assessment reveals conflicting signals: CVSS score of 6.7 indicates medium-high severity with confidentiality, integrity, and availability impact (C:H/I:H/A:H), but the real-world exploitation probability is dramatically lower. EPSS of 0.02% (5th percentile) indicates minimal exploitation likelihood, and CISA SSVC explicitly rates exploitation status as 'none' - no public exploits or confirmed active exploitation. The determining risk factors are the attack vector (local-only) and high privilege requirement (System privilege - effectively root): an attacker must already control the device at the highest privilege level to exploit this, making it a privilege-boundary issue rather than an entry vector. The 'no' automatable rating from SSVC confirms exploitation requires manual action and cannot be weaponized at scale. This is a real but contained risk: dangerous for a malicious insider with System access or as a post-exploitation lateral-movement tool, but not a primary attack entry point. The widespread chipset coverage (32 models) increases aggregate exposure across Android and IoT ecosystems that use these chipsets.

A malicious application or compromised system service running with System privilege (UID 0 or equivalent) triggers the type confusion vulnerability in slbc by passing a specially crafted buffer reference. The type confusion causes slbc to interpret the data type incorrectly, writing out-of-bounds into adjacent memory regions. The attacker overwrites sensitive kernel data structures or chipset firmware state, gaining execution control and escalating from System privilege to complete chipset-level compromise. This could allow the attacker to bypass security policies, access encryption keys, or persist across device reboots by modifying secure storage regions.