The OnePlus root vulnerability involves two OEM software flaws that let an installed Android app gain elevated privileges without requesting special permissions. Researcher Rasmus Moorats demonstrated the chain on a OnePlus 15 and published his findings on September 24, 2026. The flaws involve AtlasService and the olc2 service, with potentially broader exposure across OnePlus and OPPO devices. At disclosure, no fix or CVE identifiers were publicly available. No real-world exploitation was known. For enterprises, the concern is whether devices handling business data remain trustworthy. Teams should review potentially affected phones, limit unapproved app installation, and investigate root indicators. Hexnode UEM can support inventory, app restrictions, and compliance review, but it cannot repair vulnerable OEM services.
Employees often use the same phone for everyday apps and access to company data. On September 24, 2026, a researcher disclosed the OnePlus root vulnerability, showing how an installed app could chain two OxygenOS flaws without special permissions.
The finding gives IT teams a reason to review mobile device trust. An app’s lack of permission requests does not establish that it is safe.
Who is affected by these OnePlus flaws?
OnePlus device owners are the directly demonstrated affected group, including anyone using vulnerable phones for work. Testing included a stock OnePlus 15 running OxygenOS 16.0.3.503. Broader OnePlus and OPPO exposure was acknowledged during the disclosure process, but a complete model and software-version list was unavailable.
This is a vulnerability disclosure, rather than an identified criminal campaign. Rasmus Moorats is the security researcher who demonstrated the issue, not a threat actor. Enterprises should therefore assess exposure through their device inventories instead of assuming a particular industry was targeted. Corporate phones and personally owned devices both deserve review when they access business applications, although their management options differ.
What happened?
A local app crosses two privilege boundaries
The chain requires an app to be installed and running on the device. “Android no-permission root” describes the escalation: the app does not need special Android permissions to exploit these services. It does not mean the phone can be compromised remotely without that initial foothold.
Stage
What the flaw enables
AtlasService accepts the call
A root-running OEM service accepts requests without verifying the caller’s authorization.
An audio debugging tool processes the input
Attacker-controlled text reaches a shell command, enabling root execution in the restricted dumpstate context.
olc2 accepts the root caller
A second OEM service executes shell commands after checking that the caller already has root privileges.
Execution moves to a more privileged context
The resulting process has broad Linux capabilities, including the capability associated with loading kernel modules.
Root privileges do not automatically remove every Android safeguard. SELinux, which restricts what processes can access, still constrains the final execution context. The demonstrated result should not be described as a proven defeat of every hardware or operating-system protection.
Disclosure and remaining uncertainties
Moorats reported the flaws on April 18, 2026. OnePlus confirmed them on May 20, and public disclosure followed on September 24.
At disclosure, there was no publicly available fix, assigned CVE identifier, or vendor advisory naming the flaws. The affected-device list also remained incomplete. Organizations tracking OPPO security should check model-specific guidance rather than treating every OPPO phone as confirmed vulnerable.
No known malicious campaign, credential theft, MFA bypass, or ransomware deployment accompanied the disclosure. The research demonstrated privilege escalation; persistent access across reboots and theft from enterprise applications were not established outcomes.
Why Do Security Teams Need Contextualized Threat Alerts?
Contextualized threat alerts help SOC teams reduce alert fatigue and prioritize threats faster.
Why this matters
Mobile endpoint security depends on the operating system enforcing boundaries between apps, users, and sensitive resources. Privileged OEM services become part of that trust boundary. If an ordinary app can abuse them, reviewing its requested permissions alone will miss the underlying risk.
Android BYOD risk also extends beyond the work profile. Work profiles separate business apps and data, but they still depend on the underlying platform’s security. A serious operating-system compromise warrants reassessing that separation; it does not prove that every work profile has been breached.
For IT teams, the practical implication is to combine app controls, device monitoring, and access decisions. MFA remains valuable, but successful authentication does not establish that the device handling an authorized session is trustworthy.
How Hexnode can help
Hexnode UEM: Reduce app exposure and review device trust
Hexnode UEM provides mobile device management controls that can support a measured response while organizations await vendor remediation.
Identify devices that need review. Device details and reports expose information such as manufacturer, model, OS version, ownership, and reported root status. Administrators can use that inventory to locate OnePlus and OPPO devices and prioritize users with sensitive access. Reported root status reflects the device’s root state at the time of check-in and is not a detection mechanism for this exploit, a device can be compromised via AtlasService/olc2 without ever showing as rooted, so this field should not be relied on to identify affected devices.
Restrict unapproved installation paths. On supported Android Enterprise deployments, Hexnode can block app installation from unknown sources. This reduces one route for introducing a malicious app. However, it does not establish that every app from an approved store is safe.
Review application compliance. Hexnode displays compliance information for missing required apps and detected blocklisted apps. Beyond reporting, Hexnode can also take automated enforcement actions when a device is found non-compliant, for example, removing corporate Wi-Fi/VPN profiles, wiping the Work Container, or restricting enterprise access.
Respect enrollment boundaries. Available restrictions depend on Android version, device support, and enrollment mode. On BYOD (Work Profile) enrollments, restricting “Unknown Sources” in Hexnode only locks down the corporate work container, personal-side sideloading on the device remains allowed. This restriction only extends to the full device on corporate-owned enrollments (COPE or Fully Managed). For personally owned phones, administrators should confirm each control’s scope rather than assume that a work-profile restriction governs personal apps.
These measures improve oversight and reduce exposure. They do not patch AtlasService or olc2, and reported root status is not proof that this specific exploit will always be detected. Access restrictions also require an appropriately configured enforcement mechanism; a compliance report alone does not revoke application sessions.
Featured resource
Android Platform Capability Statement
Download the infographic to explore how Hexnode simplifies Android device management across every stage of the endpoint lifecycle.
The OnePlus root vulnerability highlights a gap that permission reviews cannot address: an installed app may exploit privileged software already present on the phone. Organizations should act on that exposure without treating every potentially affected device as compromised.
Start by identifying OnePlus and OPPO phones used for business access. Record their software versions, ownership, and business roles, then request model-specific remediation guidance. Review app installation policies and provide employees with a clear route for obtaining approved software.
Where compromise is suspected, follow incident-response procedures and restrict sensitive access while investigating. Review associated sessions and credentials when evidence warrants it. Keep a vendor-confirmed fix as the remediation target, rather than assuming that enrollment or a clean status report resolves the flaws.
Hexnode UEM can help maintain visibility and apply supported restrictions throughout this process. Assign an owner to track vendor updates, validate fixes, and confirm deployment across the relevant fleet.
Try Hexnode Free for 14 Days
Sign up for Hexnode to manage Android devices, restrict app installations, and monitor compliance.
I’m a technical content writer at Hexnode who loves simplifying tech. I break down complex ideas, remove the fluff, and help readers clearly understand our product for what it actually is: simple, reliable, and built to solve real problems.
