Proactive SIM: How a Hostile SIM Card Takes Over IoT Modems

A SIM card is allowed to issue commands to the device it sits in – that is written into the cellular specifications. Researchers at the University of Birmingham examined what happens when that card turns hostile: six of eight IoT modules tested could be driven this way, and three of 18 smartphones.

What is the Proactive SIM feature and what does RUN AT do?

A SIM card is not a passive memory chip but a small computer. Normally the modem’s communication processor queries the card. But under the name “Proactive SIM“, the specifications also provide for the reverse direction: the card may issue a limited number of commands to the device. One of them, RUN AT, instructs the device to execute a specified AT command – a control instruction from the command set that has configured modems since the Hayes Smartmodem of 1981. In effect, this creates a command interface running from the card into the device.

A team around Tomasz Piotr Lisowski and Dr Marius Muench of the University of Birmingham worked with Kristian Covic of security firm Fuzzware to build the CATana toolkit and probe this interface systematically. It comprises four components: an interactive command line, a SIM applet, an automation module for bulk testing, and an analyser. The team presented its findings on 10 August 2026 at the USENIX WOOT conference in Baltimore; the paper is openly available and the source code is published as a research artifact on Zenodo. The authors deliberately withheld ready-made attack applets. Muench stresses that this is not a break with the standard but a consequence of following it. The proactive capabilities of a SIM and the resulting attack surface are “explicitly defined in the technical specifications for cellular communication”, he says in the University of Birmingham announcement. The attacks therefore follow the specification rather than violate it.

Which devices expose the SIM AT interface?

The team examined 26 devices: 18 smartphones from ten vendors and eight cellular IoT modules from four vendors. Nine devices granted the SIM an AT command interface. Among the modules, that is six of eight. Those tested included a module from an EV charger, one from an industrial router and one from a car’s telematics control unit. Only the Nordic nRF9160-DK development board and the Simcom SIM800C did not support RUN AT.

On the smartphone side it is three of 18: the OPPO Find X5, OPPO Reno14 F 5G and Asus Zenfone 9. Two come from the same vendor, and all three use a Qualcomm communication processor. Other vendors ship the same processor without offering the feature, which leads the researchers to conclude it is added deliberately during device personalisation. The Apple and Google devices tested reported no support. That is only partial reassurance. Analysing two Samsung Exynos basebands, the team found that the parser merely adds RUN AT to a block list. The code for parsing and forwarding the command remains in the firmware and would be reachable through a control-flow hijacking exploit.

What were the researchers able to demonstrate?

The findings yielded four vulnerabilities, illustrated by three case studies.

Code execution on an EV charger.

The target was an AUTEL Maxi US AC W12-L-4G charging station containing a Quectel EC25AFXDGA module. The atfwd_daemon program inside the module accepts AT commands, including from the SIM interface, and assembles some of them into shell calls. In two places the researchers found an unsafe format string that lets an attacker inject their own text into the shell command. A character block list was meant to prevent this but could be bypassed with a newline. In two stages the team achieved code execution, driven purely by commands issued from the card.

Shutdown and 2G fallback on a smartphone.

On the OPPO Reno 14 F 5G, CATana found 198 AT commands and variants reachable through the SIM. Three sufficed for the demonstration: one powers the phone down, one shuts off the communication processor, one restricts the device to 2G networks. The user could not reverse that downgrade – not through airplane mode, manual network selection, turning off mobile data, disabling the SIM, or changing the preferred network generation.

File theft through a modem.

On Quectel modules the file system does not live in the communication processor but on the internal application processor, reached over the TFTP protocol. Its daemon does not check whether a path is a symbolic link. On the EG25-G module the team combined a previously placed link with SIM-originating commands and had the linked file emailed to a server under its own control using the module’s own SMTP commands. The attack has a precondition: an attacker must first get the link into the file system, for instance via a prepared SD card or by flashing a manipulated partition.

Why does this hit IoT devices harder than smartphones?

The reason lies in how the modules are built. Nearly every module examined runs a second, more powerful processor alongside the radio. On every Quectel module tested, that processor runs Android on an ARM Cortex-A7 core – even where the host device’s main CPU is weaker. The radio answers few AT commands itself and passes the rest up to this internal computer. The card therefore talks to what the paper calls “a rich attack surface to hostile SIMs”.

On top of that, precisely because IoT devices are usually locked down and expose only a handful of interfaces, one overlooked interface carries disproportionate weight. And the damage does not stop at the module. In one surveyed device the researchers found a memory flaw in the main processor’s firmware that can be triggered when the module supplies a malformed IP address. A compromised module thus becomes a stepping stone into the wider system.

