BALTIMORE, 11 AUG 2026 — A SIM card can tell the phone it is sitting in to shut down, to drop off 5G and reconnect on 2G, or to open a browser while the screen is locked. None of that is a bug. It is what the cellular specifications say a SIM is allowed to ask for.

Researchers from the University of Birmingham and the security firm Fuzzware presented that finding at the USENIX WOOT conference in Baltimore this month, in a paper called CATana: On the Dangers of SIM-Originating AT Commands.

What the paper actually measured

Tomasz Piotr Lisowski, Kristian Covic and Marius Muench built a toolkit, CATana, to investigate the RUN AT command, which lets a SIM ask its host device to execute an AT command.

AT commands are the instruction set used to drive modems, and they date to the 1980s. They can dial, configure the radio, read files and, on some devices, a good deal more. The RUN AT command effectively hands the SIM a console on the modem.

26 devicesSurveyed: 18 smartphones and 8 IoT devices.
9 exposedDevices exposing the SIM AT interface.
4 vulnerabilitiesDiscovered through that interface.
4 impactsCommand execution, arbitrary file read, 2G downgrade, denial of service.

Those are the numbers in the paper's own abstract, and they are worth stating plainly because the secondary coverage has not been consistent about them. The abstract says the team surveyed 26 devices and found that nine expose the interface. It does not report a separate per-category count.

Why "specification-compliant" is the uncomfortable part

As Muench put it, "The proactive capabilities of a SIM and the resulting attack surface is explicitly defined in the technical specifications for cellular communication."

Most vulnerability research finds an implementation that departs from its specification. This finds implementations that follow one. A device exposing the SIM AT interface is doing what the standard permits, which means there is no patch that makes the behaviour wrong — only decisions to narrow, harden or switch off a capability that the written rules still bless.

That is a slower kind of fix. A vendor can ship a patch in a week. Deprecating a capability across an ecosystem of carriers, module makers and integrators takes years, and every device already in the field keeps the old behaviour until it is replaced.

What an attacker needs first

The precondition for these attacks is a serious constraint, not a footnote: the attacker must control the SIM itself.

The researchers list the plausible routes: compromised SIM software, physical tampering, a malicious or breached operator with remote administration rights, or a supply-chain compromise. None is available to somebody who merely knows your number, and none is remote in the way a network attack is remote.

So the threat model is not "anyone can do this to any phone". It is closer to what we described when Poland's energy sites were reached through a private mobile network: the cellular layer is administered by somebody, and whoever administers it has reach that the device owner never granted and cannot see.

The demonstrations

According to The Register's account of the presentation, the team found 198 AT commands and variants reachable through the SIM interface on an Oppo Reno14 F 5G, including commands to power the handset down or force it onto 2G. Attempts to undo that downgrade by toggling airplane mode, disabling the SIM or changing network settings all failed.

They also reported command execution on an Autel electric-vehicle charger built around a Quectel EC25-AFX module, and file exfiltration by email from a Quectel EG25-G, using a malicious symbolic link in combination with SIM-issued commands.

A separate flaw, CVE-2025-48618, let a malicious SIM invoke the LAUNCH BROWSER command on Android 13 to 16 without user consent, including on a locked device. Google patched it in December 2025. The GSMA is tracking the broader interface question as CVD-2026-0122, and Qualcomm has produced a hardened configuration that disables the SIM AT interface by default.

The 2G downgrade is the one to think about

Of the four demonstrated impacts, the forced downgrade has the longest tail.

2G's cryptography was broken in public a long time ago, and its base stations do not authenticate themselves to handsets. That is the property every IMSI-catcher relies on. A device that can be pushed onto 2G and kept there has had its transport security removed, quietly, without any indication a user would recognise as an attack.

Denial of service is loud and gets investigated. A downgrade looks like poor coverage.

Where this actually bites

The researchers' own summary is that "modern smartphones appear to have largely got the memo", while "the IoT world still has some hanging up to do".

This distinction is where the risk lies. Cellular IoT is how an enormous amount of infrastructure reports in — utility meters, fleet trackers, payment terminals, agricultural sensors, EV chargers — and those devices are chosen on module cost, deployed in the thousands, and replaced on a decade-long cycle if at all. The two case studies that produced code execution and file theft were both module-based devices, not phones.

For anyone running a fleet like that, the question the paper raises is not "are we patched". It is "who can write to our SIMs, and would we know if they had". SIM estates are usually administered by the mobile operator or an IoT connectivity reseller, under a contract nobody reads as a security boundary.

What to watch

Whether the GSMA's CVD-2026-0122 process produces a specification change rather than guidance. Guidance leaves the capability in the standard and makes disabling it optional, which is how it survived this long.

Whether module vendors adopt Qualcomm's default-off posture. A hardened configuration that exists is not the same as one that ships.

And whether any operator publishes what its SIM remote-administration access can actually do. That capability is the precondition for all of this, it is held by a third party in every deployment, and it is almost never described in a security review.