A malicious app that asks for zero special permissions can still take full root control of a stock OnePlus 15 running the latest OxygenOS build. That is the finding published by The Hacker News on September 24, 2026, and it lands as one of the more alarming Android OEM disclosures of the year because there is, as of this writing, no CVE identifier, no CVSS score, and no patch.
Independent security researcher Rasmus Moorats chained two flaws baked into OnePlus’s own software layer, not the core Android operating system, to escalate from a freshly installed app with no permissions to full root and, ultimately, the ability to load kernel code. OnePlus has told Moorats the underlying issues reach beyond the OnePlus 15 into “many additional OnePlus devices and OPPO devices,” according to the report, but the company has not published a model list, a build number range, or a fix timeline.
What The Hacker News actually reported
The disclosure, published at 17:54 UTC on September 24, 2026, describes a proof-of-concept that required nothing more exotic than installing an app on a retail OnePlus 15 running the newest OxygenOS build available at the time. The app requested no Android permissions, triggered no user consent prompt, and still ended up with root-level control of the device. That is a meaningfully different threat model than most Android privilege-escalation stories, which typically require either a chain that starts with an already-suspicious permission grant or a kernel-level flaw in silicon vendor code (Qualcomm, MediaTek, or Unisoc firmware, for instance).
Instead, this bug lives entirely in code OnePlus wrote and shipped itself: two privileged system services called AtlasService and olc2. Neither one is part of stock Android as published by Google. Both run with elevated privileges by design, because OEMs routinely bolt debugging tools and hardware-helper daemons onto their Android builds to support diagnostics, camera tuning, and carrier features. The problem, according to the report, is that neither service adequately verifies who is allowed to call it.
How the AtlasService and olc2 exploit chain works
AtlasService is described in the disclosure as a debugging-data collector that runs with root privileges but accepts calls from apps without properly checking the caller’s identity or authorization. A malicious app can send it a crafted request, and the service inserts attacker-controlled text straight into a system command without adequately sanitizing it. That yields command execution as root, but inside a restricted SELinux domain called dumpstate, which limits what an attacker can immediately do with it.
The second half of the chain is where the real damage happens. olc2, described as a hardware-helper service, exposes a command capable of running arbitrary shell instructions, but its security check simply assumes that anything calling it is already root. Since the first flaw hands the attacker root-level execution (even in a boxed-in domain), that’s enough to satisfy olc2’s weak check. From there, the attacker can execute commands in a much less restricted context, one with broad Linux privileges, including the ability to load kernel code. At that point, the attacker effectively owns the device: full filesystem access, the ability to disable security controls, persistence across reboots, and the capacity to hide the compromise from the user entirely.
Two flaws, individually limited, combine into something close to worst-case: local privilege escalation from zero permissions to kernel-level control, no user interaction beyond installing an app in the first place. Security engineers sometimes call this pattern “confused deputy” abuse, where a privileged service trusts a caller’s claimed authority instead of verifying it cryptographically, and it has been a recurring theme across Android OEM security research for close to a decade.
Scope: one confirmed device, an unknown number of affected models
The confirmed, demonstrated scope is narrow: a OnePlus 15 running the latest OxygenOS available at time of testing, unmodified, not previously rooted. But the reported scope is much wider. According to the disclosure, OnePlus told Moorats the same underlying flaws affect “many additional OnePlus devices and OPPO devices.” OnePlus and OPPO share a parent company (BBK Electronics) and substantial amounts of firmware, which is why a bug born in one OxygenOS build frequently reappears across ColorOS, the OPPO-branded counterpart, and other BBK sub-brands.
What is not yet public: a specific list of vulnerable models, a minimum or maximum affected OxygenOS/ColorOS build number, or an estimate of the installed base at risk. That absence of detail is itself notable. OnePlus shipped an estimated tens of millions of devices globally in 2025 across its numbered flagship line, the Nord midrange series, and tablets, and OPPO’s volumes run several times larger still, but neither company has published a number tied to this specific issue, so any total-device estimate at this stage is guesswork rather than fact.
| Detail | Status as of September 24, 2026 |
|---|---|
| Demonstrated device | OnePlus 15, latest OxygenOS build |
| Vulnerable components | AtlasService (root debugging service), olc2 (hardware-helper service) |
| Permissions required by malicious app | None |
| User interaction required | None beyond installing the app |
| Broader scope acknowledged by OnePlus | “Many additional” OnePlus and OPPO devices, models not disclosed |
| CVE assigned | None as of publication |
| CVSS score | Not available |
| Public patch or OTA | Not available |
| Known in-the-wild exploitation | None reported |
| Discoverer | Rasmus Moorats, independent security researcher |
Why there’s still no CVE or patch
Responsible disclosure norms generally give a vendor 90 days, sometimes longer for complex embedded-systems bugs, to ship a fix before a researcher goes public, and a formal CVE record through CVE.org is typically how that fix gets tracked once it exists. What’s unusual here is that OnePlus, by the report’s account, acknowledged the flaws and their broader reach across its lineup, yet reached the publication date with no CVE reservation, no CVSS scoring, and no shipped fix. That combination, a vendor-acknowledged bug with no tracking number and no patch, tends to happen for one of a few reasons: the fix touches low-level firmware shared across many SKUs and can’t be tested quickly without risking bricked devices, the vendor is still scoping which models are affected, or coordination between OnePlus and OPPO’s overlapping engineering teams is adding delay.
None of that is confirmed by OnePlus directly; it’s inference based on the pattern the disclosure describes. What is confirmed is the practical guidance in the report itself: because the attack requires a malicious app to already be installed and running, the immediate mitigation is to avoid sideloading APKs from untrusted sources and to stick to the Play Store or OnePlus’s own app channels until a fix ships.
This is not OnePlus’s first brush with an OEM-service flaw
OnePlus has a documented history with vendor-service security issues distinct from stock Android. In March 2024, The Register reported on a Rapid7-flagged bug that let apps peek at SMS content through a OnePlus-specific service, and, per that coverage, OnePlus was slow to engage with the researchers. The AtlasService/olc2 chain is a different bug in different code, but the shape of the problem, a privileged OEM add-on service with weak caller verification, is a repeat pattern rather than a one-off.
That pattern isn’t unique to OnePlus. Nearly every major Android OEM ships proprietary services layered on top of AOSP to handle things Google’s base platform doesn’t: camera tuning daemons, carrier-specific diagnostics, fast-charging controllers, always-on-display helpers. Each one is a potential privileged attack surface that didn’t go through Google’s own Android security review process, because it was never part of stock Android to begin with. Samsung, Xiaomi, and other OEMs have all shipped comparable classes of bugs in their own proprietary components over the years, where a vendor add-on service, not the Android framework itself, turned out to be the weak link.
How this compares with recent Android security incidents
September 2026 has been a dense month for Android and Android-adjacent vulnerability disclosures. Earlier reporting flagged a separate chipset-level issue: SSD Secure Disclosure researchers published a two-stage exploit chain in August 2026 achieving full Android kernel access on devices running Unisoc modem firmware, triggered through a VoLTE video call, with no fix available from the chipset maker at time of publication. That bug required no app installation at all, just a phone call, making it arguably more dangerous in isolation, but it was scoped to Unisoc silicon rather than a specific OEM’s software layer.
The AtlasService/olc2 chain sits in a different category: it needs a malicious app on the device first, which raises the bar for real-world exploitation somewhat (an attacker needs a delivery vector, such as a sideloaded app, a compromised third-party store, or social engineering), but it grants a more complete and durable form of control once triggered, including kernel code loading. Compared with the ZcopyReaper Linux kernel bug that this site covered earlier in September, which carried a CVSS 7.8 score and had reportedly sat unpatched since 2018 before disclosure, the OnePlus case is notable for how fast it went from “no fix yet” to public disclosure, and for having no CVSS score assigned at all rather than a merely high one.
It also echoes a broader theme this outlet has tracked all year: vendors shipping past disclosure deadlines with zero CVE. The Steam BrokenPipe flaw granted SYSTEM-level access on Windows with no CVE assigned six months after discovery, and the BigDiskBuster Defender zero-day shipped with zero CVE and zero patch as of its disclosure. A similar pattern played out with Meta’s Muse zero-day, where a single exposed setting left more than 50 commands reachable and sat unpatched for over a day after disclosure. The OnePlus case fits the same pattern: a real, demonstrated, vendor-acknowledged security hole that exists in a kind of tracking limbo, acknowledged privately, but without the formal infrastructure (CVE, CVSS, public advisory) that lets enterprise patch-management teams and consumers alike measure and prioritize the risk.
Why “no permissions required” matters more than it sounds
Android’s permission model is the primary defense most users, and most security software, rely on to judge whether an app is trustworthy. A flashlight app that requests contacts access raises flags; a flashlight app that requests nothing at all typically sails through both manual review and automated scanning, including Google Play Protect’s on-device and server-side checks. That is precisely what makes a zero-permission root exploit dangerous: it defeats the heuristic that most users, and a fair number of security tools, use to triage risk.
It also complicates mobile device management (MDM) and enterprise bring-your-own-device (BYOD) policies that gate app installation based on permission requests. A policy engine looking for apps that ask for camera, microphone, or storage access would not flag the app used in Moorats’s proof of concept, because by design it does not ask for any of that. Enterprise security teams evaluating OnePlus and OPPO devices in their fleets should treat “the app requested nothing” as no longer a reliable signal of safety until OnePlus confirms which models and builds are fixed. The same logic applies to passkey and password-manager migrations on Android, which rely on the platform’s underlying trust model staying intact.
What device owners can actually do right now
Given the absence of a patch, the practical options are limited but not zero:
- Install apps only from the Google Play Store or OnePlus’s own verified channels; avoid sideloading APKs from third-party sites, forums, or unofficial app stores.
- Watch for an OxygenOS security update in the coming weeks; OnePlus has not given a public timeline, so check the device’s built-in software update section periodically rather than waiting for a specific announced date.
- Enterprise IT teams managing OnePlus or OPPO fleets should treat permission-based app vetting as insufficient for these devices until OnePlus publishes an affected-model list and confirms a fix.
- Consider Google Play Protect as a partial backstop, since it can flag known-malicious app signatures independent of the permissions those apps request, though it would not catch a novel app built specifically to exploit this chain.
The disclosure timeline, as reported
| Date / Period | Event |
|---|---|
| Prior to September 2026 | Rasmus Moorats discovers and chains the AtlasService and olc2 flaws, reports to OnePlus |
| During disclosure process | OnePlus acknowledges the issues and indicates broader OnePlus/OPPO impact beyond the OnePlus 15 |
| September 24, 2026, 17:54 UTC | The Hacker News publishes full technical details of the exploit chain |
| As of publication | No CVE assigned, no CVSS score, no public OnePlus advisory, no patch available |
Market and industry impact
OnePlus and OPPO, both under the BBK Electronics umbrella alongside Vivo and realme, together account for a significant share of global Android shipments, particularly across Asia, Europe, and increasingly North America following OnePlus’s push into the US carrier market. A vulnerability that potentially spans multiple brands under one parent company, without a public model list, creates exactly the kind of ambiguity that erodes trust fastest: consumers and IT buyers cannot check “am I affected” against a concrete list, so the sensible default becomes treating the entire product family as at-risk until told otherwise.
For OnePlus specifically, the timing is awkward. The OnePlus 15 is the company’s current flagship, listed on OnePlus’s own global site as the device it wants reviewers and buyers focused on for benchmark comparisons and camera quality, not a root-exploit disclosure. A vendor-acknowledged, unpatched local privilege escalation on the flagship model, with expanded but undefined impact across the broader lineup, is the kind of story that security-conscious enterprise buyers and public-sector procurement teams tend to remember well past the news cycle, particularly if a fix takes weeks rather than days.
What happens next: five predictions
- A CVE gets assigned within days, not weeks. Public disclosure by a named researcher through a widely read outlet like The Hacker News typically accelerates CVE assignment; MITRE or a CVE Numbering Authority affiliated with OnePlus, Google, or a mobile-security-focused CNA is likely to log this within the next one to two weeks.
- OnePlus publishes a partial model list before a full fix ships. Given the acknowledged scope creep beyond the OnePlus 15, expect OnePlus and/or OPPO to narrow the affected range publicly to manage user anxiety, even before the actual OTA patch is ready.
- The fix arrives as a security-only OTA, not a full OxygenOS version bump. Given the severity and the local-only attack vector, OnePlus has incentive to ship a targeted patch to AtlasService and olc2 rather than waiting for a broader scheduled OxygenOS release.
- Expect copycat research on other BBK-family devices. Once one researcher demonstrates that OnePlus/OPPO’s shared debugging and hardware-helper services carry weak caller verification, others will likely probe realme and Vivo firmware, which frequently shares codebases with OPPO, for the same class of bug.
- Enterprise mobile security vendors will update detection signatures. Mobile threat defense (MTD) products are likely to add behavioral detection for apps attempting to call AtlasService or olc2 directly, independent of whether a formal CVE or patch exists yet.
The bigger pattern: OEM services as the new attack surface
Stock Android, the version of the operating system Google ships and reviews through its own security process, has gotten measurably harder to exploit over the past several Android release cycles thanks to sandboxing improvements, tightened SELinux policies, and Google’s own bug bounty and Project Zero scrutiny, as outlined in Android’s public security update resources. What has not kept pace, repeatedly, is the layer OEMs bolt on top: camera services, thermal management daemons, fast-charging controllers, and diagnostic tools like AtlasService that never went through Google’s own hardening process because they are not part of AOSP.
That gap is exactly where this month’s disclosures have clustered, from the Unisoc modem VoLTE chain to the OnePlus AtlasService/olc2 pairing. It suggests that Android’s security story in 2026 has largely shifted from “is the kernel and framework secure” to “can you trust every OEM’s proprietary add-on service,” a much harder question for any single vendor, including Google, to fully answer on a user’s behalf.
For readers managing device fleets or simply choosing a next phone, the practical takeaway is that a manufacturer’s security update cadence and its history of acknowledging and fixing OEM-layer bugs, not just how quickly it patches Google’s own monthly Android Security Bulletin items via the official Android security bulletin program, matters just as much for real-world safety.
Frequently asked questions
Is my OnePlus phone affected right now?
The confirmed, demonstrated device is the OnePlus 15 running the latest OxygenOS build. OnePlus has told the researcher that the underlying flaws extend to other OnePlus and OPPO devices, but has not published which specific models or software builds are affected, so a full list isn’t available yet.
Has a CVE number been assigned to this vulnerability?
No. As of the September 24, 2026 disclosure, no CVE identifier, no CVSS severity score, and no public OnePlus security advisory had been issued for the AtlasService/olc2 chain.
Do I need to grant an app permissions for this attack to work?
No. The proof of concept used an app that requested no special Android permissions and required no user consent prompt beyond the initial app installation.
Can this be exploited remotely, over the internet?
No. The attack is local: a malicious application must first be installed and running on the device. It is not a network-based or remote exploit in the form disclosed.
What should I do until OnePlus releases a patch?
Only install apps from the Google Play Store or OnePlus’s own official channels, avoid sideloading APKs from unverified sources, and check for OxygenOS software updates regularly since OnePlus has not given a specific date for a fix.
Are OPPO devices also affected?
According to the disclosure, OnePlus indicated the flaws affect OPPO devices as well, since OnePlus and OPPO share significant amounts of firmware under their common parent company. No specific OPPO model list has been published.
Is there evidence this has already been exploited by attackers?
No. The report states there is no known evidence of the flaws being exploited in real-world attacks as of the September 24, 2026 publication date.
Who found the vulnerability?
Independent security researcher Rasmus Moorats discovered and chained the two flaws, reported them to OnePlus, and published the technical details after the disclosure process did not produce a public fix.
Related
- ZcopyReaper Linux Bug Hits CVSS 7.8, Root Since 2018 [2026]
- Steam BrokenPipe Flaw: SYSTEM Access, 0 CVE, 6 Months [2026]
- BigDiskBuster Defender Zero-Day: 0 CVE, 0 Patch [2026]
- Meta Muse Zero-Day: 1 Setting Exposes 50+ Commands [2026]
- Migrate Passkeys on Android: 12 Steps, 4 Apps Only [2026]
