OnePlus 15 Root Exploit: Zero-Permission Apps Can Take Full Control

OnePlus 15 Root Access Exploit: How Zero-Permission Apps Are Bypassing Android Security Entirely

Quick Answer: Two chained OxygenOS flaws let an app requesting zero permissions gain full root access on the OnePlus 15. OnePlus has patched it in OxygenOS 16.0.10.500(EX01) — update immediately and avoid sideloaded apps until then.

Last verified: September 27, 2026

Picture this: a user downloads a flashlight app. No camera access requested. No storage access requested. No contacts, no location, nothing. The permission screen never even pops up — because the app never asked for a single one. Three taps later, that "harmless" app is running shell commands as root on a brand-new OnePlus 15.

That's not a hypothetical. It's exactly what independent security researcher Rasmus Moorats demonstrated against OxygenOS this month, and it's a scenario every SOC analyst and mobile threat defense (MTD) team should be paying close attention to — because it breaks an assumption most of us have built our entire mental model of Android security around: no permissions requested means limited capability. On OnePlus and, reportedly, across the broader OPPO device ecosystem, that assumption just failed.

Table of Contents

• What Actually Happened
• Inside the Exploit Chain: AtlasService and olc2
• The Disclosure Timeline (and Why OnePlus Pushed Back)
• Why a Zero-Permission Android Exploit Is Different
• Detection: What Defenders Can Actually Do
• Useful Commands for Investigation
• Prevention Strategies for Users and Enterprises
• Expert Tips
• FAQ
• Conclusion

What Actually Happened

According to Cyber Security News and corroborating reports from The Hacker News and Cybernews, two vulnerabilities in the latest OxygenOS build allowed a malicious Android app — one holding zero permissions — to execute arbitrary code with root privileges on the OnePlus 15. The attack doesn't rely on a remote trigger, phishing link, or social engineering beyond getting the victim to install and open the app once.

Researcher Rasmus Moorats first validated the chain on an already-rooted OnePlus 12 Pro, then successfully reproduced it on a fully stock, unmodified OnePlus 15 running OxygenOS 16.0.3.503 — on the first attempt. That reproducibility is what makes this more than a lab curiosity.

Inside the Exploit Chain: AtlasService and olc2

Per Moorats's published research (as reported by The Hacker News), the chain runs through two OnePlus-proprietary components — not stock Android code:

• AtlasService — a debugging-data collector that runs as root but does not verify the identity of the calling application. Any app, permissionless or not, can talk to it.
• olc2 / doShell — a vendor hardware interface function. Its only real safeguard is that the caller must already have root — which the AtlasService step conveniently hands over.

In short: stage one abuses a root-level debugging tool with no caller verification to obtain a restricted root shell inside Android's dumpstate sandbox. Stage two pivots that restricted root into a full, unrestricted root shell via the olc2 hardware interface. Two flaws that individually look like debugging oversights become, chained together, a complete sandbox escape.

The Disclosure Timeline (and Why OnePlus Pushed Back)

This case is as much a coordinated-disclosure story as it is a technical one:

April 18, 2026	Moorats reports both flaws to OnePlus
May 20, 2026	OnePlus Security Response Center confirms the issues affect "all series of OPPO terminal products with universal security risks"
June 22, 2026	OnePlus requests more time; Moorats agrees to hold disclosure until September 17
July 20 & Sept 11, 2026	Moorats requests status updates; receives no reply
Sept 24, 2026	Moorats publishes, with no patch confirmed and no CVE assigned

Notably, OnePlus reportedly told Moorats it retains sole authority to decide when — or whether — technical details become public, even after a fix ships, and cited legal risk around independent publication. That stance drew criticism from parts of the security research community, since it conflicts with typical 90-day coordinated disclosure norms. As of this writing, OnePlus has confirmed a fix for the OnePlus 15 (OxygenOS 16.0.10.500(EX01)) but has not published a CVE identifier, an affected build list, or a full device inventory across the OPPO lineup.

Why a Zero-Permission Android Exploit Is Different

Android's permission model is the backbone of most mobile threat defense and enterprise mobile device management (MDM) policy. Security teams routinely flag apps requesting camera, microphone, SMS, or storage access as higher risk. A permission-bypass vulnerability like this one quietly defeats that entire detection heuristic — a policy engine scanning for suspicious permission requests would never flag the proof-of-concept app used here, because it doesn't request anything.

For enterprises running BYOD or corporate-owned OnePlus/OPPO fleets, this is a real gap in existing mobile threat defense coverage, and it's worth treating as seriously as any endpoint detection and response (EDR) gap on the desktop side.

Detection: What Defenders Can Actually Do

There's no public proof-of-concept exploit code available, and none should be reproduced or distributed — this is a defensive breakdown only. For SOC teams and mobile security admins, focus on behavioral indicators rather than static permission checks:

