MediaTek Chipset Vulnerabilities: CVE-2024-20104 & 20106

MediaTek Chipset Vulnerabilities: How CVE-2024-20104 and CVE-2024-20106 Enable Privilege Escalation

Two high-severity MediaTek chipset vulnerabilities disclosed in November 2024 can allow local privilege escalation on affected devices.

The flaws, tracked as CVE-2024-20104 and CVE-2024-20106, affect different MediaTek components and have different exploitation requirements. CVE-2024-20104 affects the DA component and requires user interaction. CVE-2024-20106 affects the m4u component and does not require user interaction, but an attacker must already have System-level execution privileges. MediaTek classified both vulnerabilities as High severity.

That distinction matters. These are serious vulnerabilities, but neither should automatically be described as a remote, zero-click takeover of an otherwise uncompromised smartphone.

For security teams monitoring new mobile weaknesses, combining vendor advisories with broader cyber threat intelligence helps separate confirmed technical risk from exaggerated headlines.

Key Findings

• MediaTek publicly disclosed CVE-2024-20104 and CVE-2024-20106 in its November 4, 2024 security bulletin.
• Both are Elevation of Privilege (EoP) vulnerabilities.
• CVE-2024-20104 is an out-of-bounds write in the DA component.
• Exploiting CVE-2024-20104 requires user interaction but does not require additional execution privileges.
• CVE-2024-20106 is classified as a type-confusion issue in the m4u component.
• CVE-2024-20106 requires an attacker to already hold System execution privileges, but no additional user interaction is required.
• MediaTek lists Android 12.0, 13.0, 14.0, and 15.0 among affected software for both vulnerabilities.
• CVE-2024-20104 also affects specified OpenWRT, Yocto, and RDK-B versions.
• Android's November 2024 bulletin states that a 2024-11-05 security patch level or later addresses all issues associated with that bulletin.
• MediaTek's bulletin does not establish an exact number of affected smartphones or users, so claims that a specific number of devices were exposed should be treated cautiously.

What Are the MediaTek Chipset Vulnerabilities?

The two vulnerabilities are memory-safety problems affecting low-level MediaTek components.

At a practical level, successful exploitation could allow an attacker who meets the required conditions to move beyond their current level of access and gain more powerful privileges on the affected device.

That is known as privilege escalation.

Privilege escalation matters because Android normally separates applications and system components using permissions and security boundaries. A flaw that allows an attacker to cross one of those boundaries can make an existing compromise significantly more dangerous.

However, privilege escalation is not automatically the same as remote compromise. The attacker's starting position and the required interaction differ significantly between these two CVEs.

CVE-2024-20104: Out-of-Bounds Write in the DA Component

CVE-2024-20104 is an out-of-bounds write vulnerability affecting MediaTek's DA component.

MediaTek identifies it as CWE-787: Out-of-bounds Write.

An out-of-bounds write occurs when software writes data outside the section of memory it was supposed to use. In security-sensitive code, inadequate bounds checking can corrupt nearby memory and potentially alter program behavior.

MediaTek states that CVE-2024-20104 could result in local escalation of privilege with no additional execution privileges needed. However, user interaction is required for exploitation.

That means an attacker cannot accurately be described as remotely taking full control of any affected phone simply by knowing the device exists.

Some interaction or another part of an attack chain would still be necessary.

Chipsets Listed for CVE-2024-20104

MediaTek lists the following affected chipsets:

MT6781, MT6789, MT6835, MT6855, MT6878, MT6879, MT6880, MT6886, MT6890, MT6895, MT6897, MT6980, MT6983, MT6985, MT6989, MT6990, MT8188, MT8370, MT8390, MT8676.

Affected software versions listed by MediaTek include:

Platform	Listed affected versions
Android	12.0, 13.0, 14.0, 15.0
OpenWRT	19.07, 21.02, 23.05
Yocto	4.0
RDK-B	22Q3, 24Q1

 

This wider platform list is important because CVE-2024-20104 should not be treated purely as a smartphone issue.

CVE-2024-20106: Type Confusion in the m4u Component

