OnePlus 15 zero-permission root exploit: critical OxygenOS flaws expose privileged services to any installed app

Two vulnerabilities in OxygenOS let a malicious app with zero Android permissions run arbitrary code as root, affecting the OnePlus 15 and potentially the entire OPPO device ecosystem. OnePlus has confirmed the flaws and scheduled a fix, but has told the researcher not to publish technical details.

The vulnerability at a glance

Security researcher Rasmus Moorats has disclosed two critical vulnerabilities in OnePlus’s OxygenOS that undermine Android’s permission-based security model. The flaws, affecting the OnePlus 15 and potentially all OPPO-manufactured devices running shared system components, let any installed app, regardless of whether it requested or was granted a single permission, invoke privileged system services and get root-level code execution.

The implications are severe. Android’s trust model assumes that an app requesting no permissions is confined to a tightly limited sandbox. Users who install a flashlight app, a calculator, or any other zero-permission utility reasonably expect it can’t read their messages, access their camera, change system settings, or exfiltrate data. These OxygenOS vulnerabilities break that assumption by exposing internal privileged services that don’t adequately verify who’s calling them or validate their input.

OnePlus’s response is what makes this notable, and somewhat controversial. The company’s Security Response Center confirmed the vulnerabilities, validated the technical findings, and committed to fixing them. But OnePlus also told the researcher not to independently publish a full technical analysis, exploitation method, or risk mechanism, even after patches ship. The company says it retains “final control over public vulnerability disclosures” submitted through its bug bounty program, a position that has drawn criticism from the security research community over transparency and coordinated disclosure norms.

In an email dated May 20, 2026, OnePlus’s Security Response Center acknowledged that the affected components represent “universal security risks” spanning “all series of OPPO terminal products,” meaning the vulnerable code isn’t isolated to one device but is embedded in shared system libraries or services distributed across the broader OPPO ecosystem, which includes OnePlus, OPPO, Realme, and potentially other brands under the BBK Electronics umbrella.

Understanding Android’s permission model, and why this matters

To see why these OnePlus 15 vulnerabilities matter, it helps to understand how Android is designed to protect users. Since Android 6.0 (Marshmallow), apps have had to explicitly request access to sensitive capabilities (camera, microphone, location, contacts, storage, and so on), and users grant those permissions through system dialogs. Apps that request no permissions get a minimal sandbox: their own private data directory and a handful of non-sensitive system APIs.

Android enforces this through Linux user IDs (each app runs as a unique UID), SELinux mandatory access control policies, Binder IPC permission checks, and signature-level permission enforcement for system services. When an app tries to talk to a system service, say the Package Manager, the Account Manager, or a hardware abstraction layer, the Binder framework checks the caller’s UID, confirms it holds the required permission, and enforces SELinux context restrictions before the service does anything.

Signature-level permissions sit at the top of that hierarchy. Unlike normal or dangerous permissions users grant at runtime, signature permissions are only granted automatically to apps signed with the same certificate as the system image or the privileged service itself. That means only platform-signed components, typically pre-installed system apps or OEM services, can talk to deeply privileged subsystems. A third-party app from the Play Store or sideloaded by a user should never pass a signature-level check unless the developer somehow got hold of the OEM’s platform signing key.

The OnePlus 15 vulnerabilities point to a failure in that chain. The affected OxygenOS services are reportedly reachable by apps holding no permission at all, not dangerous, not normal, not signature-level. That suggests one of three things: the services were registered in the system’s ServiceManager without proper permission annotations, the Binder transaction handlers don’t verify caller identity before running sensitive operations, or input-validation gaps let crafted requests slip past whatever checks do exist.

The upshot is that the Android permission prompt, the visible, user-facing gate billions of people rely on, becomes irrelevant. An attacker doesn’t need to trick a user into granting camera access or location tracking. They just install an app that requests nothing, and that app can call the vulnerable OxygenOS service directly to execute code as root.

Technical anatomy of the attack vector

OnePlus has restricted publication of the granular technical details, but the disclosure and the broader context of Android OEM vulnerability research let us reconstruct the likely mechanics with some specificity.

Exposed privileged services in OxygenOS

