On 31 August, a researcher at Calif published the first part of a series that does something Android’s security model is supposed to make expensive. It takes an ordinary third-party app, with no declared permissions, to a root shell on a bootloader-locked Samsung Galaxy S26 running July 2026 firmware. Then it does the same thing on a Xiaomi 17, an Oppo Find X9 Ultra and a OnePlus Ace 6 Ultra, using one repeatable strategy. The part that should concern you is not the root shell. It is the three lines printed beside it.
TL;DR
- Calif’s OEMpocalypse chains take an unprivileged Android app to root on fully patched, bootloader-locked Samsung, Xiaomi, Oppo, OnePlus and Realme flagships, using a single repeatable strategy.
- Every bug involved sits in OEM-written kernel code rather than upstream Linux or the chipset vendor’s drivers, so the Android security patch level your MDM enforces does not describe the affected surface.
- Throughout the compromise the device still reports verified boot green, bootloader locked and VBMeta locked, because those signals attest to the boot chain, not to the running kernel.
- Hardware-backed keys are not extractable by root, but they are usable by it, so a valid signature stops being evidence that your app asked for one.
- The strategy is public and the per-OEM technical write-ups are not, so the useful work this quarter is moving decisions off the device rather than tightening client-side checks.
One strategy, three OEMs
Every third-party app on Android runs under its own UID, inside the untrusted_app SELinux domain, behind a seccomp filter. Those three mechanisms together define how much kernel an app can even touch: a trimmed syscall surface, Binder, shared memory and DMA buffer heaps, the GPU driver, and a tail of chipset-specific and OEM-specific device nodes.
That tail is where the research goes. The stated yardstick is an exploit that is reliable, portable and universal, and generic Linux bugs score badly on the last two in practice: what survives years of upstream auditing tends to be a constrained slab-level primitive that has to be re-tuned per kernel version, per OEM patch set, and per device, because RAM size and core count alone shift allocator behaviour. Chipset drivers have the opposite problem, splitting coverage along vendor lines.
So the strategy targets code the OEM wrote: a page use-after-free in an OEM kernel driver, reached, where the OEM’s own SELinux policy gates that driver, through an OEM-specific sandbox escape first. A page use-after-free leaves a live mapping onto a physical page after the kernel has released it. That is a read and write primitive over whatever the page allocator hands out next, and it sits underneath most of the last few years of Android kernel hardening: slab freelist protections, KASLR and control-flow integrity are largely aimed at slab corruption and control-flow hijacking, and this bug class needs neither an information leak nor a hijack.
The researcher’s own verdict on the bugs is the uncomfortable part. None of them were subtle. Each is a page-lifetime mistake that a focused review of the driver would likely have caught, and none of the drivers gave the impression of having been written with an adversarial caller in mind.
The line that did not change
Each demo prints the app’s context before the exploit and the same block after it. Afterwards it reads uid=0(root), SELinux permissive, and then the three lines that matter: verified boot green, bootloader lock 1, VBMeta state locked. A stock signed image, a locked bootloader and a fully compromised kernel, all true at the same moment.
Nothing in the chain has to make those signals lie, because they answer a different question. Verified boot is a statement about what was loaded during boot and who signed it. It says nothing about what the kernel is doing forty minutes later. The attestation is accurate and irrelevant simultaneously, which is the worst combination a security signal can have.
This is the load-bearing consequence for anyone shipping software onto handsets. Device-integrity verdicts consumed by your mobile app, and the compliance posture your MDM reports back to the console, are built on boot-time evidence plus a reported patch level. A runtime kernel compromise on an otherwise stock device is orthogonal to both, so a green verdict is not a claim that the device is uncompromised. It is a claim that the device booted an image somebody legitimate signed.
Client-side root detection fares worse still. The usual libraries hunt for Magisk, stray su binaries, unexpected mounts and test-keys builds. A chain that needs none of those leaves nothing of that shape to find, and the code doing the looking is running at lower privilege than the thing it is looking for. Root detection is a speed bump for casual tampering, priced accordingly.
Your patch policy measures somebody else’s number
The Android security patch level is a date published by Google. The bugs in this series live in OEM drivers and OEM userspace IPC, which have their own repair cadence: Samsung tracks its own items in monthly bulletins, and visibility at Xiaomi and across the Oppo family is thinner again. The tested devices ran Android 16 on kernels between 6.12.23 and 6.12.58, on the latest firmware available in early August 2026. Fully patched was the starting condition, not a mitigation.
Which makes “every device at patch level N or later” a necessary fleet rule that does not cover this class of bug at all. The honest version adds three questions: which OEMs are we actually exposed to, what support window has each committed to in writing, and where would we find out that an OEM driver bug had been fixed. For most teams the answer to the third is nowhere. That makes the OEM kernel layer a dependency with no advisory feed, no version you track and no agent you can install, which is the same shape of problem we described in appliance firmware. Phones are that dependency with a better screen and your users’ credentials on it.
What root actually buys an attacker
A rooted kernel reads every app’s private data directory: cached access tokens, offline databases, session cookies, queued uploads. Android’s work profile is a separation boundary the kernel enforces, and root sits underneath it rather than beside it, so “it is in the work profile” stops being an answer at exactly the point you need one.
The keystore deserves precision, because it is where most teams put their confidence. Keys held in the TEE or a StrongBox secure element are not extractable by a compromised kernel. They remain perfectly usable by it. Passkeys, push-approval MFA and device-bound refresh tokens all survive as keys and all produce signatures on request. What you lose is not the secret, it is the inference: a valid signature no longer implies that your app requested it, with your user’s knowledge, on a device behaving normally. If your threat model treats the handset as an independent second factor, independence is precisely what the chain removes.
Six things worth doing before the technical write-ups land
- Inventory the decisions made on the device. Entitlements, limits, pricing, feature gates, validation. Anything a client can be persuaded to misreport should be re-decided server-side by something that cannot be.
- Re-grade your integrity signals. Integrity verdicts and root detection belong in a risk score alongside behavioural signals, never as a single gate whose pass result grants access.
- Shorten what is worth stealing. Short-lived access tokens, server-side refresh, no long-lived secrets in app storage, step-up re-authentication for high-value actions, and no offline cache of data whose loss you would be legally obliged to report.
- Stop counting one device as two factors. For transactions that would genuinely hurt, require confirmation through a channel the handset does not control.
- Make the fleet question OEM-shaped rather than version-shaped. Which manufacturers, what committed support windows, and what your policy says when a model leaves support mid-contract.
- Detect server-side. Device-attribute drift, impossible travel, new signing keys, session anomalies. These survive a lying client, because nothing on the compromised device gets to edit them.
The window is somebody else’s editorial calendar
Part one sets out the strategy. Parts two, three and four, the per-OEM chains with the technical detail, are not published yet. That gap is the whole window, and its length is a decision nobody in your organisation gets to make. None of the six items above needs the exploit details, which is rather the point: every one of them is an architecture change, and architecture changes take considerably longer than a patch cycle.
If you ship a mobile app, run a BYOD estate, or treat a handset as a second factor, REPTILEHAUS can review where the trust actually sits in your stack and move the decisions that matter off the device. Get in touch.
📷 Photo by Jametlene Reskp on Unsplash