CVE-2024-20106 affects MediaTek's m4u component.

MediaTek labels the weakness CWE-843: Type Confusion. Its technical description also identifies a possible out-of-bounds write caused by a missing bounds check.

Type confusion happens when software handles one type of data or object as though it were another. At a low level, that mistake can cause the program to interpret memory incorrectly and create unsafe behavior.

There is an important exploitation condition that should not be overlooked.

MediaTek says exploitation could produce local privilege escalation if the malicious actor has already obtained System privilege. User interaction is not required at that stage.

No User Interaction Does Not Mean a Remote Zero-Click Attack

This is one of the most important details of CVE-2024-20106.

"No user interaction required" describes only one part of the exploitation conditions.

It does not mean an unauthenticated attacker anywhere on the internet can silently compromise an otherwise clean phone.

For CVE-2024-20106, MediaTek specifically states that System execution privileges are required. The attacker therefore needs an already elevated position or another step in an attack chain before this vulnerability becomes useful.

That makes it potentially valuable for chaining with another vulnerability, but it should not be described as a standalone zero-click remote takeover based on the available official information.

Chipsets Listed for CVE-2024-20106

MediaTek identifies:

MT6739, MT6761, MT6765, MT6768, MT6779, MT6785, MT6853, MT6873, MT6885, MT8666, MT8667, MT8673, MT8678.

The listed affected software versions are:

Android 12.0, 13.0, 14.0, and 15.0.

CVE-2024-20104 vs CVE-2024-20106

Detail	CVE-2024-20104	CVE-2024-20106
MediaTek severity	High	High
Component	DA	m4u
Weakness	Out-of-bounds write	Type confusion
CWE	CWE-787	CWE-843
Main impact	Local privilege escalation	Local privilege escalation
Existing execution privilege required	No additional privilege required	System privilege required
User interaction	Required	Not required
Android versions listed	12, 13, 14, 15	12, 13, 14, 15
Other affected platforms listed	OpenWRT, Yocto, RDK-B	None listed in this bulletin

 

The table shows why the two vulnerabilities should not be discussed as though they have identical attack paths.

CVE-2024-20104 has a lower initial privilege requirement but needs user interaction. CVE-2024-20106 removes the interaction requirement but starts from a much stronger attacker position.

What Could Privilege Escalation Mean for an Android Device?

Android relies heavily on privilege separation.

A normal application should only be able to access the resources and permissions assigned to it. Sensitive operations are protected behind stronger system privileges.

If an attacker successfully escalates privileges, the practical consequences depend on exactly what level of access is gained and what other protections remain in place.

Potential consequences of a successful attack chain can include unauthorized access to protected resources, interference with system processes, or additional control over device functionality.

However, the official MediaTek advisory does not establish that every affected device can be exploited to steal banking data, messages, passwords, or other specific information.

Those outcomes depend on the complete attack chain.

For organizations managing mobile devices, the more useful response is to identify vulnerable assets and track remediation through a structured vulnerability management process rather than assuming every high-severity CVE produces the same business impact.

Were These MediaTek Vulnerabilities Actively Exploited?

The official material reviewed for this update does not provide enough evidence to claim that CVE-2024-20104 or CVE-2024-20106 was being actively exploited in the wild.

The November 2024 Android Security Bulletin did warn of indications of limited, targeted exploitation for CVE-2024-43047, a different vulnerability. It did not attach that warning to these two MediaTek CVEs.

That does not prove CVE-2024-20104 and CVE-2024-20106 have never been exploited.

It simply means we should not state active exploitation as a confirmed fact without stronger evidence.

How Were the Vulnerabilities Patched?

MediaTek says device OEMs were notified about the issues and corresponding security patches at least two months before its November 2024 bulletin was published.

The Android Security Bulletin published on November 4, 2024 includes both vulnerabilities under MediaTek components.

Android states that devices with a security patch level of 2024-11-05 or later address all issues associated with the bulletin, assuming the relevant patches are applicable to that device.

This is more useful than simply telling people to "upgrade Android."

