Researcher demonstrates two OxygenOS failures in OnePlus 15 that allow root with local app

A security researcher, Rasmus Moorats, has shown that an OnePlus 15 with the latest version of OxygenOS can be taken entirely by a malicious application that the owner voluntarily installs, even if that app does not request special permits. Moorats chained two failures in OnePlus's own software to climb privileges to root - the highest level of control on an Android phone - and published his findings on September 24 after several months of communication with the company. OnePlus confirmed in May the existence of the two vulnerabilities and stated that similar problems affect more of its models and others of OPPO, although it did not identify which ones.

In technical terms, the operating chain uses two pre-installed OxygenOS services. The first is AtlasService, a service that collects debugging data and, according to Moorats, runs with root privileges and accepts calls from any application without verifying the identity of the caller. A specially built request reaches a cleansing tool that takes text provided by the application and inserts it without sanitation into a system command. That error alone grants root privileges within an area of the system called state; it's a functional but restricted root. The second failure is independent and complementary: a hardware service called olc2 that offers an interface to run shell commands. Your only barrier is to check that the caller already has root privileges. With the first vulnerability you get that root in state, and with the second one you run a command in a context that grants low-level Linux privileges, including the possibility to load code in the kernel. The final result is system-level control over the device.

It is important to note that the attack is local: needs that the malicious application has been installed and is running on the phone; it cannot be remotely launched over the Internet without local interaction. However, the conditions for the app to start the operation are minimal: according to the researcher, it does not ask for special permits or show any notice to the user, and it worked on a serial phone without any modifications.

The facts confirmed in the chronology provided by Moorats are clear: the initial notification to OnePlus was April 18; the company confirmed the failures on May 20 and, in that communication, stated that it would control the disclosure and that the publication without its consent could entail legal responsibility. OnePlus reported that it would schedule a correction, asked Moorats to hold and gave him a date until he did not publish; when that date came and there was no public arrangement, Moorats published on September 24. At the time of its disclosure there was no assigned CVE or patch available, according to his account. Moorats also reproduced the chain in an OnePlus 12 Pro and estimates that the problem generally affects OxygenOS 16; OnePlus and OPPO share a software base that would explain the coverage between brands.

What is known with certainty and what is not: it is confirmed that Moorats found and combined two failures in OxygenOS services that allow to climb to root when a malicious app is installed. It is also confirmed that OnePlus was informed, recognized the failures in May and warned about the disclosure. It is confirmed that, according to Moorats, there is no public evidence of exploitation in the real world until the date of its publication. As far as the exact scope of affected devices and patch dates is concerned, this remains uncertain: OnePlus has not published a list of models or a public technical notice, nor has it given a verifiable correction schedule at the time of disclosure.

The practical consequences for users and administrators are clear in the threat model of this failure: an attacker only needs to convince or deceive the owner to install an application locally - for example, by sideloading, an attachment package or a link to install outside of official stores - and that app can be quietly raised to root without asking for permission. With root and ability to load kernel code, an attacker can install deep persistence, deactivate security controls, access data encrypted in memory and hide its presence. In corporate environments that is equivalent to losing control of the device and potentially access to the company's systems if the phone is used for authentication or mail.

The real difficulty of exploiting this vector is in the first step: installing the malicious app. Until suppliers publish and deploy patches, the most practical and effective defense for end users is to restrict the installation of applications to sources of trust. Avoid sideloading, do not install APKS from third parties and use official protective stores (such as Google Play with Play Protect) significantly reduces the risk. The chain described by Moorats does not thrive without a local app installed.

Specific and verifiable recommendations for users:

1) Do not install applications outside official stores and, if necessary, verify the origin and signature of the APK. Disable the installation from "unknown origins" in system settings when not necessary. 2) Keep USB debugging disabled unless actively used and monitor connected devices: open debugging facilitates the installation of unwanted software. 3) regularly review installed apps (settings → applications) and remove anything you do not recognize; use reputation tools like Google Play Protect. 4) Backup and maintain a recent picture of important data in case a factory restoration is required. 5) For companies: implement MDM policies that block the installation of unapproved apps and restrict developer modes on corporate devices.

For researchers and security professionals, the case also raises a discussion of responsible disclosure practices. OnePlus stated that the final decision on when to publish vulnerabilities corresponds to it - a position that Moorats replayed in its exchange and that caused the threat of legal actions if it published - and that European standards require the acceptance and correction of reports but would not allow the disclosure by researchers without the consent of the manufacturer. This legal interpretation is controversial among the security community, which often advocates coordinated disclosure with reasonable time limits if the supplier does not apply patches. For guidance on good outreach practices there are public material from agencies such as ENISA: ENISA - Coordinated Vulnerability Disclosure, and for technical aspects of Android and security mitigation, the official documentation is available: Android Security - source.android.com.

Finally, if you think your OnePlus or OPPO device may be compromised or has installed dubious applications, consider reinstalling the system from the official image or restoring to factory values and, if possible, wait for the manufacturer's notice and patch before reinstalling applications outside the official store. It is also advisable to keep an eye on official OnePlus channels for a safety and patch notice: the company has a support website and security policies where updates and mitigation procedures should be published - for example, its security center or technical support - OnePlus Support & Security.

The case highlights a recurring reality on Android devices with manufacturer layers: any additional code running with high privileges multiplies the attack surface. Until suppliers publish corrections and lists of affected models, the best defense is the digital hygiene of the user and, for organizations, technical policies that limit facilities and privileges.