How realistic is a hostile SIM card?

The objection is obvious: anyone who controls the SIM has already gained a great deal. The team therefore adopts a threat model from earlier work listing four sources of hostile cards, each backed by a real-world precedent.

• First, vulnerabilities in SIM software, as exploited by the SIMJacker attacks.
• Second, physical access to swap the card or install an interposer; the NSA’s ANT catalogue lists SIMs as an attack vector.
• Third, remote SIM administration by malicious or compromised operators – one observed operator data breach included SIM authentication secrets.
• Fourth, supply-chain manipulation between manufacturing and distribution.

Since eSIMs use the same technical path, the third point in particular affects IoT fleets relying on remote provisioning. Alongside the RUN AT findings, the researchers hit on a further weakness: on recent Android versions a hostile card can use the LAUNCH BROWSER command to make the phone open a website of the attacker’s choosing without any user interaction, even with the screen locked. Google acknowledged the case as CVE-2025-48618 and released a patch.

How did the manufacturers respond?

The team disclosed its findings in March 2026 to Google, Oppo, Quectel, Semtech (formerly Sierra Wireless) and Qualcomm; after initial responses, it additionally informed the GSM Association in May 2026. The reactions varied. Oppo and Google triaged the reports and considered them informative, but outside the scope of their respective bug bounty programmes. Semtech confirmed the findings and plans to adopt patches from baseband vendor Qualcomm.

Quectel also confirmed them, but noted that the shell command injection was already known and fixed in newer firmware versions; the company has since removed the SIM AT interface. Qualcomm supplied a hardened configuration that disables the interface by default. The GSMA passed the report to its CVD panel, tracks the case as CVD-2026-0122, and intends to brief 3GPP and ETSI on the findings. The university announcement additionally cites the identifier CVE-2026-57550 without attributing it to a manufacturer. Looking ahead, the authors argue for more than blocking the interface with a block list: the associated code paths should be removed from the baseband and the software stack so that they cannot reappear through a regression.

Conclusion

The real finding lies not in four individual vulnerabilities but in the interface that makes them reachable. It is not a bug but a documented feature – and whether it is active in the shipped product is a decision each manufacturer makes for itself. The smartphone results show exactly that: the same processors, different configuration, different outcome. For operators of IoT fleets, this shifts the question away from “is my device patched” towards “why is this feature switched on in my module at all”. That Qualcomm and Quectel have moved does not resolve the underlying problem: as long as the standard provides for the feature and block lists merely conceal the code, it remains a configuration decision – and configuration decisions outlive firmware generations.

What is the Proactive SIM feature and what does the RUN AT command do?

Proactive SIM is a capability provided for in the cellular specifications that lets a SIM card issue a limited number of commands to the device it sits in. The RUN AT command instructs the device to execute a specified AT command, a control instruction from the modem command set in use since 1981. This effectively creates a command interface running from the card into the device.

Which devices are affected by the SIM AT interface?

In the University of Birmingham study, nine of 26 devices tested exposed the AT command interface to the SIM. Six of the eight IoT modules were affected, and three of the 18 smartphones. The device classes chiefly affected are therefore EV chargers, industrial routers and automotive telematics units.

Are eSIMs affected in the same way as physical SIM cards?

The study’s threat model includes eSIMs because they use the same technical path to the modem. Among four sources of hostile cards, the researchers explicitly name remote administration by malicious or compromised operators. That route is particularly relevant to eSIM-based IoT fleets using remote provisioning.

Which CVE numbers relate to the SIM AT findings?

The GSM Association tracks the case under the identifier CVD-2026-0122. CVE-2025-48618 belongs to a separate finding the team reported to Google: using the LAUNCH BROWSER command, a hostile SIM could open a website on recent Android versions without user interaction. The University of Birmingham announcement additionally cites CVE-2026-57550.

What can IoT device operators do about SIM-originating AT commands?

Qualcomm provides a hardened configuration that disables the SIM AT interface by default, and Quectel has removed the interface from its modules. Operators should establish with their module vendor whether the interface is still active in the firmware they deploy, and apply the corresponding updates. The study’s authors recommend removing the associated code paths entirely rather than merely blocking them with a block list.

What is the CATana toolkit?

CATana is a four-part toolkit developed by Tomasz Piotr Lisowski and Marius Muench of the University of Birmingham together with Kristian Covic of security firm Fuzzware. It systematically probes which AT commands a device accepts through the SIM interface. The source code is published as a research artifact on Zenodo; the authors deliberately withheld ready-made attack applets.

- Advertisement -