A phone manufacturer can integrate security fixes into a supported Android release without necessarily moving the device to a completely new major Android version.

What matters is whether the device manufacturer has delivered the applicable patched software or firmware.

How to Check Whether Your Android Phone Is Updated

You can check your current Android version and security update level directly from the device.

On standard Android, the general process is:

1. Open Settings.
2. Open About phone or About tablet.
3. Select Android version.
4. Check the Android security update date.
5. Go to System → Software updates and install available updates.

Google notes that menu names can vary slightly between devices.

For these November 2024 bulletin issues, a security patch level of 2024-11-05 or later is the key Android reference point.

If your device reports a much older security patch and no update is available, check the support information provided by the phone manufacturer.

How Smartphone Users Can Reduce the Risk

Installing the latest manufacturer-provided security update is the most important step.

Beyond patching:

1. Enable automatic system updates. Delaying a security update leaves known weaknesses unpatched for longer.
2. Keep applications updated. App updates do not replace chipset firmware patches, but keeping the rest of the software stack current reduces other opportunities an attacker might combine with a privilege-escalation flaw.
3. Use trusted application sources. Avoid installing unknown APK files or software from untrusted download sites.
4. Treat unexpected links, files, and prompts cautiously. This is particularly relevant where an exploitation chain requires some form of user interaction.
5. Check your security patch date periodically. Do not assume that having a recent-looking Android version automatically means the device has a current patch level.
6. Review support status for older devices. Google notes that older devices cannot always run newer Android versions. If a device no longer receives security updates and handles sensitive personal or business information, replacing it may be the safer long-term option.

A dedicated mobile security and threat defense strategy can add another layer for organizations managing larger numbers of phones and tablets.

What Businesses Should Do About MediaTek and Other Mobile CVEs

A business response should go further than telling employees to update their phones.

1. Build an Accurate Mobile Asset Inventory

Security teams need to know which devices connect to business systems.

Track the device model, operating system version, security patch level, ownership status, and whether the device remains under manufacturer support.

If the device's chipset information is available through your management platform or vendor documentation, record that as well.

2. Identify Devices Below the Required Security Patch Level

Use your UEM, MDM, endpoint platform, or manual inventory to identify devices that have missed security updates.

Prioritize phones accessing corporate email, VPNs, administrative systems, sensitive applications, customer information, or regulated data.

3. Restrict Non-Compliant Devices Where Appropriate

For higher-risk environments, an outdated mobile device should not automatically receive the same access as a fully patched one.

Network access control and conditional-access policies can help organizations restrict devices that do not meet an approved security posture.

The exact policy should match the organization's environment and business requirements.

4. Review the Mobile Security Baseline

Patch management is only one layer.

A security gap analysis can help identify missing controls around mobile-device enrollment, unsupported operating systems, access policies, patch enforcement, BYOD, incident response, and application security.

5. Monitor Vendor Bulletins Continuously

Chipset security does not end after one Android update.

Security teams should monitor MediaTek, Android, device-manufacturer, and relevant vulnerability advisories so newly disclosed weaknesses can be mapped to assets quickly.

6. Test Applications That Handle Sensitive Data

Fixing an operating-system or chipset vulnerability does not make an insecure application secure.

Organizations developing Android or iOS software should use mobile application security testing to assess authentication, authorization, local storage, API communication, permissions, runtime behavior, and other application-level weaknesses.

7. Review Security-Sensitive Code

Memory corruption is particularly dangerous in low-level software, but secure coding matters throughout the stack.

A structured source code review helps teams identify unsafe coding patterns, weak validation, authorization mistakes, dependency risks, and other vulnerabilities before release.

8. Prevent the Same Classes of Problems Earlier

Organizations producing software or connected products should not rely entirely on post-release vulnerability discovery.

Embedding threat modeling, secure code review, dependency analysis, automated security gates, and testing through a secure SDLC process can help detect weaknesses much earlier in development.

Why Android Patch Fragmentation Still Matters

MediaTek creates and distributes fixes to its customers, but smartphone owners normally receive those fixes through the device manufacturer.

That creates several stages:

