Bitdefender Labs has published research on a family it calls Midnight Mimosa: malware that arrives in the firmware of cheap Android phones, before anyone has installed anything.

The component poses as a core part of the operating system. It is a platform-signed system app named com.android.system.lite, labelled simply "System", with sibling builds under similar names. Bitdefender found it on low-cost, multi-brand handsets built on MediaTek chipsets.

What it can do, and why the position matters

Being in the system partition is not a detail of where the file sits. It is the whole capability.

The component holds INSTALL_PACKAGES, DELETE_PACKAGES, GRANT_RUNTIME_PERMISSIONS and WRITE_SECURE_SETTINGS. In plain terms, it can install software, remove software, and grant that software whatever permissions it wants, without asking and without appearing to.

Bitdefender describes one touch that is almost comic in its directness: before installing a payload, the malware disables the Play Store, and re-enables it afterwards. Installer records were also found falsely attributing apps to Google Play, so a user checking where something came from is told it came from the store.

The payloads run ad fraud — fabricated impressions and clicks — and turn the handset into a residential-proxy relay node, which is rentable infrastructure and usable for denial-of-service traffic. The component also declares Accessibility, Notification Access and SMS permissions, and switches the first two on itself. Bitdefender says it did not observe those being used, which is worth stating precisely: the capability is present and the use is not evidenced.

The owner cannot remove it

This is the part with no good answer.

The component ships in the system partition, so there is no uninstall. Bitdefender's own assessment is that clearing it needs firmware-level work or disabling the component over ADB, and that this is not realistic for most people.

A factory reset restores the firmware, which is where the malware is. The remedy for a compromised phone is, for almost every owner of one, not to own it.

Who is responsible, and the caveat Bitdefender puts on its own finding

Bitdefender traced the platform signing key to a named Shenzhen manufacturer, and then did something coverage of this kind often does not: it said what that does and does not mean.

Bitdefender states plainly that identifying the holder of a signing key does not constitute proof that the company wrote the malware, distributed it, or knew about it. It also says it cannot determine where in the supply chain the code is added — it could be an ODM, a firmware integrator, a logistics partner, or someone else entirely. And it notes the infection is not confined to firmware signed with that key.

We are not naming the key holder here for the same reason. A signing key identifies who signed a build, and builds pass through hands.

Two handset models are named as the highest-volume ones, associated with two budget brands. Many of the other device strings Bitdefender saw are counterfeit flagship names — spoofed versions of well-known Samsung and Apple model numbers — which the firm describes as spoofing indicators rather than a list of affected devices. Anyone reading a device name out of this dataset is reading what the firmware claims, not what the phone is.

Scale, and the thirteen apps in the store

Bitdefender reports thousands of unique devices across more than 150 countries over roughly a two-year window, led by Mexico, France and Italy, then the United States, Germany, Brazil and Spain.

Separately, thirteen apps on Google Play carry the same ad-fraud family markers and talk to the same servers, loading and displaying ads outside the app. The thirteen packages use thirteen different signing certificates across at least two developer accounts, with the rest unresolved — which is what deliberate separation looks like rather than a careless developer.

Bitdefender does not say whether Google has removed them.

Bitdefender keeps two questions apart in its attribution: whoever inserts the code into firmware, and whoever operates the ad-fraud payloads, are tracked as different actors. The payload operator is linked through shared domains to families other vendors have tracked since 2021.

What to do

  • For detection, Bitdefender's advice is to key on the shared core — a particular native library, a common class path and one command server domain — rather than on package names, which rotate.
  • For buyers: a handset sold far below the cost of its components is a handset whose margin is coming from somewhere. That is not a moral judgement about cheap phones; it is a question worth asking about a specific one.
  • For organisations with any bring-your-own-device policy: this is the category that policy cannot inspect. A phone that arrived compromised passes every check that assumes a clean baseline.
  • The durable fix is not a user action. It sits, as Bitdefender says, with the vendors and marketplaces shipping and selling the firmware.

What is not established

  • Where in the supply chain the code is inserted, and by whom.
  • Whether the company whose signing key appears on the builds knew anything about it. Bitdefender explicitly declines to claim this.
  • The real number of affected devices. Thousands is what one vendor's telemetry saw, not a census.
  • Whether Google has removed the thirteen Play apps, or acted on the developer accounts.
  • Whether the declared Accessibility, notification and SMS permissions have ever been used for anything.