A malicious SIM card can do more than identify a subscriber. In recent research, investigators demonstrated that a hostile SIM can instruct compatible cellular modems to execute attacker-chosen commands, effectively turning parts of the device behind cellular IoT hardware into a controllable target.
Because machine-to-machine deployments often rely on hardware that ships with always-on cellular connectivity, this capability raises operational risk for organizations running chargers, routers, telematics units, and other connected equipment. The study also points out that the first step in the attack is not remote: someone must place the SIM in the slot, introduce it as an interposer, or otherwise get the malicious card into the trust path.
What Malicious SIM Code Execution looks like
The core idea is based on a standard modem feature. A SIM can send “proactive commands” to the modem, rather than waiting for the modem to read information from the SIM. One such command, referred to as RUN AT, asks the modem to execute an AT command—the classic command language used to control modems.
AT commands are old, widely supported, and extended by vendors. That matters because enabling a generic command execution pathway gives a hostile SIM a practical, general-purpose console into the modem control plane. Even when the vulnerability is “ordinary” at the code level, the interface becomes the multiplier that turns a bug into a working exploitation path.
Which devices accepted the proactive SIM command
To explore real-world exposure, researchers tested 26 phones and cellular modules. The RUN AT capability turned on in 9 of them and was used to run proof-of-concept code on a commercial EV charger.
They found that 6 of 8 cellular modules they evaluated accepted the command. On the handset side, only 3 of 18 phones accepted it: OPPO Find X5, OPPO Reno 14 F 5G, and ASUS Zenfone 9. No iPhone or Pixel models were among the accepting devices in the survey.
The study indicates that exposure is primarily tied to machine-to-machine cellular hardware rather than consumer phones. In particular, Quectel modules accounted for five of the six accepting modules, including modules pulled from an EV charger, an industrial router, and a vehicle telematics control unit.
Why attackers need more than the victim’s phone number
Importantly, the researchers emphasize that knowing the victim’s number is not enough. The attack begins with access to the SIM inside the device. That access can come from swapping the SIM by hand, slipping in a thin interposer, using a compromised operator process, or introducing a hostile SIM through software or production-line tampering.
For unattended IoT equipment, a SIM tray that is physically reachable—and coupled with fewer other exposed interfaces—creates a tradeoff that can make the attack worthwhile. In other words, the “entry point” is physical or operational rather than purely remote.
No single patch: the problem spans interface and implementation
The findings suggest there is not one simple, universal fix that solves everything. Instead, two layers matter:
- The interface exposure—whether the modem leaves the proactive SIM command path enabled.
- The implementation flaws—bugs in how the modem-side software handles the resulting AT command execution.
All nine devices that accepted RUN AT run a Qualcomm communication processor. Still, not every Qualcomm-based handset accepted the interface. The paper’s interpretation is that vendor-specific customization likely changes whether the interface is available.
Vendor responses and status of updates
The researchers report that Qualcomm has built a hardened configuration that disables the relevant interface by default. Quectel said it has mitigated a related file-access issue and continues working on the broader interface behavior.
At the time of writing, neither side had published a publicly visible advisory describing the issue in detail. Additionally, the module-maker’s vulnerability portal appears gated behind login credentials, making it harder for operators to validate scope and remediation without direct vendor communication.
How the attack can impact a cellular IoT device
The study includes examples showing that once the hostile SIM can drive AT command execution, the consequences can range from denial-of-service to deeper compromise of modem-related components.
One case focused on a commercial charger identified by a model code (MAXI US AC W12-L-4G). Inside it, the Quectel EC25AFXDGA module’s atfwd_daemon was able to pass attacker-controlled text into a shell call due to an unsafe formatting behavior. A character blocklist was intended to prevent shell escapes, but the researchers found that a newline could bypass it. After multiple stages, they achieved code execution driven entirely by commands issued by the SIM.
In a handset scenario involving the OPPO Reno 14 F 5G, the RUN AT command enabled a specific AT+COPS=0,,,0 action that pinned the phone to 2G. The researchers state that the owner could not reverse the change through common user controls such as airplane mode toggling, manual network selection, mobile data changes, disabling the SIM, or changing the preferred network generation setting. They link the risk to the fact that 2G lacks mutual authentication, allowing an attacker to set conditions for a fake base station.
They also report additional commands that powered the handset down and shut off the modem. Using their tooling, they identified many AT commands reachable through the SIM on that specific device model.
File access and root-level daemons
Another case study involved a Quectel EG25-G module and a TFTP daemon running as root. The researchers found a path-handling weakness where the service did not properly prevent symbolic-link traversal. With a malicious link already present on the module’s filesystem (for example, inserted via an SD card or through flashing a crafted partition), the hostile SIM could trigger file reads and then exfiltrate data using the module’s own email-related AT command mechanism.
So while RUN AT is the bridge that enables command-driven control, the broader exploitation still depends on how other subsystems handle inputs and filesystem operations.
Connection to earlier Android issues
The work also builds on prior observations. The researchers previously showed that a hostile SIM could make a locked Android phone open an attacker-controlled web page with no user interaction, with affected models including Pixel 6, 8, and 9 among others. In that separate line of research, Google addressed the issue as CVE-2025-48618 in a December 2025 Android bulletin.
In this new research, the key focus is the modem-side proactive SIM interface that can drive modem commands.
Scope expectations: likely broader among certain module families
The survey covers only what 26 devices can confirm. Even so, the lead researcher said they are fairly confident that modules across Quectel’s EC25, EG25, and RM52xN series are affected, and they suspect other Quectel modules built on Qualcomm modems may also be exposed.
They note that these modules show up in cars, vehicle chargers, payment terminals, and other cellular IoT deployments. At the same time, Quectel does not appear to publish firmware updates publicly, which makes it difficult for operators to verify the real-world state across large fleets.
Security identifiers and coordinated reporting
The researchers say the issue is tracked as CVE-2026-57550 through Qualcomm and CVD-2026-0122 by the GSMA, with the CVE record not yet appearing in the public CVE Program list at the time of reporting.
According to the team, they submitted reports to major stakeholders in March 2026 and to the GSMA in May 2026. Some companies treated the findings as informative but outside their bug bounty scope, while others confirmed the problem and planned or discussed fixes.
As of August 10, the research team states that no public advisory had been issued by five named vendors, and no exploitation of the modem interface had been reported.
What operators can do today
Because the interface exposure is vendor-configurable, mitigation may start with contract and supplier communication. The researchers’ recommended immediate action for anyone running cellular IoT fleets is to ask module suppliers two practical questions:
- Whether RUN AT is enabled in the firmware shipped on their modules.
- Whether the interface can be disabled in that product configuration.
Even when updates are forthcoming, the team notes uncertainty about whether the code paths are fully removed or simply switched off. For fleet operators, this distinction matters because it affects risk under future configurations and firmware update behavior.
Conclusion
Malicious SIM Code Execution demonstrates how a legitimate modem feature—proactive SIM control of AT commands—can become dangerous when combined with implementation weaknesses. While exploitation requires a hostile SIM to be present in the device, the practical outcomes can include code execution, denial-of-service behaviors, and connectivity downgrades that may undermine network protections.
For organizations managing cellular IoT assets, the most actionable next step is to validate whether your deployed modules have the proactive SIM interface enabled and to request a path to disable it or apply hardened configurations through the vendor.
Source: https://thehackernews.com/2026/08/a-malicious-sim-card-can-run-attacker.html
