MediaTek's October fixes: verify updates across work phones

MediaTek published its October bulletin covering 31 CVEs on 5 October: two critical, nine high and twenty medium. Device manufacturers received the issues and patches at least two months earlier. The vendor reported no awareness of active exploitation at publication.

For an organisation, the key question is: which devices in use have received the relevant device-vendor update? A component bulletin’s date does not establish that every phone using that chipset has been patched.

What the two critical records describe

CVE-2026-20519 and CVE-2026-20520 concern out-of-bounds writes in the modem. MediaTek describes potential remote privilege escalation if a device connects to an attacker-controlled rogue base station. The description does not require user interaction.

The records and bulletin identify specific chipsets. Assessing a phone therefore requires its model, hardware variant and information about fixed firmware. The brand name or major Android version alone does not settle exposure.

Three details instead of a general “up to date”

Android documentation explains how to find the OS version, security update level and build number. It also notes that update schedules vary by device, manufacturer and operator.

Breachroad recommends recording the exact model, build and patch level, then mapping them to the device vendor’s notice. Include deployment status and the last confirmation date. Do not close the task solely because an update package has been downloaded.

For managed devices, use the available organisational report and understand what it actually measures. For personal phones allowed to access work resources, follow the established policy and collect only information needed for the assessment. Do not request screenshots of private messages or other unrelated data.

A plan for the device administrator

1. Inventory models. Include phones used for email, messaging and access approvals, as well as older spare devices.
2. Check the device vendor’s notice. Map the model variant to available firmware and stated fixes. If the information is unclear, ask the supplier to confirm coverage.
3. Plan deployment. Set a deadline, an owner and a route for update failures. Employees should know when they can interrupt phone use.
4. Confirm the installed state. Check the resulting build and any required installation completion or restart according to the device instructions.
5. Handle exceptions. A device without an available fix needs a risk-owner decision: restricted use, an alternative device or a replacement plan. Record the rationale and review date.

This is Breachroad’s proposed plan. It does not assert that every MediaTek device is affected or that an app update replaces a device-firmware fix. Match the assessment to the actual hardware.

Training scenario: two phones that look alike

In our fictional scenario, two employees use phones from the same brand. One reports a new build; the other says all their apps are current. The team must establish whether those statements answer the same question and what further information the administrator needs.

A good answer identifies the model, variant and device software update state. The exercise should also explain where to report an unavailable update and how to obtain help. Employees do not need to analyse chipset lists themselves or install firmware found on an unfamiliar website.

Employee cybersecurity training connects user habits with the organisation’s update and reporting process. Our smartphone security guide provides supporting advice.

Sources and Breachroad conclusions

The vulnerability summary comes from MediaTek; its CVE records describe the conditions for the two modem flaws. Google documents update checks and availability. The inventory approach, administrator plan and fictional scenario are Breachroad recommendations. A vendor’s lack of knowledge of exploitation does not guarantee an absence of incidents.