CVE-2026-20435: Yocto Information Disclosure Vulnerability

CVE-2026-20435 Overview

A logic error vulnerability exists in the MediaTek preloader component that allows unauthorized reading of device unique identifiers. This information disclosure vulnerability affects numerous MediaTek chipsets used across Android devices, IoT platforms, and embedded systems. An attacker with physical access to a vulnerable device can exploit this flaw to extract sensitive device identifiers without requiring any special privileges or user interaction.

Critical Impact

Physical access to affected devices enables extraction of unique device identifiers, potentially compromising device authentication mechanisms, enabling device tracking, or facilitating further targeted attacks against specific hardware.

Affected Products

• Google Android 14.0, 15.0, and 16.0
• MediaTek MT6700/MT6800/MT6900 series chipsets (MT6739, MT6761, MT6765, MT6768, MT6781, MT6789, MT6813, MT6833, MT6853, MT6855, MT6877, MT6878, MT6879, MT6880, MT6885, MT6886, MT6890, MT6893, MT6895, MT6897, MT6983, MT6985, MT6989, MT6990, MT6993)
• MediaTek MT8100/MT8600/MT8700 series chipsets (MT8169, MT8186, MT8188, MT8370, MT8390, MT8676, MT8678, MT8696, MT8793, MT2737)
• Linux Foundation Yocto 4.0
• RDKCentral RDK-B 2022Q3 and 2024Q1
• OpenWrt 21.02.0 and 23.05.0
• Zephyr Project Zephyr 3.7.0

Discovery Timeline

• 2026-03-02 - CVE-2026-20435 published to NVD
• 2026-03-03 - Last updated in NVD database

Technical Details for CVE-2026-20435

Vulnerability Analysis

This vulnerability resides in the MediaTek preloader, which is a critical early-stage bootloader component responsible for initializing hardware before the main operating system loads. The preloader contains a logic error in how it handles requests for device-specific identifiers, failing to properly validate the context in which such requests are made.

When the preloader processes certain commands during the boot sequence, it does not adequately verify whether the requesting entity should have access to device unique identifiers such as IMEI numbers, serial numbers, or hardware-specific cryptographic keys. This insufficient access control allows an attacker with physical access to extract these identifiers through the device's bootloader interface.

The vulnerability is classified under CWE-522 (Insufficiently Protected Credentials), indicating that sensitive device identifiers are not adequately protected from unauthorized access. The attack requires physical access to the device, limiting remote exploitation but making the vulnerability particularly relevant for device theft scenarios, forensic analysis evasion, or targeted surveillance operations.

Root Cause

The root cause is a logic error in the MediaTek preloader's credential protection mechanism. The preloader fails to implement proper access controls when handling requests for device unique identifiers, allowing these sensitive values to be read without proper authentication or authorization checks. This represents a fundamental flaw in how the bootloader segregates access to sensitive hardware information.

Attack Vector

Exploitation requires physical access to a vulnerable device. An attacker can connect to the device through its bootloader interface (typically via USB or UART debug ports) and issue commands to read device unique identifiers. The attack does not require elevated privileges on the device, nor does it need any user interaction, making exploitation straightforward once physical access is obtained.

The attacker may leverage MediaTek-specific tools or custom software to communicate with the preloader during the early boot phase, before the main operating system has loaded any security controls. Once extracted, device identifiers can be used for device tracking, cloning attacks, or bypassing device-based authentication systems.

Detection Methods for CVE-2026-20435

Indicators of Compromise

• Unexpected USB or serial connections to devices during boot sequences
• Evidence of devices being booted into download or preloader mode without authorized maintenance
• Physical signs of device tampering or unauthorized access to debug ports
• Anomalous device identifier queries in audit logs if logging is enabled at the bootloader level

Detection Strategies

• Implement physical access monitoring and tamper-evident seals on devices containing sensitive data
• Enable bootloader-level logging where supported to capture unauthorized access attempts
• Monitor for unauthorized firmware modifications that might indicate exploitation attempts
• Deploy endpoint detection solutions capable of identifying unusual boot sequences

Monitoring Recommendations

• Establish baseline behavior for device boot patterns and alert on deviations
• Implement asset tracking to quickly identify devices that may have been compromised through physical access
• Review security camera footage and access logs in areas where affected devices are stored
• Consider hardware security modules (HSM) or secure enclaves for protecting critical identifiers on high-value devices

How to Mitigate CVE-2026-20435

Immediate Actions Required

• Apply the MediaTek security patch identified as ALPS10607099 when available from your device manufacturer
• Restrict physical access to affected devices, especially in enterprise or government environments
• Review and strengthen physical security controls for devices containing sensitive information
• Audit devices for signs of unauthorized physical access or tampering

Patch Information

MediaTek has addressed this vulnerability in their March 2026 security bulletin. The patch is identified by Patch ID: ALPS10607099 and Issue ID: MSV-6118. Organizations should obtain patched firmware from their device manufacturers or original equipment manufacturers (OEMs) who integrate MediaTek chipsets. For Android devices, patches will be distributed through the Android Security Bulletin process. For embedded systems using Yocto, OpenWrt, or Zephyr, updated board support packages (BSPs) from MediaTek should be integrated.

For additional details, refer to the MediaTek Security Bulletin March 2026.

Workarounds

• Implement strict physical access controls and device custody tracking for affected devices
• Disable or physically secure debug interfaces (USB/UART) on production devices where possible
• Use secure boot chains and encrypted storage to limit the impact of identifier disclosure
• Consider deploying additional authentication layers that do not rely solely on device identifiers

# Example: Disable USB debugging on Android devices via ADB
adb shell settings put global adb_enabled 0
adb shell settings put global development_settings_enabled 0

# Note: For embedded systems, consult your BSP documentation
# for disabling preloader debug interfaces