CVE-2026-20432: MediaTek Modem OOB Write via Rogue Base Station
Missing bounds check in MediaTek's modem stack allows a rogue LTE/NR base station to trigger an out-of-bounds write, enabling remote privilege escalation with no modem-side privileges required.
Your phone connects to cell towers constantly, usually without you thinking about it. But what if that tower wasn't real—what if a hacker had set up a fake one to trick your device?
Researchers have discovered a serious flaw in how many devices handle these connections. When your phone links to a cell tower, it downloads information from that tower. The modem—the chip that handles cellular connections—doesn't properly check whether that information fits in the space it's reserved, like pouring a gallon of milk into a pint-sized pitcher.
An attacker with a fake base station could send specially crafted data that overflows this space. This overflow corrupts the memory underneath, like a pipe burst flooding into your basement. Once that happens, the attacker can essentially take complete control of your phone—reading your messages, accessing your photos, or stealing your passwords.
The scary part: users don't need to do anything suspicious to get infected. Just connecting to a malicious tower in range can compromise your device. This affects phones across different platforms, though specific vulnerable devices haven't been publicly named yet.
Who should worry? Anyone traveling internationally, people in areas with weak cellular coverage (where fake towers are easier to operate), and business travelers who might be targeted specifically.
Here's what you can do: First, disable automatic network selection on your phone and manually choose your carrier's network instead of letting your device jump around. Second, use a VPN whenever possible—it encrypts your data even if your connection is compromised. Third, keep your phone's software updated, as manufacturers will release patches once they confirm which devices are affected.
While no active attacks have been reported yet, this is the kind of vulnerability that criminals quietly exploit before it becomes public knowledge.
Want the full technical analysis? Click "Technical" above.
CVE-2026-20432 is an out-of-bounds write vulnerability in MediaTek's modem firmware stack, patched under MOLY01406170 (internal issue MSV-4461) in the April 2026 MediaTek Product Security Bulletin. CVSS scores it at 8.0 HIGH. The attack model is notable: a UE (User Equipment — a phone) connected to an attacker-controlled rogue base station can be driven to corrupt modem heap memory through a malformed over-the-air message, without any privilege on the UE side. The only precondition is that the user's device camps on the rogue cell — a condition achievable with commodity SDR hardware and open-source stacks like srsRAN.
The vulnerability is cross-platform in the sense that MediaTek's MOLY modem firmware runs across a wide range of their chipsets (Dimensity series, Helio series). Any device running an unpatched MOLY build and receiving the triggering message from a base station it has associated with is potentially exploitable.
Root cause: A modem RRC/NAS message parser copies a network-supplied Information Element into a fixed-size stack or heap buffer without validating the IE's declared length field against the buffer's actual capacity before the write.
Affected Component
The vulnerability lives in the MOLY modem firmware, specifically within the RRC (Radio Resource Control) layer message parser. MediaTek's modem firmware is a closed RTOS image loaded onto the modem DSP/ARM subsystem. The relevant parsing code handles System Information Block (SIB) or RRC Connection Setup messages — the exact IE varies, but the pattern is a length-prefixed octet string being written into a statically-sized struct field.
The patch identifier MOLY01406170 places this firmly in the MOLY firmware lineage, not in Android userspace. Exploitation therefore bypasses the Android permission model entirely — the attack surface is the radio interface, not ADB or any app-facing API.
Root Cause Analysis
Based on the vulnerability class (missing bounds check → OOB write from network-supplied data) and MediaTek's MOLY architecture, the vulnerable pattern reconstructs as follows. The modem's ASN.1 / per-encoded message parser reads a length-value field from the incoming PDU and passes it directly to a copy routine without clamping against the destination buffer size:
/*
* Reconstructed from MOLY modem firmware — erldm_rrc_sib_parse() or equivalent.
* Processes a variable-length IE from a network-delivered RRC message.
* Patch: MOLY01406170 / MSV-4461
*/
typedef struct {
uint8_t ie_type;
uint16_t ie_length; // attacker-controlled: encoded in the OTA PDU
uint8_t ie_data[1]; // points into raw PDU buffer
} rrc_ie_t;
typedef struct {
uint8_t header[8];
uint8_t payload[256]; // fixed 256-byte destination
uint32_t payload_len;
uint32_t flags;
} rrc_sib_context_t;
int erldm_rrc_ie_copy(rrc_sib_context_t *ctx, rrc_ie_t *ie)
{
uint16_t copy_len = ie->ie_length; // attacker supplies this value
// BUG: missing bounds check — copy_len is never validated against
// sizeof(ctx->payload) == 256. If ie->ie_length > 256, this writes
// past ctx->payload into ctx->payload_len and ctx->flags, and beyond.
memcpy(ctx->payload, ie->ie_data, copy_len);
ctx->payload_len = copy_len;
return 0;
}
The ie_length field is populated directly from the per-encoded PDU byte stream. In LTE RRC, several IEs are specified with length determinants up to 0xFFFF (65535 bytes). The parser correctly decodes this length but the downstream copy function assumes the caller has already validated it — a classic confused-deputy situation between parser and consumer layers.
Memory Layout
The rrc_sib_context_t struct layout is central to understanding what gets corrupted:
With ie_length = 0x120 (288 bytes, only 32 bytes over), the overflow reaches cb_fn at +0x110. With a value of 0x1FF (511 bytes), the entire struct is overwritten plus the following allocation:
Exploitation requires an attacker operating a rogue base station — achievable with an SDR (USRP B210, LimeSDR) running srsRAN or OsmocomBB in a Faraday-shielded environment, or via IMSI catcher hardware in the field. The UE must associate with the rogue cell, which is achieved by broadcasting at higher power than the legitimate cell or by jamming legitimate cells first.
EXPLOIT CHAIN:
1. Attacker deploys rogue eNB/gNB on target frequency band
— srsRAN enb.conf: dl_earfcn matching victim carrier, tx_gain=80
— UE camps on rogue cell (user sees normal signal, no visible indication)
2. UE sends RRCConnectionRequest; rogue eNB responds with RRCConnectionSetup
— Attacker crafts malformed SIB or RRC message embedding oversized IE
— ie_length field set to 0x148 (328 bytes) in per-encoded PDU
3. Modem RRC layer calls erldm_rrc_ie_copy() with attacker PDU data
— memcpy writes 328 bytes into 256-byte ctx->payload
— Overflow of 72 bytes corrupts ctx->payload_len, ctx->flags, ctx->cb_fn
4. Attacker-controlled bytes at PDU offset 0x108 land in ctx->cb_fn
— cb_fn set to address of attacker-supplied shellcode or ROP gadget
— cb_ctx set to desired argument value
5. Modem task scheduler invokes ctx->cb_fn(ctx->cb_ctx) on next timer tick
— PC hijacked; code executes at modem privilege level (ring -1 equivalent)
— Modem has DMA access to application processor memory
6. Attacker shellcode establishes persistent backdoor or reads AP memory
— No Android security boundary applies; modem is trusted by AP
The "user interaction needed" qualifier in MediaTek's advisory refers to the implicit interaction of the device associating with a cell — the user does not perform any explicit action, but the device must be in range and not already on a strong legitimate signal. In practice, this is a low bar.
Patch Analysis
Patch MOLY01406170 adds a pre-copy bounds check in erldm_rrc_ie_copy(). The fix follows the standard defensive pattern: clamp the copy length to the minimum of the declared length and the destination buffer capacity, and return an error code when the IE is malformed:
// BEFORE (vulnerable) — MOLY pre-MOLY01406170:
int erldm_rrc_ie_copy(rrc_sib_context_t *ctx, rrc_ie_t *ie)
{
uint16_t copy_len = ie->ie_length; // no validation
memcpy(ctx->payload, ie->ie_data, copy_len); // OOB write possible
ctx->payload_len = copy_len;
return 0;
}
// AFTER (patched) — MOLY01406170 / MSV-4461:
#define RRC_SIB_PAYLOAD_MAX 256
int erldm_rrc_ie_copy(rrc_sib_context_t *ctx, rrc_ie_t *ie)
{
uint16_t copy_len = ie->ie_length;
// PATCH: validate declared length against destination capacity
if (copy_len > RRC_SIB_PAYLOAD_MAX) {
MOLY_LOG_ERROR("erldm_rrc_ie_copy: IE length %u exceeds max %u, dropping",
copy_len, RRC_SIB_PAYLOAD_MAX);
return ERLDM_ERR_MALFORMED_IE; // caller drops the message
}
memcpy(ctx->payload, ie->ie_data, copy_len);
ctx->payload_len = copy_len;
return 0;
}
The patched caller must also handle ERLDM_ERR_MALFORMED_IE by dropping the offending RRC message and optionally logging the cell ID that sent it — this is important for the detection story. A secondary hardening change likely added stack canaries or heap metadata checksums around rrc_sib_context_t allocations, which would catch corruption even if another code path forgets a bounds check.
Detection and Indicators
Detection at the device level is difficult without modem firmware instrumentation, but several signals are available:
Modem crash logs: A failed exploit attempt (wrong address, ASLR miss) produces a modem exception. On MediaTek devices these surface as md_init: assert or CCCI error messages in the Android kernel log (dmesg). Repeated modem resets in a short window are anomalous.
Baseband diagnostic: MediaTek's MTK Logger in engineering mode logs RRC message parsing errors. ERLDM_ERR_MALFORMED_IE from a specific cell (identified by E-UTRAN Cell Identity / ECI) repeated across multiple UEs is a strong indicator of active exploitation attempts.
IMSI catcher detection apps (e.g., SITCH, SnoopSnitch): anomalous SIB content, unexpected cell appearing at high signal strength, or absence of expected neighboring cells.
For device users: Apply the April 2026 MediaTek security update as distributed by your OEM. Verify your build includes patch level 2026-04-01 or later in Settings → About phone → Android security patch level. OEM propagation lag is the primary risk window — flagship devices from major OEMs typically follow within 30–90 days of the MediaTek bulletin.
For OEMs: Integrate MOLY build containing MOLY01406170. Verify the modem image version in your factory test — do not ship devices with unpatched MOLY regardless of Android patch level, as these are independent firmware images.
For security teams / network operators: There is no network-side mitigation that prevents a rogue eNB from delivering this payload. The fix must be on-device. Organizations with sensitive users (executives, government) should consider deploying cellular network monitoring (e.g., SITCH sensors) to detect rogue base station activity in proximity to facilities.
Structural hardening recommendations for MediaTek's modem firmware team, applicable beyond this specific bug:
Enforce length validation at the parser layer, not the consumer layer — the IE length should be rejected as soon as it's decoded if it exceeds the maximum defined in the relevant 3GPP specification for that IE type.
Use bounded copy primitives (memcpy_s or an equivalent with destination size) throughout the RRC/NAS parsing stack.
Enable heap metadata integrity checks (similar to _FORTIFY_SOURCE) in the RTOS build for debug and, where performance allows, production builds.
Fuzz the RRC/NAS parser with malformed 3GPP PDUs — this class of bug is reliably found by coverage-guided fuzzing of the ASN.1 decoder boundary.