• Monitor for unexpected privileged process spawning tied to AtlasService or olc2-related system calls in MDM/EMM telemetry, where supported.
• Flag devices exhibiting root-level behavior (unexpected SELinux context changes, unauthorized system settings modification) despite no rooting tool ever being installed by IT.
• Audit installed applications on managed OnePlus/OPPO devices for anything sideloaded outside the Google Play Store or official OnePlus channels.
• Cross-reference device OxygenOS build numbers against the patched version to identify vulnerable endpoints still awaiting update.

Useful Commands for Investigation

To check the current OxygenOS build number on a managed Android device via ADB (useful for fleet-wide patch verification):

adb shell getprop ro.build.display.id

This returns the exact build string so you can confirm whether a device is running OxygenOS 16.0.10.500(EX01) or a later, patched build. No special permissions or root are required to run this — it's a safe, read-only diagnostic command suitable for fleet audits.

To list currently installed packages for a manual sideload audit:

adb shell pm list packages -3

Note: -3 filters to third-party (non-system) apps only. This is a read-only inventory command — do not run any command that modifies system partitions or attempts to interact with AtlasService directly, as no safe testing method for this vulnerability has been publicly released.

Prevention Strategies for Users and Enterprises

• Update immediately. Install OxygenOS 16.0.10.500(EX01) or later the moment it's available for your model.
• Stop sideloading. Only install apps from the Google Play Store or OnePlus's official channels until OnePlus confirms the full list of affected devices.
• Audit installed apps. Remove anything from unknown developers, especially utility apps (flashlight, QR scanner, battery saver) that request no permissions but also have no clear reason to exist beyond ads.
• Enterprise fleets: Flag all OnePlus and OPPO devices in your MDM console for mandatory OTA update enforcement; treat unpatched devices as high-risk until confirmed updated.
• Security teams: Since OnePlus hasn't published a device list, assume any device sharing OxygenOS/ColorOS core components with the OnePlus 15 could be affected until told otherwise.

Expert Tips

• Don't wait for a CVE number to act — vendor confirmation of the flaw (which OnePlus has given) is a stronger signal than CVE assignment timing, which is often delayed for political or PR reasons.
• Treat "zero permissions requested" as a neutral signal, not a safe one, when triaging mobile app risk going forward — this incident is a good internal case study for updating mobile risk-scoring models.
• If you manage a mixed OnePlus/OPPO/Realme fleet (shared BBK Electronics lineage), request written confirmation from your device vendor about patch status — don't assume "OnePlus 15 only" is accurate, since OnePlus itself flagged broader OPPO ecosystem risk.

Related Cybersecurity Topics You Should Explore

• One Misconfigured chmod Command Gave Attackers Root Access
  
• How SOC Analysts Use sed to Catch Attacks Before the SIEM Does
  
• Linux tr Command Tutorial: Fix Messy SOC Logs in Seconds
  
• Linux tee Command: The SOC Trick That Saves Evidence Before It's Gone
  
• Linux wc Command Tutorial: Count Log Lines Like a SOC Pro
  
• Linux cmp Command Explained: Every Flag SOC Teams Actually Use
  
• Linux diff Command Tutorial: Detect Config Drift Like a SOC Analyst
  
• Linux uniq Command: 6 Log Analysis Tricks SOC Analysts Use

FAQ

Is this vulnerability actively exploited in the wild?

No confirmed in-the-wild exploitation has been reported as of this writing. This was disclosed through a research proof-of-concept, not an observed attack campaign.

Does this affect devices other than the OnePlus 15?

OnePlus told the researcher the issue affects "all series of OPPO terminal products with universal security risks," but has not published a specific model or build list. Treat other OnePlus/OPPO devices as potentially at risk until confirmed patched.

Has a CVE been assigned?

As of this writing, no CVE identifier has been publicly assigned to this vulnerability.

What OxygenOS version fixes this on the OnePlus 15?

OxygenOS 16.0.10.500(EX01) has been verified by the researcher to fix both flaws on the OnePlus 15.

Can antivirus apps detect this exploit?

Since the malicious app requests no permissions and the exploit abuses legitimate OEM system components, traditional permission-based mobile antivirus heuristics are unlikely to flag it reliably. Behavioral detection and MDM-level build auditing are more effective.

Why did OnePlus restrict the researcher from publishing details?

OnePlus reportedly stated it retains sole authority over public disclosure of vulnerabilities submitted through its security program, even after remediation. This is a stricter stance than typical 90-day coordinated disclosure norms and drew criticism from parts of the security community.

Conclusion

The OnePlus 15 root access case is a reminder that permission prompts are a UI convention, not a security guarantee — the real boundary lives in how privileged system services validate who's calling them. A single unchecked debugging service was enough to erase Android's entire sandboxing model on a flagship device. Patch your OnePlus and OPPO devices now, tighten your sideloading policy, and don't let "requests no permissions" become your team's blind spot when triaging mobile risk going forward.

Found this breakdown useful? Share it with your SOC team or subscribe for the next deep dive as more details on affected OPPO models emerge.

Analysis based on SOC monitoring and public threat intelligence review.