OxygenOS, like ColorOS (OPPO’s primary Android skin) and Realme UI, ships with proprietary system services beyond what’s in stock AOSP builds: custom gesture engines, game-mode optimizations, charging controllers, display calibration daemons, fingerprint sensor interfaces, camera processing pipelines, and IPC bridges for OnePlus’s cross-device features.

Each service registers with Android’s ServiceManager and becomes reachable via Binder IPC. In a properly secured implementation, the service’s onTransact() method or its AIDL-defined interface handlers would verify the calling UID against an allowlist, check signature-level permissions, or validate input before doing anything privileged. The OnePlus 15 flaws indicate at least two services skip these checks.

Caller identity bypass

The most likely failure is a missing or broken checkCallingPermission() or enforceCallingOrSelfPermission() call inside the service’s Binder handler. When a remote process invokes a method on a system service via Binder, the receiving service can call Binder.getCallingUid() and Binder.getCallingPid() to identify the caller and check that against permission databases. If a developer omits these checks, or implements them in a code path that can be sidestepped with the right input, any process on the device can invoke the service’s methods.

For a zero-permission exploit to reach root, the vulnerable service itself has to run with root privileges (UID 0) or hold Linux capabilities (like CAP_SYS_ADMIN or CAP_SETUID) that allow privilege escalation. Many OEM system services run as root or with elevated SELinux contexts (such as u:r:platform_app:s0 or a custom vendor context) to reach hardware interfaces or modify system partitions. If a service like that accepts unauthenticated input and hands it to a command-execution function, a file write, or a dynamic library loader without sanitizing it, the attacker gets code execution at the service’s privilege level.

Input validation failures and code execution

The second vulnerability likely involves insufficient input validation on data passed to the privileged service. Common patterns in this class of OEM bug include:

• Command injection via Runtime.exec() or ProcessBuilder: the service builds a shell command from user-supplied input without escaping it, letting an attacker inject arbitrary commands at the service’s privilege level.
• Path traversal in file operations: the service reads or writes files based on caller-supplied paths without canonicalizing them or checking they stay inside expected directories, opening the door to writes at /system/bin/ or /data/local/tmp/.
• Unsafe deserialization: the service accepts serialized objects or structured data from untrusted callers and processes them via reflection or dynamic class loading, allowing arbitrary code instantiation.
• Native library loading: the service calls System.loadLibrary() or dlopen() with a path an attacker can influence, letting them load a malicious shared object into the service’s process.

Any of these, in a service running as root or with equivalent capabilities, turns a zero-permission app into a full device-compromise tool.

The zero-permission constraint bypass

What sets this attack apart from typical Android malware is the complete absence of permission requirements. Ordinary malware usually asks for dangerous permissions (SMS, contacts, accessibility services, device admin) and relies on social engineering to get users to grant them. More sophisticated attacks exploit the permission-granting mechanism itself or abuse accessibility services.

The OnePlus 15 flaws remove even that friction. The malicious app’s AndroidManifest.xml has no <uses-permission> entries. It installs silently, no runtime permission dialogs. The user sees no prompt, no warning, nothing suggesting the app intends to touch privileged system components. It looks like the most harmless kind of software on the phone.

Once installed and launched (or triggered by a broadcast receiver, content-provider query, or background service), the app builds a Binder transaction targeting the vulnerable OxygenOS service, packages the exploit payload, and sends it. The service, running as root, processes the request without checking who’s calling or what they’re allowed to do, and runs the attacker’s payload at the highest privilege level the device has.

Scope of impact: beyond the OnePlus 15

OnePlus’s acknowledgment that the vulnerabilities affect “all series of OPPO terminal products with universal security risks” widens the potential blast radius considerably. Under BBK Electronics, OPPO, OnePlus, Realme, and (in some markets) vivo share significant software infrastructure. ColorOS, OxygenOS, and Realme UI are all built on common foundational layers, and many system services, particularly ones handling hardware abstraction, power management, camera processing, and cross-device connectivity, are developed once and deployed across brands with minor configuration changes.

That shared-code architecture means a vulnerability in a privileged service on the OnePlus 15 likely exists in identical or near-identical form on OPPO Find series devices, Reno series handsets, Realme GT and Number series phones, and potentially tablets and IoT devices on the same platform. The “universal security risk” language from OnePlus’s security team suggests the vulnerable component isn’t a OnePlus-only customization but a foundational service inherited from the shared OPPO/BBK codebase.

