MediaTek vdec CVE-2026-20502

Exploitation requires the attacker to execute local code on the target device - specifically, an installed process capable of invoking the MediaTek vdec driver interface through media APIs. Because the CVSS vector specifies PR:N alongside AV:L, no special Android permissions or elevated privileges beyond ordinary app execution are required; a standard unprivileged app context is sufficient to reach the vulnerable code path. The attack is strictly local (AV:L): remote exploitation is not possible without first achieving separate code execution on the device via another vulnerability. No user interaction is required once the malicious payload is running on the device. Per SSVC, the attack is not automatable due to the local-access prerequisite. The flaw is present across all software versions shipping the unpatched vdec component on the 53 listed chipset SKUs, with no specific non-default configuration required to expose the vulnerable code path.

The CVSS 8.4 vector (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) captures the core risk accurately: local access required, low complexity, no privileges, no interaction, with full confidentiality, integrity, and availability impact - scope-unchanged prevents a Critical rating. SSVC signals exploitation status as 'none' and automatable as 'no,' aligning with the absence of any CISA KEV listing or known proof-of-concept code, though technical impact is rated 'total.' The PR:N with AV:L combination is notable: in Android and similar embedded stacks, vdec is reachable by ordinary app processes without elevated permissions, meaning any installed malicious application on an affected device constitutes a viable attack path. No EPSS score was provided in the input data, limiting probabilistic exploitation forecasting. Even a mid-sized municipal IT team in walbrzych managing a fleet of MediaTek-based Android handsets should treat this as urgent given the breadth - 53 chipset SKUs spanning a substantial portion of global budget and mid-range device shipments. The primary long-term concern is the delayed patch propagation pipeline: MediaTek distributes fixes to OEMs, who must then build and push OS updates to end users, a process that can take months and often never reaches older devices.

An attacker distributes a malicious Android application - perhaps disguised as a media player or codec tool - that, once installed on a device containing an affected MediaTek chipset, submits crafted inputs to the vdec kernel driver via the platform media framework. The malformed request triggers the missing bounds check, causing a heap out-of-bounds write that corrupts adjacent kernel data structures, allowing the attacker to redirect kernel execution and escalate to root. No public proof-of-concept has been identified at time of analysis, but the technique is well-established in the mobile kernel exploitation literature for similar video-driver heap overflow vulnerabilities.