A phone that has never been rooted, never had a custom ROM flashed, and never left the factory settings can still hand over full control to any app a user installs. That’s the finding a security researcher published on September 24, 2026, about the OnePlus 15 running the latest build of OxygenOS. No malware download link, no phishing text, no exotic exploit kit. Just an app the owner installed themselves, asking for nothing, and walking away with root.
The researcher, Rasmus Moorats, chained two separate flaws in OnePlus’s own software layer to reach root, the highest level of control an Android device can grant. According to The Hacker News, which first reported the chain, the malicious app in his proof of concept requested no special permissions and triggered no permission prompt at all. He tested it on a stock, unmodified phone, exactly the condition most owners are in today. Five months after he first reported it, OnePlus has assigned no CVE and shipped no patch.
OnePlus’s Root Access Problem, In Brief
Strip away the technical detail and the story is simple. OnePlus built two background services into its phones that run with root privileges and trust whatever app calls them. One service, meant for gathering debug logs, doesn’t check who is asking. A second service, meant to talk to phone hardware, will run any shell command handed to it. Put an app that calls the first service in front of the second, and the phone hands over the keys.
This isn’t a bug in Android itself, and Google isn’t the vendor at fault here. It’s a bug in the OnePlus-specific software layered on top of Android, the kind of custom code every Android manufacturer adds to differentiate its phones. That distinction matters for anyone trying to figure out whether this OnePlus root vulnerability touches their device: it depends entirely on which manufacturer skin is installed, not on the version of Android underneath.
Who Is Rasmus Moorats
Moorats is the independent security researcher credited with finding and chaining both flaws. His writeup, picked up by The Hacker News on the day of publication, lays out a five-month back-and-forth with OnePlus that started with a private report and ended with a public disclosure the vendor had explicitly asked him not to make yet. That tension between researcher and vendor timelines sits at the center of this story almost as much as the technical bug does.
Nothing in the available reporting attributes a direct, on-record quote to Moorats explaining his motivation for publishing on schedule. What is documented is the timeline itself, and it reads like a fairly standard coordinated-disclosure dispute: a vendor asks for more time, a researcher grants an extension, the vendor goes quiet, and the clock eventually runs out.
Stage One: AtlasService Opens a Root-Adjacent Door
The first flaw lives in a OnePlus component called AtlasService, described in the research as a debugging-data collector that runs as root and accepts calls from any app without verifying who’s on the other end. A crafted call reaches a OnePlus debugging tool that takes text supplied by the calling app and inserts it, unvalidated, into a system command. That’s a classic command-injection pattern, the same family of bug that has powered breaches on servers for two decades, just relocated onto a phone’s debugging pipeline.
The catch, at this stage, is that the root access it grants is boxed inside a restricted zone called dumpstate, an area of the system built for collecting bug reports. Android normally enforces those boundaries through SELinux policy rules baked into the platform, which is why the access is constrained rather than total. It can’t load kernel modules, and it can’t touch everything an unrestricted root shell can. On its own, stage one is a serious bug. It is not yet a full device takeover.
Stage Two: olc2 Turns Partial Root Into Total Control
The second flaw sits in olc2, described as a OnePlus hardware-helper service, the kind of low-level component that talks to sensors, radios, or other physical parts of the phone. Olc2 includes a command that will execute arbitrary shell instructions handed to it. Its only real gate is that the caller has to already be root, which is exactly what stage one supplies.
Once an app clears that gate, the shell command runs in a zone with full low-level Linux privileges, including the ability to load kernel code. That’s the difference between “some root” and “all of it.” Chained together, AtlasService and olc2 turn a permission-less install into complete control of the device, at the same privilege level a factory technician would have.
For readers who track this kind of flaw across platforms, it’s a similar shape to the container-escape bug detailed in our coverage of the GKE Fragnesia root vulnerability: two components that are individually contained become a full privilege breach only when chained.
Why Zero Permissions Made This Worse
Android’s entire permission system exists to give users a checkpoint. An app that wants your contacts, your camera, your location, has to ask, and a prompt has to appear. Users have been trained, however imperfectly, to treat that prompt as a signal of risk. This exploit chain skips the checkpoint entirely. The malicious app in Moorats’s proof of concept requested nothing unusual and displayed no dialog box a user could have declined.
That’s what separates this from garden-variety Android malware. Most malicious apps still have to talk their way past a permission prompt Google documents as a core defense layer, an app store review process, or both. A flaw that reaches root with zero requested permissions removes the single control point most phone owners actually rely on, even if they’ve never opened a security settings menu in their life.
Five Months, Four Contacts: The Disclosure Timeline
The gap between private report and public disclosure ran nearly five months, and the back-and-forth followed a pattern security researchers will recognize from other vendor disputes. Reporting from The Hacker News lays out the sequence in detail.
| Date (2026) | Event |
|---|---|
| April 18 | Moorats privately reports both flaws to OnePlus |
| May 20 | OnePlus confirms the flaws; asserts it holds final say over disclosure timing |
| June 22 | OnePlus asks Moorats to hold disclosure until September 17; he agrees |
| July 20 | Moorats requests a status update; no response recorded |
| September 11 | Moorats requests a second status update; no response recorded |
| September 24 | Moorats publishes the full research, no CVE or patch issued by OnePlus |
Notice the gap between the agreed date, September 17, and the actual publication, September 24. Moorats gave OnePlus a week past its own requested deadline before going public. By any reasonable reading of coordinated-disclosure norms, that’s not an impatient researcher jumping the gun, that’s a vendor that missed a deadline it set for itself.
OnePlus’s Legal Liability Warning
The most striking detail in the disclosure record isn’t technical, it’s the language OnePlus reportedly used with the person who found the bug. Per The Hacker News, OnePlus told Moorats it holds “the exclusive final right of vulnerability disclosure” and warned that publishing without its approval could carry “relevant legal liabilities in accordance with applicable laws.”
That kind of language sits uneasily next to the substance of the finding. A vendor is well within its rights to ask for extra time, and most researchers grant reasonable extensions in good faith, which Moorats did once already. But threatening legal exposure toward a researcher who waited a week past an already-extended deadline, on a bug the vendor itself confirmed in May, is the sort of move that tends to harden industry opinion against a vendor rather than buy it more runway. Coordinated disclosure runs on trust in both directions, and a legal threat spends that trust fast.
Which Devices Carry the Flaw
The confirmed device is the OnePlus 15, tested on the latest build of OxygenOS. But the scope, per OnePlus’s own admission to Moorats, extends well beyond one flagship phone. According to reporting on the disclosure, OnePlus told him the same flaws affect many more of its own devices, and devices built by OPPO as well. OnePlus did not identify which additional models are affected.
That last point deserves emphasis: OnePlus and OPPO both sit under the same parent conglomerate, BBK Electronics, which also owns Vivo and Realme. AtlasService and olc2 sound like OnePlus-branded components, but shared code across sibling brands under one corporate umbrella is common in this segment of the market, and it’s exactly the kind of arrangement that turns a single-model bug into a multi-brand one. Until OnePlus names specific models and OS builds, anyone running OxygenOS, or a OPPO-built skin descended from the same code, has reason to treat this as an open question rather than a closed one.
Inside the Exploit Chain, Step by Step
Laid out stage by stage, the chain looks like this. Each step depends on the one before it, which is exactly why patching either service individually would break the chain, and why a full fix likely requires OnePlus to rework both.
| Stage | Component | Weakness | Privilege Gained |
|---|---|---|---|
| 1 | AtlasService | Accepts calls from any app; no caller verification | Root, restricted to the dumpstate zone |
| 1 (detail) | OnePlus debug tool | Inserts app-supplied text into a system command unvalidated | Command injection |
| 2 | olc2 | Executes arbitrary shell commands from any already-root caller | Full low-level Linux privileges, including kernel code loading |
For a sense of how a researcher would begin probing for this class of bug on a real device, the general reconnaissance looks like standard Android debugging work rather than anything exotic:
# Illustrative reconnaissance only -- not exploit code
adb shell dumpsys activity services | grep -i atlas
adb shell ps -A | grep -i root
adb shell service list | grep -i olcCommands like these simply enumerate which services are running and at what privilege level, the same basic triage any Android security researcher runs before looking for a deeper flaw. The actual exploit logic, the crafted calls that chain AtlasService into olc2, hasn’t been published as ready-to-run code, and no CVE identifier exists yet to track it.
How This Stacks Up Against Past Android Root Bugs
Android has a long history of local privilege-escalation flaws that let an installed app claw its way to root. This one earns a place in that lineage for a specific reason: almost none of the bug’s own logic lives in the Linux kernel or in AOSP code that Google controls. It lives entirely in vendor-added services, which means Google’s monthly security patch cycle can’t fix it. Only OnePlus can.
| Vulnerability | Year Disclosed | Root Cause | Scope | Patch Path |
|---|---|---|---|---|
| TowelRoot (CVE-2014-3153) | 2014 | Linux kernel futex bug | Millions of Android devices across vendors | Kernel patch via Google/AOSP |
| Dirty COW (CVE-2016-5195) | 2016 | Linux kernel race condition | Broad, all Linux-based systems including Android | Kernel patch via Google/AOSP |
| Quadrooter | 2016 | Qualcomm chipset driver flaws | Reported by Check Point to affect roughly 900 million devices | Chipset vendor plus OEM patch |
| AtlasService / olc2 chain | 2026 | OnePlus-specific service design | OnePlus 15 confirmed; more OnePlus and OPPO models acknowledged, unnamed | OnePlus-only fix; no CVE or patch as of Sept. 24 |
The pattern across the older entries is that a kernel-level bug, once found, gets a single upstream fix that flows down to every vendor through Google’s own security update pipeline. A vendor-layer bug like this one doesn’t have that luxury. Each manufacturer has to find and fix its own version of the mistake, which is slower by design and depends entirely on that one company’s priorities. Readers who followed our coverage of the F5 BIG-IP zero-day or the Cisco ISE zero-day will recognize the shape of this problem: vendor-specific code sitting on top of a well-audited base is consistently where the ugliest, longest-lived bugs turn up.
The BBK Ecosystem: Market and Security Impact
OnePlus built its brand on being the enthusiast’s alternative to Samsung and Apple’s flagship phones, and the OnePlus 15 is its current top-tier device. A root-access flaw with no patch and no CVE lands right on that flagship at a moment when the company is trying to hold premium-tier credibility against faster-moving rivals. It’s a bad look regardless of how many devices actually end up affected once OnePlus finishes its internal review.
The bigger exposure sits one level up, at BBK Electronics, the parent group behind OnePlus, OPPO, Vivo, and Realme. Those four brands collectively sell hundreds of millions of phones a year across Asia, Europe, and emerging markets, and shared engineering across sibling brands is standard practice in that conglomerate structure. OnePlus has already told Moorats the flaws reach beyond the 15, and named OPPO devices specifically. If the underlying service code is shared more broadly across the BBK family, as much of that group’s software historically has been, the true device count could run far higher than “OnePlus 15 owners” once OnePlus and OPPO finish auditing their full lineups.
Enterprise IT and BYOD (bring your own device) programs are the segment most exposed in the near term. A phone that any installed app can silently root breaks the security assumptions behind mobile device management software, corporate email sandboxing, and any policy that assumes the OS layer enforces separation between personal and work data. It’s the same category of risk OWASP’s Mobile Top 10 project flags under insecure platform usage. Until a patch exists, the honest answer for an IT security team is that any unmanaged OnePlus or OPPO device on the network should be treated as potentially rooted, not as trusted hardware.
Coordinated Disclosure Under Strain
Vendor disclosure disputes are common; researchers and companies negotiate deadlines all the time, and most of those negotiations never become public news. What pushes this one into a bigger story is the combination of three things happening at once: a legal liability warning aimed at the researcher, a missed self-imposed deadline, and a flaw serious enough to hand over root with zero permissions.
Security researchers watching this case are likely to read it the same way the industry read past standoffs over responsible disclosure: as evidence that a vendor tried to slow-walk a fix past its own agreed date, then reached for legal language instead of a patch. Whether or not OnePlus intended it that way, the optics point in one direction. For a company whose flagship phone runs the same OxygenOS platform this bug was found on, that’s a rough tradeoff for however many extra weeks the delay might have bought internally.
What Happens Next: Predictions
A few things are reasonably likely to follow from here, based on how similar vendor-specific Android flaws have played out in the past.
- OnePlus will assign an internal tracking identifier and likely request a CVE within weeks now that the flaw is public, since silence becomes far costlier once a named outlet has covered it.
- An OxygenOS patch targeting AtlasService’s authentication gap is the more urgent of the two fixes; expect it before a fix for olc2’s command-execution path, since restricting the entry point kills the chain fastest.
- OPPO will face pressure to confirm or deny exposure on its own lineup rather than let OnePlus’s vague acknowledgment stand as the only public statement.
- Third-party mobile threat-defense vendors will likely publish detection signatures for the exploit chain before OnePlus ships a fix, since defensive tooling tends to move faster than OEM patch cycles.
- Expect renewed scrutiny of vendor debug services across other Android OEMs, since AtlasService-style “accepts any caller” debug tools are not unique to OnePlus, and this disclosure gives other researchers a template to go looking for the same pattern elsewhere.
What Device Owners Can Do Right Now
The practical mitigation options are limited, because this isn’t a flaw an owner can configure their way around. The attack requires the malicious app to already be installed and running locally; it cannot be triggered remotely over the internet, which is the one piece of good news in this story. That means the strongest defense available today is simply being careful about what gets installed.
- Install apps only from the Google Play Store or OnePlus’s own app store, and avoid sideloading APKs from unfamiliar sources until a patch ships.
- Review already-installed apps and remove anything unrecognized or rarely used, since the exploit works through an app already sitting on the device.
- Watch for a OxygenOS security update referencing AtlasService, olc2, or a newly assigned CVE, and apply it as soon as it’s available.
- Enterprise device managers should flag OnePlus 15 and other suspected BBK-family devices for closer monitoring until OnePlus clarifies the full affected list.
None of these steps close the underlying hole. Only a code fix from OnePlus does that. For readers weighing how urgently to act, it’s worth comparing this to a recent case where an OS vendor moved fast once a fix existed: our coverage of the Nintendo Switch CVE-2026-82079 firmware update showed a company shipping a fix and pushing users toward it within a single update cycle. OnePlus hasn’t reached that point yet.
The broader lesson for anyone tracking Android security extends past OnePlus. Vendor-added debug and hardware-helper services are exactly the kind of code that rarely gets the same scrutiny as the Android base itself, and this is far from the first time that gap has produced a serious bug, as our recent look at the record-setting Microsoft Patch Tuesday and the ransomware-linked VMware vCenter RCE both illustrate on the enterprise side. Vendor-specific code, not the shared platform underneath it, keeps turning out to be where the highest-severity bugs live.
Frequently Asked Questions
What exactly is the OnePlus root vulnerability?
It’s a two-stage exploit chain in OnePlus’s own software, not in Android itself, that lets an already-installed app reach root access, the highest privilege level on the device, without requesting any permissions or showing a prompt. Researcher Rasmus Moorats demonstrated it on a OnePlus 15 running the latest OxygenOS.
Does OnePlus have a patch available?
No. As of the September 24, 2026 disclosure, OnePlus had assigned no CVE identifier and released no fix, according to reporting from The Hacker News.
Can this be exploited remotely, over the internet?
No. The malicious app has to already be installed and running locally on the phone. There is no remote trigger, which limits the immediate risk to devices that install an app carrying the exploit.
Which devices are affected besides the OnePlus 15?
OnePlus told Moorats that the same flaws affect additional OnePlus devices and OPPO devices, without naming specific models. Until OnePlus publishes a full list, owners of other OnePlus and OPPO phones should assume they may be exposed.
What are AtlasService and olc2?
AtlasService is a OnePlus debugging component that runs as root and accepts calls from any app without verifying the caller. Olc2 is a OnePlus hardware-helper service that will execute shell commands from any caller that is already root. Chained together, they escalate a permission-less app to full device control.
Did OnePlus threaten the researcher?
According to the disclosure reported by The Hacker News, OnePlus told Moorats it held final say over disclosure timing and warned that publishing without its permission could carry legal liability. Moorats published on September 24 after OnePlus missed its own requested September 17 deadline.
How is this different from a normal Android security bug?
Most Android security patches come from Google through the monthly security bulletin and cover the shared AOSP codebase and Linux kernel. This flaw lives entirely in OnePlus’s own added software layer, so Google’s patch cycle can’t fix it. Only OnePlus can, which is part of why the timeline has stretched to five months with no resolution.
Should I stop using my OnePlus 15 until this is fixed?
There’s no need to stop using the phone, since the attack requires installing a malicious app locally first. Stick to trusted app sources, review what’s already installed, and apply a security update from OnePlus as soon as one referencing this flaw becomes available.
