A Zero-Permission App Just Rooted a Fully-Patched OnePlus 15

Picture the compliance dashboard. Green across the board. The OnePlus in your BYOD pool is running the latest OxygenOS, Play Protect is on, the MDM agent checks in every few minutes and reports the device as compliant. Conditional Access waves it through to mail, SharePoint, the lot.

Now picture the app the user installed the night before — a flashlight, a battery widget, whatever — that requested zero special permissions on install. No SMS, no accessibility, no device admin. The kind of app nobody thinks twice about. That app is now running as root. It can read the keystrokes going into the authenticator app, pull tokens out of the credential store, and lie to the MDM agent about all of it.

That’s the situation a researcher demonstrated on a OnePlus 15 running current OxygenOS, as reported by The Hacker News. Two flaws, both in OnePlus’s own code — not stock Android — chained into a full local privilege escalation. OnePlus has been told. There is no public patch and no committed timeline.

What actually broke

Android’s security model rests on a simple bargain: apps are sandboxed and get only what the user grants them. Privileged work — anything touching the system or root — happens behind interfaces that are supposed to check who is calling before they act. Break that check and the sandbox stops meaning anything.

Both bugs here live in OEM-added components, the software OnePlus layers on top of AOSP to make OxygenOS OxygenOS. That distinction matters, so let me be blunt about it: this is not an Android-wide flaw. A Pixel or a Galaxy is not affected by this chain. It’s the vendor’s additions that are broken.

Described generically — because reproduction detail helps attackers, not defenders — the chain works like this. The first flaw is an exposed privileged interface: a system-level component that any app on the device can talk to without holding a permission, and which fails to properly verify the caller’s identity or intent. That gets an unprivileged app a foothold inside a context it should never have reached. The second flaw is an escalation within that privileged context — a weakness that turns “I can talk to a system service” into “I am executing as root.” One bug gets you through the door nobody was watching. The second hands you the keys to the building.

The dangerous property isn’t any single bug. It’s that the entry point costs nothing. No permission request means no prompt, which means the user sees nothing to refuse. And no permission request means the standard signals reviewers and MDM policies lean on — dangerous permission groups, device-admin escalation, accessibility abuse — are all quiet. The app looks inert. It behaves inert, right up until it doesn’t.

What root buys the attacker

Root on Android is the top of the ladder. Once an app has it, the boundaries your security stack depends on are advisory at best:

• Credential and token theft. Read app-private storage, dump the keystore’s usable material, scrape session cookies and OAuth refresh tokens straight out of other apps’ sandboxes.
• Keylogging without the accessibility prompt. With root you don’t need the permission that would normally warn the user; you can hook input at a level the sandbox was supposed to hide.
• Work profile breakout. Android’s work/personal separation is enforced by the OS. Root sits underneath that enforcement, so the isolation your Android Enterprise deployment relies on stops being a wall and becomes a suggestion.
• MDM and compliance spoofing. The agent that reports “compliant, not rooted” is just another process to something running as root. It can be fed whatever answer keeps the light green — which is exactly what makes this a Conditional Access problem, not just an endpoint problem.
• Disabling endpoint protection. Mobile threat defense running as an ordinary app can be starved, sandboxed, or quietly blinded.

The through-line: every control you’d normally point to as your compensating measure runs above the privilege the attacker now holds. You can’t detect a rootkit reliably from inside the machine it owns.

Find your exposure before you argue about policy

Confirmed vulnerable: OnePlus 15 on current OxygenOS. Given the flaws sit in shared OnePlus components, treat other current OnePlus models and OxygenOS builds as suspect until OnePlus says otherwise — but don’t overstate what’s proven. Start by knowing how many OnePlus devices touch your tenant at all. Most organisations underestimate this because BYOD enrolment is quiet.

1
2
3
4
5
6
7
8
9
10
11
12
13

# Report-only. Requires Microsoft.Graph + DeviceManagementManagedDevices.Read.All
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
​
$oneplus = Get-MgDeviceManagementManagedDevice -All |
    Where-Object { $_.Manufacturer -match 'OnePlus' -or $_.Model -match 'OnePlus' }
​
$oneplus | Select-Object DeviceName, UserPrincipalName, Model, OSVersion,
    ComplianceState, ManagementAgent, LastSyncDateTime |
    Sort-Object LastSyncDateTime -Descending |
    Format-Table -AutoSize
​
"`nOnePlus devices seen: {0}" -f $oneplus.Count
$oneplus | Group-Object OSVersion | Select-Object Count, Name | Sort-Object Count -Descending

If you run Defender for Endpoint on mobile, cross-reference with your device inventory via the advanced hunting API rather than trusting the on-device rooting verdict alone — remember, a rooted device can lie to its own agent. And if you have any devices reachable over USB in a lab or kiosk context, a quick manufacturer sanity check never hurts:

1
2
3
4
5
6
7

# Read-only inventory of attached devices
for d in $(adb devices | awk 'NR>1 && $2=="device"{print $1}'); do
  mfr=$(adb -s "$d" shell getprop ro.product.manufacturer | tr -d '\r')
  model=$(adb -s "$d" shell getprop ro.product.model | tr -d '\r')
  osver=$(adb -s "$d" shell getprop ro.build.version.release | tr -d '\r')
  echo "$d  $mfr  $model  Android $osver"
done

The calls I’d make this week

There is no patch to deploy, so this is about reducing blast radius, and every option here has a cost you’ll feel.

1. Block or step down OnePlus in Conditional Access — now, for corporate-data access. The cleanest version is a compliance/filter policy that excludes OnePlus devices from access to sensitive resources until a fix ships. It will generate helpdesk tickets and irritate executives who bought their own phones. Do it anyway for anything touching regulated or high-value data; degrade to web-only/limited access if a hard block is politically impossible.
2. Kill sideloading paths. The realistic delivery vector is a benign-looking app. Enforce app protection policies, restrict installs to managed/approved sources, and disable unknown-sources installation via UEM where you can. This is the single highest-leverage control while the bugs are live.
3. Stop trusting the device’s own root verdict as your only signal. Layer Play Integrity / hardware-backed attestation into your access decisions where available, and treat behavioural anomalies — an agent that stops reporting, a device whose posture flips — as suspicious rather than benign.
4. Tell your OnePlus users something true and specific. Not “be careful what you install.” Tell them not to install anything outside your managed catalogue on a device that touches company data, and tell them why.
5. Set a review date and hold OnePlus to it. No committed timeline is itself a risk input. If a fix hasn’t landed by your next cycle, escalate from “restricted” to “unenrolled.”

The lesson: your compliance dashboard was never measuring what you thought. It was measuring what the device chose to tell you. A single vendor bug in software you didn’t write and can’t patch flipped a green tick into a lie — and the app that did it asked for nothing at all.