OEMpocalypse roots Android with an app that has zero permissions

August 31, 2026. Researcher Lukas Maar publishes OEMpocalypse, the first part of a series that elevates any permissionless Android app to root. July 2026. The stock firmware he tested on — locked bootloader, Verified Boot enabled — is the firmware your users carry today. Two weeks. The time it took for public exploit tools to appear on GitHub. Why it matters: the attack does not target the mainline Linux kernel, but the code Samsung, Xiaomi and Oppo add on top — a surface Google never reviews.

The bug lives in the code vendors add

The core flaw is a page use-after-free in OEM-specific kernel drivers — the code Samsung, Xiaomi and Oppo write for their own product features: camera processing, display calibration, thermal management, proprietary IPC. Those drivers live inside One UI, HyperOS and ColorOS, outside AOSP and outside Google’s security review.

A use-after-free means the kernel keeps a live pointer to a physical memory page it has already freed, letting an attacker write to memory they have no business touching. The attack runs in two stages. First, the app exploits a logic flaw in OEM IPC endpoints — Binder calls, intents, content providers — to escape the SELinux untrusted_app domain into a privileged OEM process. Second, it triggers the page use-after-free for arbitrary read/write at the physical memory level, which translates directly to root.

The detail that unsettles: the exploit requires no KASLR leak and hijacks no control flow. Standard kernel hardening — slab protections, CFI — is irrelevant to this chain. Worse, the vulnerable page-reclamation code runs unchanged across kernels 5.15 through 6.12, and each OEM skin carries its own instance of the same bug class.

What breaks, and what still holds

The impact is precise, and worth reading without exaggeration.

What breaks. The Android permission model is out of the picture: zero permissions required. FLAG_SECURE windows and EncryptedSharedPreferences offer no protection against a co-installed malicious app reading memory directly. And root detection itself is blind: the public GhostLock and Root-My-Galaxy tools, which weaponize CVE-2026-43499, run through KernelSU, designed specifically to pass Play Integrity and SafetyNet checks. Your root-detection probe sees nothing.

What still holds. Hardware-backed KeyStore and StrongBox keys. Because they live in a dedicated secure element the kernel cannot read — even with root — hardware-backed attestation is now your last meaningful line of defense on affected devices. Any app that stores credentials or health data must verify it is using hardware-backed key storage, not software-backed.

The most disorienting point is elsewhere: Verified Boot stays green throughout the attack. The device-integrity checks your MDM policy leans on attest to the boot chain, not the running kernel. A phone compromised after boot keeps presenting a “healthy” attestation.

The patching blind spot

Samsung shipped its September 2026 security patch on September 8, fixing 90 vulnerabilities. But the notes do not explicitly list OEMpocalypse or CVE-2026-43499. Community reports suggest the GhostLock tools only work on June 2026 firmware or earlier — yet Maar’s research ran successfully on July 2026 firmware. That gap has not been publicly explained.

Xiaomi and Oppo have issued no statement. And this is only part one of a series: later installments will name the specific OEM kernel drivers. “Keeping the set alive is real ongoing work,” Maar notes — a line that reads less like a researcher’s caveat than a warning that piecemeal patches will not close the door.

Why this is structural, not a one-off

This is not a Qualcomm bug, nor a Linux kernel bug. It is a bug in code Samsung, Xiaomi and Oppo wrote to ship product features. Every OEM customization that touches the kernel is attack surface that bypasses Google’s review entirely. That is the cost of the “differentiate through software” model: more in-house features, more unaudited kernel code.

Android Sandbox 3.0, coming with Android 17 via per-app Linux namespaces, may tighten the SELinux escape vector on future devices. It does nothing for the hundreds of millions of Galaxy S23–S26 and Xiaomi flagships already in circulation.

What this changes for your fleet policy

For a CISO running a mobile fleet, the conclusion is operational, not theoretical:

• Stop trusting root detection. It is bypassed by KernelSU and detects neither OEMpocalypse nor its public tools. A “not rooted” check no longer proves anything.
• Require hardware attestation. The only thing that resists is a hardware-backed StrongBox/KeyStore key. Verify that your critical apps use hardware-backed key storage, and push vendors who do not.
• Treat vendor patches as incomplete. Samsung’s September patch does not confirm it covers the chain. Without explicit confirmation, treat Galaxy S23–S26 on July firmware or earlier as exposed.
• Watch the rest of the series. Part one does not name the drivers; the follow-ups will, and will likely widen the list of affected vendors.

Why standard hardening is not enough

The OEMpocalypse chain has a rare property: it does not depend on any of the primitives modern hardening tries to break. There is no KASLR leak to close, no ROP to defeat, no CFI to bypass. The attacker reads and writes physical memory directly, which short-circuits stack, slab and control-flow defenses in a single move.

That is why piecemeal patches will not be enough. As long as OEM drivers run unaudited kernel code, the bug class — a page use-after-free in a proprietary driver — will keep recurring, because vendors rewrite the same kind of code for every device generation. Samsung’s September patch can plug one specific driver; it does not plug the model that produced that driver.

For a CISO, the consequence is a shift in paradigm: on an Android device, the trust boundary is no longer “the app is sandboxed” but “the key is in the secure element.” Anything not backed by that hardware should be treated as readable by an attacker who has already rooted the phone without tripping a single alarm.

The practical casualty is the everyday security theater around mobile apps. Play Integrity verdicts and SafetyNet attestations are widely used to decide whether an app gets access to sensitive flows — payments, banking, corporate SSO. When those verdicts can be satisfied by a rooted device running KernelSU, they stop being a security boundary and become a speed bump. The only signal left with any teeth is an attestation anchored in a hardware-backed key, and even that only proves the key exists — not that the running kernel is trustworthy.

Verdict

OEMpocalypse makes explicit a truth the Android ecosystem has sidestepped for years: vendor kernel code is an unaudited attack surface, and integrity attestation does not cover the running kernel.

If your fleet includes Samsung Galaxy S23–S26, Xiaomi flagships or Oppo/OnePlus/Realme devices, stop treating “not rooted” as a security signal and move your checks to StrongBox hardware attestation. If you ship an Android app, move every piece of sensitive data to hardware-backed key storage — EncryptedSharedPreferences and FLAG_SECURE are worthless against a co-resident app with memory-level root. And if you own compliance, demand written confirmation from vendors that their September patch covers the chain, instead of assuming a “90 vulnerabilities” bulletin includes it.

References

• calif.io — OEMpocalypse, Lukas Maar (full research)
• Reptile Haus — Verified Boot Said Green. An App With No Permissions Had Root.
• Cybernews — Android OEM software vulnerabilities let apps root phones
• eSecurityPlanet — Samsung September 2026 Galaxy security update
• Android Security Bulletin — September 2026