For enterprises, that broad reach is a real problem. Organizations running fleets of OPPO or Realme devices alongside OnePlus handsets, common in Asian and European markets, should treat all such devices as potentially affected until vendor patch information narrows the scope. The attack surface isn’t a single flagship model, it’s potentially hundreds of device variants across multiple product lines and price tiers.

The OnePlus disclosure controversy: transparency vs. control

Beyond the technical vulnerabilities, there’s a second story here: the disclosure process itself. OnePlus telling researcher Rasmus Moorats not to independently publish a complete technical analysis, exploitation method, or risk mechanism, even after fixes ship, is a restrictive reading of coordinated vulnerability disclosure norms.

Industry-standard practice, codified in frameworks like FIRST’s Coordinated Vulnerability Disclosure guidelines and widely adopted by major tech companies, holds that researchers who report vulnerabilities in good faith keep the right to publish technical details after a reasonable remediation window (typically 90 days, per Google’s Project Zero standard) or once the vendor ships a fix. The reasoning: public technical disclosure lets the broader security community understand the vulnerability class, build detection signatures, audit similar code elsewhere, and hold vendors accountable for how complete their patches actually are.

OnePlus’s position, that it retains “final control over public vulnerability disclosures submitted through its security program” and will issue a “unified public announcement” on its own timeline, effectively hands the vendor unilateral authority over what security information the public gets to see. The company has directed the researcher to its official security platform or HackerOne for submission and bounty processing, and says it will credit researchers through a “security honor list” once fixes are fully released.

This isn’t unheard of among OEMs, but it raises real concerns. Without independent technical analysis, the security community can’t verify whether the patch addresses the root cause or just blocks the specific exploitation path the researcher found. Security researchers and pen testers can’t check whether their organizations’ OnePlus or OPPO devices remain vulnerable to variant attacks against the same service. Antivirus and EDR vendors can’t build behavioral signatures without understanding the exploitation mechanics.

The restriction also has a chilling effect on future research. If researchers know that reporting through official channels means the vendor controls publication indefinitely, the incentive to use those channels drops. Some may go for full disclosure without vendor coordination, sell findings on gray markets, or just stop researching OnePlus and OPPO devices, none of which improves user security.

No public proof-of-concept exploit code or detailed technical write-up came with the initial disclosure. What’s public is limited to the vulnerability’s existence, its general class (privileged service exploitation for root code execution), its zero-permission requirement, and OnePlus’s confirmation and remediation commitment. That’s a thin basis for the security community to assess risk or build mitigations independently, and it’s thin because the vendor decided it should be.

Root access on Android: what full compromise actually means

For readers less familiar with Android internals: root access on an Android device is the equivalent of SYSTEM-level compromise on Windows or root on Linux. The root user (UID 0) sits above all permission boundaries, SELinux restrictions (unless SELinux is enforcing a policy that constrains even root, which stock Android partially does), and app sandboxing.

An attacker with root code execution on a OnePlus 15 can:

• Read all application data: access the private data directories of every installed app, including encrypted databases, auth tokens, cached credentials, and chat histories. Android’s file-based encryption ties each app’s data to a key derived from the lock-screen credential, but root access combined with the device’s keymaster/keymint hardware-backed keystore can potentially defeat that, especially if the device is unlocked at the time of exploitation.
• Modify system partitions: write to /system, /vendor, and /product (subject to verified boot and dm-verity, though both can be disabled or bypassed with root), enabling persistent malware that survives a factory reset.
• Disable security mechanisms: turn off Google Play Protect, switch SELinux from enforcing to permissive, deactivate verified boot, uninstall security apps, and block future OTA security updates.
• Install persistent implants: deploy rootkits, kernel modules (if the bootloader allows it), or system-level daemons that run on every boot below the Android framework layer, making them very hard for standard antivirus or mobile threat defense tools to catch.
• Intercept and modify network traffic: install rogue CA certificates at the system level, run transparent proxies, and intercept TLS traffic for every app on the device.
• Access hardware peripherals: reach camera, microphone, GPS, NFC, and cellular modem hardware through HAL interfaces, enabling surveillance that bypasses every app-level permission check.
• Pivot to connected devices: use the compromised phone as a network pivot against other devices on the same Wi-Fi network, or exploit Bluetooth and NFC to compromise nearby devices.

