A malicious SIM card can order the device it sits in to run commands of the attacker’s choosing. On the cellular modules built into electric-vehicle chargers, industrial routers, and car telematics units, that is enough to take the whole device over.
Researchers at the University of Birmingham and the security firm Fuzzware tested 26 phones and cellular modules for the capability, found it switched on in 9 of them, and used it to run their own code on a commercial EV charger.
Six of the eight cellular modules they tested accepted the command. Only 3 of 18 phones did: the OPPO Find X5, the OPPO Reno 14 F 5G, and the ASUS Zenfone 9. No iPhone or Pixel was among them.
The exposure is in machine-to-machine hardware. Five of the six were Quectel parts, three of them pulled from an EV charger, an industrial router, and a car’s telematics control unit.
Knowing the victim’s number is not enough: every attack starts with a hostile card already in the slot, swapped by hand, slipped in as a thin interposer, pushed out by a compromised operator, or subverted in software or on the production line. Unattended IoT gear with an accessible SIM tray and few other exposed interfaces is exactly where that trade is worth making.
There is no single patch. Every one of the nine devices that accepted the command runs a Qualcomm communication processor. Five other Qualcomm-based handsets in the survey did not accept it, which the paper suggests is down to vendor customisation.
Qualcomm told the researchers it has built a hardened configuration that switches the interface off by default. Quectel says it has mitigated the file-access flaw and is still working on the interface itself. Neither has published an advisory, and the module maker’s vulnerability portal requires a login to see anything at all.
The researchers’ own position is that the interface should be hardened, deprecated, or disabled outright. That hardened configuration will be the default on future devices, the researchers told The Hacker News, and fixes will also reach affected modules as updates, though the team has not checked whether the RUN AT code paths are removed or only switched off. For anyone running cellular IoT fleets, the step available today is to ask the module supplier whether RUN AT is enabled in the firmware they shipped and whether it can be disabled. No attacks using the interface have been reported.
The command in question is a proactive command, part of the standardised set a SIM can push back at the modem instead of waiting to be read. RUN AT asks the modem to execute an AT command, the modem control language that dates to the 1981 Hayes Smartmodem and that every vendor extends with its own additions. Supporting it therefore hands the card a general-purpose console.
Marius Muench, assistant professor in computer science at the University of Birmingham, said in the university’s announcement of the work that the SIM’s proactive capability and the attack surface it opens are “explicitly defined in the technical specifications for cellular communication”, which is why he frames the result as compliant with the standard rather than a break from it.
That framing matters for what a fix looks like. The individual flaws are ordinary bugs and can be patched; the interface that exposes them is a documented capability, and switching it off is a decision each vendor makes for its own products.
Architecture is what makes the IoT side worse. Nearly every module the team examined runs a small application processor alongside the radio, usually Android on an ARM Cortex-A7, and passes up any AT command the radio does not handle itself. The card ends up talking to a little Linux computer, which their paper, presented this week at USENIX WOOT in Baltimore, calls “a rich attack surface to hostile SIMs.”
The charger is a commercial Autel unit that the paper identifies by the model code MAXI US AC W12-L-4G. Inside it, the Quectel EC25AFXDGA module’s atfwd_daemon passes attacker-controlled text into a shell call through an unsafe format string. A character blocklist was supposed to stop shell escapes. A newline got past it. Two stages later, the team had code execution, driven entirely by commands the SIM issued. Autel is not among the companies the write-up says were notified; the flawed code belongs to the module. Muench told The Hacker News the team disclosed to Quectel as the module vendor, which then notified its own customers.
On an OPPO Reno 14 F 5G, one of the three handsets that accepted RUN AT, the command AT+COPS=0,,,0 pinned the phone to 2G. The owner cannot undo it. Not by toggling airplane mode, not by switching to manual network selection, not by toggling mobile data, not by disabling the SIM, not by changing the preferred network generation in settings. 2G has no mutual authentication, so a downgrade the victim cannot reverse hands an attacker the conditions for a fake base station.
Two further commands powered the handset down and shut off the modem. The team’s tooling, released as CATana, found 198 AT commands reachable through the SIM on that OPPO handset.
A third case study read arbitrary files off a Quectel EG25-G by way of a TFTP daemon that runs as root and does not check whether a path is a symbolic link, then mailed them out using the module’s own AT+QSMTP commands. That one needs more than a hostile card: the malicious link has to be sitting on the module’s filesystem first, put there via an SD card or by flashing a crafted partition.
While building up to this work, the group showed that a hostile SIM could make a locked Android phone open an attacker-controlled web page with no user interaction, on Pixel 6, 8 and 9 among others. Google patched that separate flaw as CVE-2025-48618 in the December 2025 Android bulletin.
The survey establishes only what its 26 devices do. Muench said the team is fairly confident every module in Quectel’s EC25, EG25 and RM52xN series is affected, and thinks it likely that other Quectel modules built on a Qualcomm modem are too. He said those modules turn up in cars, vehicle chargers, payment terminals and other IoT devices, and that Quectel does not release firmware updates publicly, which makes the exposure hard to verify at scale. Nobody has put a figure on how many are in service.
The reports went to Google, Oppo, Quectel, Semtech and Qualcomm in March 2026, and to the GSMA in May. Muench said the exposed SIM AT interface is tracked as CVE-2026-57550, assigned through Qualcomm, and as CVD-2026-0122 by the GSMA, though the CVE record has yet to appear in the CVE Program’s published list. Oppo and Google treated the findings as informative but outside their bug bounty scope.
Semtech confirmed them and plans to ship patches written by Qualcomm. Quectel confirmed them too, and said the command injection was already known and fixed in newer firmware, though it has not published affected or fixed version numbers.
The same daemon has prior history: an AT-reachable command injection at a different entry point was published in 2021 as CVE-2021-31698. As of August 10, none of the five vendors had issued a public advisory on the research, Quectel’s advisory portal remains login-gated, and no exploitation has been reported.
