Aug 11, 2026
Policy

Malicious SIM attacks exposed in smartphone and IoT device tests

Researchers found a standards-defined SIM command path that enabled file reads, code execution and 2G downgrades in selected devices.

Dominic Okoye

By Dominic Okoye · Staff Writer

· 3 min read

Malicious SIM attacks exposed in smartphone and IoT device tests
Photo: The Register

Malicious SIM attacks were scheduled for presentation at USENIX WOOT ’26 on August 11 after University of Birmingham researchers and Fuzzware’s Kristian Covic found a SIM-controlled modem interface in nine of 26 tested devices. Their CATana toolkit identified four vulnerabilities and demonstrated outcomes including arbitrary file reads, code execution, denial of service and forcing a cellular connection down to 2G.

The result is a device-security issue, not evidence that a nearby attacker can remotely commandeer every phone through a rogue cell tower. An attacker must first control the target’s SIM or eSIM. That could happen through compromised SIM software, physical replacement or an implant, abuse of an operator’s remote SIM-management tools, or supply-chain modification, according to University of Birmingham material.

How do malicious SIM attacks work?

The research concerns Proactive SIM functions, a standards-defined set of commands a SIM can send to its host device. One command, called RUN AT, asks the device to execute an AT command, an instruction type long used to operate and configure modems. If the device exposes this request path, it creates a SIM AT interface that a hostile SIM can use to reach modem functions or device-specific flaws.

That means a SIM can become a route into the device when an attacker controls it. The eventual impact remains dependent on the particular hardware, firmware and available commands. The researchers argued that vendors should harden, disable or retire the interface rather than assume all SIMs remain benign.

Which devices were exposed in the CATana tests?

The sample was small and should not be read as a market-wide prevalence estimate. Still, the split was notable: seven of eight cellular IoT modems exposed the interface, compared with two of 18 smartphones. The tested IoT equipment included modules used in EV chargers, industrial systems and connected vehicles.

According to The Register’s reporting, the team achieved code execution on an Autel EV charger fitted with a Quectel EC25-AFX module by exploiting a command-injection flaw in the modem’s Linux-based application processor. It also reported a file-exfiltration demonstration on a Quectel EG25-G modem. On an Oppo Reno14 F 5G, the reporting said researchers found commands through the SIM interface that could shut down the handset, stop its modem or force a 2G connection.

The 2G downgrade is consequential because it can put a device onto an older network generation with known security weaknesses. The Electronic Frontier Foundation has said 2G lacks tower-to-phone authentication and uses weak tower-to-device encryption, while 3G, 4G and 5G addressed the worst of those defects. This SIM-command path differs from a cell-site simulator: the latter tries to force a radio downgrade from the network side, while CATana starts with control of the SIM inside the target device.

What has been patched?

The Register reported that Google fixed a separate issue, tracked as CVE-2025-48618, in Android 13 through 16 in December 2025. That flaw let a hostile SIM launch an attacker-controlled website on affected Android versions without interaction, including while the device was locked. The patch should not be treated as a fix for every SIM AT interface risk.

Researchers disclosed their findings to Google, Oppo, Quectel, Semtech and Qualcomm in March 2026, then to the GSMA in May, The Register reported. Qualcomm has produced a hardened configuration that disables the SIM AT interface by default, according to that report, while GSMA is tracking the wider matter as CVD-2026-0122. The University of Birmingham said manufacturers had made updates and hardened configurations available, but did not publish a device-by-device patch list.

This story draws on original reporting from The Register.

More from Policy

All Policy →