MediaTek patches two critical modem flaws exploitable via a rogue base station
MediaTek’s October 2026 security bulletin closes 31 flaws, including two critical out-of-bounds writes in the modem (CVE-2026-20519 and CVE-2026-20520) that a rogue base station can trigger to escalate privileges with no user interaction. Treat the gap between MediaTek’s fix and its distribution by device makers as a risk in its own right, and audit the patch level of your Android fleet.
Monday, October 5, 2026. MediaTek published its monthly security bulletin: 31 flaws closed, including two critical — CVE-2026-20519 and CVE-2026-20520. No click, no download. Both are out-of-bounds writes (CWE-787) in the modem, caused by a missing bounds check. The vector is radio. A rogue base station — an antenna controlled by the attacker that the phone connects to — is enough to trigger the memory corruption and escalate privileges on the device. For a mobile fleet, this is the quietest attack scenario there is: it goes through no email, no app, and no Wi-Fi network.
What the October bulletin contains
The bulletin, scored under CVSS v3.1, breaks down into 2 critical, 9 high, and 20 medium flaws. The breakdown by subcomponent tells the story of the surface area: the two criticals live in the modem, while the rest hit the video decoder (vdec), encoder (venc), video HAL, neural unit (neuropilot), APU, secure world (mtee), and the meta layer.
The two criticals are near-identical: CVE-2026-20519 and CVE-2026-20520 both describe “a possible out of bounds write due to a missing bounds check,” in the Modem subcomponent, both classified CWE-787. They affect the same set of roughly 57 chips — from entry-level MT6739 parts to recent Dimensity silicon (MT6980, MT6985, MT6989, MT6990, MT6991, MT6993), plus IoT and automotive platforms (MT8668, MT8676, MT8678). In practice that spans hundreds of millions of Android devices, not just phones.
On the high side, CVE-2026-20526 and CVE-2026-20527 are also modem flaws — an out-of-bounds write and a faulty index validation (CWE-129) — while CVE-2026-20586, CVE-2026-20589, CVE-2026-20521, CVE-2026-20522, CVE-2026-20523, and CVE-2026-20524 hit the SoC’s multimedia and AI pipelines. Those generally require local access or a malicious app to exploit: less dramatic, but a reminder that a monthly SoC patch is never just about the modem.
Why the modem is the part that worries people
The modem (or baseband) is the part of the phone that talks to the cellular network. Historically it is closed code, supplied by the chipmaker, that neither a company’s security team nor outside researchers can audit the way they can the rest of the system. It continuously processes untrusted data arriving from outside — network beacons, cell identifiers, control messages — with no user interaction.
That is exactly what makes the two criticals dangerous. A rogue base station (sometimes called an IMSI catcher) emits a cellular signal the phone accepts as legitimate. Once the device connects, the attacker can send malformed control messages that trigger the out-of-bounds write in the modem firmware. MediaTek states in the bulletin that it is aware of no active exploitation as of October 5, 2026 — but the absence of known exploitation does not lower the risk: this class of bug lends itself to targeted, silent attacks that are hard to detect because they leave no trace on the user side.
The impact goes beyond surveillance. A privilege escalation in the modem can expose communications, defeat the isolation between the baseband and the application processor, and serve as a foothold for longer exploit chains. Chipmakers disclose these flaws quietly, without the echo of a browser zero-day, but the surface area is comparable.
The baseband’s danger is compounded by its isolation. On most devices the modem runs on a separate processor with its own real-time operating system, deliberately sealed off from the application processor that runs Android. That boundary is a security control in theory; in practice, a privilege escalation inside the modem can still expose call metadata and SMS, and in some cases pivot toward the application processor. That is why chipmakers fix these flaws quietly and quickly — and why a phone that has not received the patch is exposed to an attack no app scanner will ever flag.
The real risk: the patch distribution lag
The most important sentence in the bulletin is this one: “device OEMs have been notified of all the issues and the corresponding security patches for at least two months before publication.” The fix has therefore existed since the summer. The question is not whether MediaTek fixed it, but when the patch reaches each device.
The chain is long: MediaTek hands the fix to device makers, who must integrate it into their own firmware and then ship it — sometimes through carriers — as an OTA update. At every link the fix can be delayed, or never delivered for end-of-life models. Google’s monthly Android security bulletin is only one link in that chain: it carries Google’s own fixes and some partner fixes, but a MediaTek patch on a third-party device depends first on that device maker.
For a CISO, the consequence is direct: a fleet’s patch level is not verified by looking at the Android version, but by cross-referencing the security patch level each device reports with the chipmakers’ bulletins. A phone showing a September 2026 patch is not necessarily covered against October’s MediaTek flaws — it may have received them early, or not at all.
Checking the patch level of your fleet
The MediaTek fix is not something you guess, it is something you measure. On Android, the security patch level is shown in settings, but that level is a vendor declaration, not proof that October’s MediaTek fixes are actually integrated. Two commands let you verify on the device.
# Android security patch level reported by the device
adb shell getprop ro.build.version.security_patch
# Radio (baseband) firmware version, to cross-reference with vendor bulletins
adb shell getprop gsm.version.basebandThe first command returns the patch date (for example 2026-09-05); the second returns the baseband version. Cross-reference both with MediaTek’s October bulletin: a device whose patch level goes back to August almost certainly did not receive October’s fixes, and a device whose radio firmware has not moved in months deserves a flag.
Across a fleet, manual checks do not scale. A competent MDM or EMM reports the patch level and baseband version per device; demand that data in your compliance dashboards, on the same footing as the OS version. That is the only way to turn a MediaTek bulletin into measurable action — and to catch devices whose maker has stopped shipping fixes.
Verdict
If you manage an enterprise Android fleet, treat this bulletin as a structural reminder: demand a patch delivery SLA from device makers in your procurement contracts, and do not accept any device whose security patch level is more than 30 days behind. If your fleet contains MediaTek-based devices, cross-reference each device’s patch level with MediaTek’s October bulletin — the two critical flaws span several chip generations, including models still in circulation in business fleets. If you have no visibility into your endpoints, start with a patch-level inventory before discussing mitigation: a rogue base station cannot be stopped by antivirus, only by up-to-date firmware. The deeper lesson applies to everyone: on mobile, the weakest link is not the phone — it is the gap between the chipmaker’s fix and its actual arrival on the device. Close that gap on every device, and a rogue base station becomes an annoyance rather than a breach.