Two vulnerabilities in the latest build of OxygenOS could let a malicious Android app run code with full root privileges on OnePlus devices, including the newly released OnePlus 15, without ever asking the user for a single permission. The flaws work by targeting privileged system services that are already running with elevated access, rather than trying to convince a user to grant something suspicious.

That distinction matters. Android’s permission model is built around the idea that a user can look at what an app is requesting and make an informed judgment about the risk. An app that asks for nothing at all reads, on the surface, as low-risk. These findings suggest that assumption can be quietly wrong if a device manufacturer ships privileged services that don’t properly check who is asking them to do something.

How the Attack Would Work

The issue centers on OxygenOS services that run with elevated privileges and are reachable by any app installed on the device. If one of these services fails to properly verify the identity of the caller, check for a signature-level permission, or validate its inputs, an untrusted app could send it a crafted request that triggers actions well beyond what a regular app should ever be able to do. In the scenario described by the researcher, that outcome is arbitrary code execution as root — the most privileged account on an Android device.

Root access of that kind would give an attacker sweeping control: reading protected data, altering security settings, planting persistent malicious components, interfering with other installed apps, or disabling security tooling outright. The real-world severity would still depend on the exact behavior of the vulnerable service, the specific device configuration, and whether any additional conditions need to be met to trigger it — details that have not been made public.

Responsible Disclosure and a Wider Footprint

The findings were reported to OnePlus by researcher Rasmus Moorats. OnePlus’s security response center confirmed its team had validated the report and scheduled a fix, and — notably — said in correspondence dated May 20, 2026, that the underlying issue affects “all series of OPPO terminal products with universal security risks.” Since OnePlus operates under the broader OPPO umbrella, that statement suggests the vulnerable components may not be limited to a single phone model or even a single brand.

OnePlus has asked the researcher not to independently publish a full technical writeup, proof-of-concept, or exploitation walkthrough — including after patches ship — and says it retains final say over how and when the vulnerability details are disclosed publicly. The company has pointed researchers toward its official bug bounty channels, including HackerOne, and says it plans a unified public announcement along with researcher credit through its security honor roll once fixes are broadly available.

No Fix Timeline Yet, So Caution Is the Best Defense

As of now, OnePlus has not published which specific OxygenOS versions are affected or when a public patch will land. Until that information is available, there isn’t a version number users can check against to confirm whether their device is exposed.

In the meantime, security-conscious users and administrators can reduce their exposure with a few practical steps:

• Install OxygenOS security updates as soon as OnePlus makes them available, rather than deferring them
• Avoid sideloading apps from outside official app stores, since this is the most likely delivery path for an exploit targeting this class of bug
• Periodically review installed apps and remove anything from unfamiliar or unverified developers
• For enterprises managing fleets of OnePlus or OPPO devices, flag any device running an outdated OS build and restrict installation from unofficial sources through mobile device management policy

A Reminder About Vendor-Added Attack Surface

Android’s core permission model is generally well-regarded from a security standpoint, but this case is a reminder that it only protects users from risks the model was designed to cover. Vendor-specific system services — the customizations manufacturers add on top of stock Android — sit outside that model’s normal scrutiny, and a single service that doesn’t check who’s calling it can undo the protection a “zero-permission” app is supposed to imply.