MediaTek fix → OEM integration → device-specific testing → carrier/vendor distribution where applicable → user installation

MediaTek says OEMs had been notified of the relevant issues and patches for at least two months before the November 2024 bulletin became public.

Even so, the exact availability of an update can depend on the phone model and manufacturer support lifecycle.

This is why checking the actual Android security update date on the device gives users more useful information than simply checking whether a phone runs Android 12, 13, 14, or 15.

Why Updating Apps Alone is Not Enough

There is an important difference between an app vulnerability and a chipset vulnerability.

Updating applications from the Play Store helps patch problems inside those apps.

It does not by itself replace the low-level MediaTek components affected by CVE-2024-20104 or CVE-2024-20106.

For these vulnerabilities, users need the applicable system, firmware, or vendor security update delivered for their device.

That is why "all my apps are updated" should not be treated as proof that the underlying Android device is fully patched.

What If Your Phone No Longer Receives Security Updates?

An unsupported phone creates a different problem.

You may know that a vulnerability exists but have no official patch available for your device.

First, confirm the device's latest security update and check the manufacturer's official support information.

For personal devices containing little sensitive information, the decision may depend on individual risk.

For business devices handling privileged accounts, confidential communications, customer records, or administrative access, continuing to use an unsupported phone can create a more serious security exposure.

Organizations should define a maximum supported patch age and remove or restrict devices that fall outside it.

Frequently Asked Questions

What are the main MediaTek vulnerabilities discussed here?

They are CVE-2024-20104 and CVE-2024-20106, two privilege-escalation vulnerabilities disclosed in MediaTek's November 2024 security bulletin.

Is CVE-2024-20104 a remote attack?

MediaTek describes it as a local escalation-of-privilege vulnerability. Exploitation requires user interaction but no additional execution privileges.

Is CVE-2024-20106 a zero-click vulnerability?

Calling it a standalone zero-click compromise would be misleading. User interaction is not required, but MediaTek states that an attacker must already have System execution privileges.

Which Android versions were affected?

MediaTek lists Android 12.0, 13.0, 14.0, and 15.0 for both vulnerabilities.

Was Android 12L listed?

MediaTek's affected-software tables for CVE-2024-20104 and CVE-2024-20106 list Android 12.0, 13.0, 14.0, and 15.0. Android 12L is not listed in those two MediaTek entries.

How do I know whether my Android device has the fix?

Check the Android security update date under your device's Android version information. Android's November 2024 bulletin says a security patch level of 2024-11-05 or later addresses all issues associated with that bulletin.

Should I install a new Android version?

Install the newest system and security update officially available for your device. A major Android-version upgrade is not necessarily the only way an OEM can deliver a security fix.

Are millions of phones confirmed to be vulnerable?

The MediaTek bulletin lists affected chipsets and software versions but does not provide a verified number of affected phones or users. An exact device count should therefore not be presented as confirmed without additional reliable evidence.

Final Takeaway

CVE-2024-20104 and CVE-2024-20106 show why chipset vulnerabilities deserve attention without exaggeration.

Both can enable local privilege escalation, but their exploitation conditions are different. CVE-2024-20104 needs user interaction. CVE-2024-20106 needs existing System privileges.

For individual users, the most important action is simple: check the Android security patch level and install the newest security update offered by the manufacturer.

For businesses, the response should be broader: maintain an accurate mobile-device inventory, enforce patch requirements, restrict unsupported devices, monitor vendor advisories, and test the applications and services those devices can reach.

Organizations managing Android fleets or building mobile applications may need more than a one-time patch check.

A practical assessment can determine which mobile assets are outdated, which applications expose sensitive data, where access controls are weak, and whether remediation has actually closed the identified risk.

Hoplon Infosec can support relevant areas such as mobile application security testing, vulnerability management, mobile security assessment, security gap analysis, and secure development practices.

The right starting point depends on whether the problem is an unpatched device fleet, an application-security concern, or a broader weakness in the organization's mobile-security program.

Review your current mobile-device and application exposure, identify the highest-priority gaps, and build a remediation plan based on verified risk rather than assumptions.