Targeting the manufacturer layer

A security researcher has detailed a strategy for taking an unprivileged Android application to root access by concentrating on code and security policies added by phone manufacturers. The work, published as the first part of a series called OEMpocalypse, describes three exploit chains covering devices from Samsung, Xiaomi and the related Oppo, OnePlus and Realme families.

Third-party Android applications normally run under separate user identities in a restricted security domain known as untrusted_app. Standard Unix permissions, Android's SELinux mandatory-access controls and system-call filtering collectively limit the kernel interfaces an application can reach. The researcher's method looks for weaknesses in manufacturer-specific components inside that boundary and, where necessary, uses a separate sandbox escape to reach a vulnerable driver.

At the centre of the approach is a page use-after-free flaw in an OEM kernel driver. This class of memory-safety bug leaves a live reference to a physical memory page after the kernel has released it. If an attacker can reliably control what replaces the freed page, the dangling reference may become a route to greater privileges. The published strategy pairs that primitive with manufacturer-specific access paths instead of relying on one generic Linux-kernel bug across every handset.

The researcher said the resulting chains cover Samsung Galaxy S23 through S26 flagship models and recent Z-series phones, a broad range of Xiaomi mid-range and flagship devices, and recent flagship devices sold by Oppo, OnePlus and Realme. A demonstration showed the Samsung chain running on a bootloader-locked Galaxy S26 Ultra. Exact exposure can vary by model, software release and configuration, so those coverage claims should not be interpreted as proof that every unit remains vulnerable in its current state.

Portability versus universality

The project frames exploit engineering as a balance between reliability, portability and universality. A flaw in shared Linux or Android Common Kernel code may exist across many brands, but turning it into stable root access can require extensive adjustments for kernel versions, vendor hardening and hardware differences. Modern Android phones in the research span kernel branches from 5.15 to 6.12, while memory size, processor count and manufacturer patches can all affect exploitation.

OEM-specific bugs have a narrower conceptual scope, yet they can offer more controllable memory primitives and can sometimes be adapted across product lines that reuse manufacturer code. The research applies the same overall playbook three times rather than claiming that identical exploit code works unchanged on every device.

The disclosure also highlights why Android's layered sandbox remains valuable even when vulnerabilities exist. An attacker must connect multiple weaknesses and navigate device-specific policy before reaching privileged kernel functionality. Conversely, code added below or alongside those layers can create attack surfaces that are not uniform across the Android ecosystem.

This first instalment focuses on the research strategy and comparison with generic-kernel alternatives. Later posts are expected to provide technical details of the individual chains. Until vendor advisories and patch status are established, users should keep device software current and avoid treating the demonstration as evidence that a particular fully updated phone can be compromised by any arbitrary application.