For enterprises, that means corporate data access, VPN credential theft, MDM agent tampering, and lateral movement into corporate networks. For individuals: financial fraud through banking app compromise, identity theft, surveillance, and ransomware.

OEM privileged service vulnerabilities aren’t new

The OnePlus 15 disclosure fits a well-established pattern of Android OEM vulnerabilities in inadequately secured proprietary system services. This isn’t the first time a major manufacturer has shipped software with privileged services that untrusted apps could invoke.

In 2023, researchers found vulnerabilities in Samsung’s Galaxy devices where pre-installed system services could be invoked by third-party apps to perform privileged operations, including arbitrary file writes and code execution. Qualcomm’s Snapdragon platform has racked up numerous CVEs tied to proprietary services and drivers reachable from the app layer. MediaTek chipset-level services have seen similar privilege-escalation exploits.

Closer to the OnePlus 15 case: researchers have previously found local privilege-escalation vulnerabilities in OPPO’s ColorOS and OnePlus’s OxygenOS through exposed system services. In 2022, a vulnerability in OxygenOS let a local attacker escalate privileges through a component tied to the device’s update mechanism. In 2021, multiple CVEs were assigned to OPPO devices for insufficient permission enforcement in system services, exploitable for arbitrary file access or code execution.

This keeps happening across OEMs because AOSP’s permission framework is well-audited, but the hundreds of custom services, daemons, and utilities OEMs add to differentiate their products often get less rigorous review. Teams focused on shipping features may not apply the same security discipline to internal service interfaces that Google applies to core Android framework services.

BBK’s shared-code model makes this worse: a single vulnerable service written for ColorOS and inherited by OxygenOS and Realme UI turns one coding error into a multi-brand exposure. The “universal security risk” language from OnePlus’s security team confirms that’s exactly what happened here.

Remediation timeline and patch expectations

As of publication, OnePlus has confirmed the vulnerabilities and scheduled a fix but hasn’t publicly disclosed affected OxygenOS build numbers, a patch release date, or CVE identifiers for the two flaws. The company’s security team validated the report and acknowledged the issues in May 2026, which means patches have likely been in development for around four months.

OnePlus typically releases monthly security updates aligned with Google’s Android Security Bulletin, plus vendor-specific patches as needed, and has previously pushed out-of-band updates for critical flaws on flagship devices like the OnePlus 15.

Watch the official OnePlus community forums, the Security Response Center page, and System Update settings for availability. The fix will likely come as an incremental OTA update to OxygenOS 15.x builds. Users on the OnePlus 15, 15 Pro, 15R, and potentially the OnePlus 13 and 13R should prioritize installing it.

Given the OPPO-wide scope OnePlus’s security team described, OPPO and Realme users should watch their own update channels too. Since the fix has to address the vulnerable service at the shared-component level, it should roll out across brands simultaneously or in close succession.

Immediate mitigation guidance

Until patches are out and installed:

For individual users:

• Restrict where apps come from. The attack needs a malicious app installed on the device. Avoid sideloading APKs from unofficial sources, third-party stores, or links from SMS, email, or social media. Stick to the Play Store, which runs automated malware scanning through Play Protect and verifies developer identity.
• Audit installed apps. Go through everything on your OnePlus or OPPO device. Remove anything you don’t recognize, didn’t intentionally install, or that came pre-installed by a carrier or retailer with no clear purpose. Pay particular attention to zero-permission apps, since that’s exactly the profile that would exploit these flaws without raising suspicion.
• Turn on Google Play Protect and let it scan regularly. It won’t catch a zero-day exploit of a vendor service, but it can flag known malicious apps and suspicious behavior.
• Disable installation from unknown sources: Settings > Security > Install unknown apps, and check that no browser, file manager, or messaging app has permission to install APKs. On Android 15 this setting is per-app, so check each one.
• Watch for unexplained battery drain, unexpected network activity, or unfamiliar processes. Non-specific signs, but worth noticing.

For enterprise administrators:

