If you have spent any time worrying about phone security, you have almost certainly worried about the wrong layer. Malicious apps, phishing links, dodgy Wi-Fi hotspots: all reasonable concerns, all addressed by settings you can actually change. Nobody ever told you to worry about the little gold-contact card sitting under your battery tray, because nobody imagined it needed worrying about. A paper presented on August 11, 2026 at USENIX WOOT, one of the most respected offensive security venues in the world, makes the case that this was an oversight, not an omission.

cover

In brief

  • Researchers from the University of Birmingham built a toolkit called CATana to test how far a SIM card can push commands onto the device it sits in.
  • The mechanism is Proactive SIM, a legitimate feature of the cellular spec (3GPP TS 31.111, ETSI TS 102 223) that lets a SIM issue a RUN AT command, executed directly by the modem using the decades-old AT command language.
  • Out of 26 tested devices (18 smartphones, 8 cellular IoT modules), the team found 4 exploitable vulnerabilities, including forced 4G-to-2G downgrades, silent lock-screen browser launches, file exfiltration, and code execution on a modem’s application processor.
  • Google fixed the Android lock-screen browser bypass as CVE-2025-48618 in the December 2025 security bulletin; Qualcomm has shipped a configuration that disables the vector by default.
  • The researchers argue that patching individual bugs is not enough. They want RUN AT deprecated and stripped out of firmware entirely.

A command channel nobody expected to defend

The interface at the center of this research is called the AT interface, named after the AT (ATtention) command set that Dennis Hayes and Dale Heatherington designed in 1981 to control the Hayes Smartmodem. It became the universal control language for modems, and it never really left: your phone’s baseband processor still speaks it internally, decades after anyone last heard a modem’s dial tone.

Normally the flow runs one way. The phone queries the SIM to authenticate you on the network, fetch your contacts, or read carrier settings. Proactive SIM commands invert that relationship: they let the card initiate a request toward the device instead of just answering one. This is a documented part of the standard, specifically Section 6.4.23 of 3GPP TS 31.111, which defines the RUN AT COMMAND that lets a SIM ask the terminal to execute an arbitrary AT command. As Dr. Marius Muench, one of the paper’s authors, put it in the University of Birmingham’s writeup:

“What people don’t realise is that SIM cards are tiny computers. They don’t just store secrets to access the network; they can directly interact with the phone. And there is a full specification defining what a SIM is allowed to request from the phone.”

Most phones filter this channel or ignore it outright. The point of CATana, the toolkit built by Tomasz Piotr Lisowski, Muench, and Kristian Covic of Fuzzware, was to stop assuming that filtering works and start measuring it. According to the project’s Zenodo archive, the suite includes CATtty, for driving AT commands into a target through a SIMtrace-connected software SIM, CATlet, for running the same experiments through an applet on a real programmable SIM, and CATauto and CATview for scaling and analyzing the results. It is, in effect, adversarial fuzzing applied to a component the industry has spent forty years treating as inherently trustworthy.

This is not the team’s first pass at SIM security either. The same Birmingham group previously built SIMurai, a software SIM emulator for adversarial testing, and readers of this blog will recognize the general shape of the problem from the WIBattack disclosure covered here back in 2019, when the SIMJacker family of attacks first showed that SIM toolkits could be weaponized over SMS. CATana targets a different direction of the same trust relationship: not “can I attack the SIM,” but “what can the SIM do to me.”

OPPO’s stuck 2G radio and Android’s lock-screen browser

Two results from the paper illustrate why this matters in practice rather than just in theory. On the OPPO Reno 14 F 5G, which according to Help Net Security’s coverage accepted 198 distinct AT commands and variants through the SIM interface, a proactive command can force the phone’s connection down to 2G, the standard that shipped in the 1990s and never got proper mutual network authentication. That gap is exactly what makes 2G a favorite for rogue base station attacks, the same weakness this blog covered when looking at how smartphones react to IMSI catching. What makes the OPPO case worse is persistence: the downgrade survived airplane mode, disabling the SIM, and manually changing network settings. There is, at the time of writing, no user-facing toggle that undoes it.