• Enforce update compliance through your MDM/EMM platform: flag and restrict OnePlus, OPPO, and Realme devices on OxygenOS, ColorOS, or Realme UI builds that haven’t received the patch, with a patch-lag policy appropriate to your risk tolerance.
• Restrict sideloading at the policy level using Android Enterprise managed configuration, and deploy app allowlists or blocklists.
• Monitor for anomalous behavior: unusual process creation, unexpected Binder transactions to system services, SELinux policy violations, if your SOC covers mobile endpoints.
• If a managed device is suspected of compromise, start incident response: isolate the device, forensically image it, rotate credentials for any accounts accessed from it, and assess corporate data exposure.
• Contact OnePlus enterprise support or your device procurement partner for patch timelines, affected build numbers, and confirmation that the fix covers both vulnerabilities.

The broader implications for Android OEM security

This case points to a persistent gap in the Android ecosystem: the difference between AOSP’s well-audited core framework and the sprawling, less-scrutinized proprietary layers OEMs build on top of it. Google invests heavily in hardening the core OS, the permission model, SELinux policies, verified boot, and the app sandbox. But once OEMs stack dozens or hundreds of proprietary services and daemons on that foundation, the attack surface grows, and the security guarantee AOSP provides is only as strong as the weakest OEM-added component.

It also shows the tension between vendor-controlled disclosure and the security community’s need for technical transparency. When a vulnerability potentially affects hundreds of device models across multiple brands, the community’s ability to independently assess risk, build detection, and verify that a patch is actually complete depends on having technical details available. Vendor-imposed publication restrictions, meant to keep unpatched devices safe, can end up delaying the broader ecosystem’s response and letting patch quality go unchecked.

For OnePlus and OPPO, this lands at an awkward time. Both brands are competing hard in the premium segment, where security and privacy are increasingly part of the pitch. A critical root vulnerability in the OnePlus 15’s OS, one that OnePlus has restricted from full public disclosure, carries reputational risk that reaches well past the technical crowd into mainstream buyers and enterprise procurement.

Expect the security research community to watch closely for the eventual patch, how complete it turns out to be, whether OnePlus’s “unified public announcement” includes any real technical detail, and whether the company’s disclosure policy shifts in response to the pushback. How this plays out will set a precedent for how OnePlus and the wider BBK ecosystem deal with independent researchers going forward.

What we know and what remains unknown

Confirmed:

• Two vulnerabilities exist in OxygenOS affecting the OnePlus 15
• The flaws let zero-permission apps achieve root code execution
• The attack vector involves exposed privileged OxygenOS services
• OnePlus’s security team has validated the findings
• The vulnerabilities affect “all series of OPPO terminal products”
• Remediation has been scheduled
• Researcher Rasmus Moorats submitted the findings through official channels
• No public proof-of-concept or exploit code has been released
• OnePlus has restricted the researcher from publishing technical details

Unknown / not yet disclosed:

• Specific CVE identifiers for the two vulnerabilities
• Exact OxygenOS build numbers affected
• Precise patch release date
• Which specific OxygenOS services are vulnerable
• Exact exploitation technique (command injection, path traversal, deserialization, etc.)
• Whether exploitation requires a specific device state (unlocked, developer mode enabled, etc.)
• Whether the vulnerabilities are being actively exploited
• Full list of affected OPPO, Realme, and other BBK device models
• Whether the patch will be backported to older OxygenOS/ColorOS versions

Final assessment

The OnePlus 15 zero-permission root vulnerabilities are a serious failure in how one of Android’s major OEMs implemented the platform’s security model. An app that needs no permissions, triggers no prompts, and shows no warnings shouldn’t be able to run code as root, and the fact that one can here breaks the trust assumption Android users and enterprise security teams depend on. Because the affected components are shared across the OPPO ecosystem, this isn’t a single-device bug, it’s closer to a platform-wide event.

OnePlus’s restriction on technical disclosure, understandable as a vendor risk-management call, limits how well the security community can assess and respond to the threat on its own. Users and administrators are left relying on OnePlus’s patch timeline without a way to independently verify the fix is complete or build interim detection.

For now, the practical defense is straightforward: restrict app installation to trusted sources, audit what’s already installed, and apply the OxygenOS security update as soon as it’s out. Enterprises running OnePlus, OPPO, or Realme fleets should tighten patch management and sideloading policies until the vendor confirms full remediation.

Android’s permission model is only as secure as every system service running on the device, including the proprietary ones OEMs add and rarely open up to public scrutiny the way AOSP components get. This won’t be the last Android device to run into this vulnerability class. Whether it’s among the last where the vendor controls the story instead of independent researchers is a separate question, and one worth asking.