On Android more broadly, a proactive command called LAUNCH BROWSER let a hostile SIM open an attacker-chosen URL even on a locked screen, with zero user interaction. Google tracked this as CVE-2025-48618, an elevation-of-privilege flaw in processLaunchBrowser inside CommandParamsFactory.java, and fixed it in the December 2025 Android security bulletin, covering Android 13 through 16. The CVSS score sits at a modest 6.8, largely because the attack requires physical access to swap or control the SIM, but modest CVSS scores have a way of undercounting real-world impact when the access requirement is “steal the phone,” which is precisely the scenario a locked screen is supposed to defend against in the first place.

Beyond phones: EV chargers and the Quectel problem

The most interesting result may not be about phones at all. The team achieved code execution on an AUTEL EV charger built around a Quectel EC25-AFX cellular module, chaining a SIM-issued command injection flaw in the modem’s Linux-based application processor into full control of the module. Quectel modems are not exotic; they turn up in industrial routers, telematics units, and automotive control systems well beyond EV chargers, which is why the disclosure list for this research includes Google, OPPO, Quectel, Qualcomm, and Semtech. Qualcomm has already published a configuration that disables the vulnerable channel by default, a mitigation that will quietly protect a much larger population of devices than the headline phone examples suggest.

The reasoning behind why IoT devices are especially exposed is almost mundane: an EV charger or industrial router typically has no USB port, no exposed debug header, nothing an attacker can plug into from outside. It does, however, always have a SIM slot, because cellular connectivity is the whole point. On a device engineered to minimize its attack surface, the SIM interface becomes the one gap nobody closed, precisely because it was assumed to be the trusted anchor rather than a possible entry point.

Four ways a SIM turns hostile

None of this works unless someone controls the SIM in the first place, and the researchers are explicit that this is not a single failure mode. They describe four realistic paths: exploiting a vulnerability in the SIM’s own software (the SIMJacker lineage), physically swapping or tampering with the card, abusing an operator’s remote SIM-management infrastructure, and tampering during manufacturing or distribution before the SIM ever reaches a user. The SIM swap scenario in particular overlaps with fraud patterns this blog has already flagged as a trigger for stronger authentication checks in the contactless payment security piece, where anomalous SIM activity is listed as a signal that should force step-up verification on financial accounts. A hostile SIM is a tracking risk and a lever that touches whatever else trusts “this is still your phone number.”

The GSM Association has assigned the overall issue tracking number CVD-2026-0122, and several manufacturers have already shipped patches or hardened default configurations in response to the disclosure. But the researchers, in comments to Help Net Security, are not asking for a patch-by-patch cleanup. Kristian Covic called hostile SIMs “an overlooked attack vector,” and the team’s stated recommendation is blunter than a bug bounty payout: deprecate RUN AT entirely and remove the supporting code from modem and device firmware, rather than leaving it dormant behind a filter that the next firmware regression might quietly disable. Lisowski’s own framing leaves little room for complacency: “the attacks we found only scratch the surface of what is possible with hostile SIM cards.”

For years the security advice aimed at ordinary users has been about apps and links: don’t click that, don’t install this. Nobody thought to add “don’t trust the little card the carrier gave you,” because that card was supposed to be the one component the phone could trust unconditionally. CATana is a useful reminder that in security, the components everyone stops questioning are usually the ones worth questioning again.

FAQ

What is a proactive SIM command? It is a mechanism defined in the cellular specifications (3GPP TS 31.111 and ETSI TS 102 223) that lets a SIM card send instructions to the phone, instead of only answering the phone’s requests. RUN AT is one of these commands, and it tells the modem to execute an AT command chosen by the SIM.

Is CVE-2025-48618 fixed? Yes. Google patched it in the December 2025 Android security bulletin for Android 13 through 16. The flaw let a hostile SIM trigger the LAUNCH BROWSER proactive command and open an attacker-controlled website even on a locked screen, without user interaction.

Can I protect myself from a malicious SIM card right now? Update your phone to the latest security patch, avoid inserting SIM cards from untrusted sources, and be aware that a physically stolen or swapped device may retain SIM-level access even after a factory reset of the OS. There is no user-facing setting to disable the AT interface on affected devices.