Back to Intelligence

Unpatched OnePlus OxygenOS Root Flaw Chain (Also Affecting OPPO): Detection and Hardening Guide for Android Fleets

SA
Security Arsenal Team
September 24, 2026
13 min read

Security researcher Rasmus Moorats has demonstrated a full root chain against the OnePlus 15 running the latest OxygenOS build — and the attack requires almost nothing from the victim. A malicious application, installed by the device owner and requesting no special permissions, can chain two vulnerabilities in OnePlus's own system software to escalate to root: the highest privilege level on an Android device. According to reporting by The Hacker News, OnePlus confirmed to the researcher that the same flaws affect many more OnePlus devices and devices from OPPO (which shares the ColorOS/OxygenOS codebase lineage), though the full affected model list has not been publicly enumerated.

Why defenders should care right now:

  • No patch is available. This is an unpatched, working privilege-escalation chain on current-generation hardware.
  • The barrier to weaponization is low. The trigger app needs no dangerous Android permissions, which defeats the permission-review and runtime-prompt controls most mobile threat defense (MTD) products lean on.
  • Root breaks the enterprise trust model. A rooted device defeats SafetyNet/Play Integrity attestation-based conditional access, can read protected app sandboxes (including MFA authenticator seeds, VPN profiles, and email), and can persist below the OS.
  • The delivery vector is a normal app install. Enterprise sideloading, third-party app stores, social-engineered installs, and supply-chain tampering of otherwise benign apps are all viable delivery paths.

Until OnePlus ships fixes, detection of rooting artifacts and aggressive control of application installation are your only compensating controls. This post gives you both.

Technical Analysis

Affected products and platforms

AttributeDetail
Confirmed affectedOnePlus 15 running latest OxygenOS (at time of disclosure)
Vendor-confirmed scope"Many more" OnePlus devices; OPPO devices sharing the affected software
ComponentTwo chained flaws in OnePlus/OPPO proprietary system software (not AOSP core, per reporting)
CVENone assigned at time of writing — no CVE identifier has been published in the disclosure
CVSSNot scored yet
Patch statusUnpatched

How the attack chain works (defender's view)

The full technical details of the two flaws have not been made public, but the reported characteristics let us map the chain precisely enough to defend it:

  1. Initial execution — zero-permission app. The attacker application declares no dangerous permissions in its manifest. This means it survives Play Store policy review, Play Protect behavioral heuristics keyed on permission abuse, and user scrutiny. Delivery is simply "get the user to install an app" — phishing, QR-code sideloading, third-party stores, or a trojanized legitimate app.
  2. First flaw — privilege boundary crossing within OnePlus system software. One OnePlus-specific component (a privileged service, system app, or vendor IPC endpoint) can be abused by an unprivileged app context. This is consistent with the long history of vendor-bound service vulnerabilities on Android: exported components, binder endpoints, or system-app content providers reachable without permission checks.
  3. Second flaw — escalation to root. The intermediate privilege gained from flaw one is leveraged against a second OnePlus component to obtain root execution. Once root is achieved, the attacker can write to /system, execute su-equivalent binaries, disable or remount SELinux protections, and persist below the Android runtime.
  4. Post-exploitation observable artifacts. Regardless of the specific bugs, rooting produces highly consistent forensic artifacts: su execution from an app UID (not shell or root), SELinux avc: denied churn followed by permissive-mode changes, new binaries in /system/bin, /system/xbin, /data/local/tmp, or /sbin, ro.secure/ro.debuggable property changes, and Play Integrity/StrongBox attestation failures.

Exploitation status

  • Public PoC: Yes — demonstrated end-to-end by the researcher on a current OnePlus 15.
  • In-the-wild exploitation: No confirmed active exploitation reported at time of writing.
  • CISA KEV: Not listed (no CVE assigned yet).
  • Risk trajectory: High. Details are expected to be published after OnePlus ships fixes, which means a weaponization window exists right now for attackers who reverse the chain, and a second, larger window the day the technical write-up drops. Patch velocity across carrier-locked OPPO/OnePlus variants is historically slow — assume exposure measured in months for parts of the fleet.

Detection & Response

Because there is no patch, your detection strategy is artifact-based: hunt for the effects of rooting, not the exploit itself. If your organization forwards Android device logs (via MDM/EMM syslog, MTD telemetry, or managed logcat collection) into a SIEM, the following detections are deployable today.

Sigma rules

These rules assume Android device logs are ingested as Linux-style syslog/process telemetry (the Android runtime sits on the Linux kernel, and enterprise log forwarders present it that way).

YAML
---
title: Android SU Binary Execution From Non-System Context
id: 3f8a1c94-2b7d-4e5a-9c16-8d4e2f7a1b35
status: experimental
description: Detects execution of su or common root-management binaries from an application UID on Android devices. Root escalation from an installed app is the end state of the unpatched OnePlus/OPPO OxygenOS privilege escalation chain reported September 2026.
references:
  - https://thehackernews.com/2026/09/unpatched-oneplus-flaws-let-installed.html
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/09/18
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection_image:
    Image|endswith:
      - '/su'
      - '/magisk'
      - '/busybox'
  selection_path:
    CommandLine|contains:
      - '/system/bin/su'
      - '/system/xbin/su'
      - '/sbin/su'
      - '/data/local/tmp/su'
  filter_system:
    User:
      - 'root'
      - 'shell'
      - 'system'
  condition: (selection_image or selection_path) and not filter_system
falsepositives:
  - Legitimate enterprise-rooted test devices
  - Developer/QA devices intentionally rooted for build validation
level: high
---
title: Android SELinux Permissive Mode or Enforcement Weakening
id: 91d2e7b4-5c3a-4f68-8b12-7e9a3d5c6f48
status: experimental
description: Detects attempts to set SELinux to permissive mode or remount system partitions writable on Android devices, a common post-root action following exploitation of vendor privilege escalation flaws such as the OnePlus/OPPO OxygenOS chain.
references:
  - https://thehackernews.com/2026/09/unpatched-oneplus-flaws-let-installed.html
  - https://attack.mitre.org/techniques/T1562/
author: Security Arsenal
date: 2026/09/18
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  category: process_creation
  product: linux
detection:
  selection_setenforce:
    CommandLine|contains:
      - 'setenforce 0'
      - 'setenforce permissive'
  selection_remount:
    CommandLine|contains:
      - 'mount -o remount,rw /system'
      - 'remount,rw /vendor'
      - 'remount,rw /product'
  condition: 1 of selection_*
falsepositives:
  - OEM factory diagnostics tooling (rare on production builds)
  - Intentionally rooted development devices
level: high
---
title: Sideloaded APK Installation Outside Managed Store on Corporate Android Fleet
id: 5e7b3a91-4d28-4c5f-9a47-2c8e1b6d3f52
status: experimental
description: Detects package installation via shell/package manager from non-managed sources on managed Android devices. The OnePlus/OPPO root chain is delivered via an installed application with no special permissions, making sideloaded install telemetry the earliest detectable stage of the attack.
references:
  - https://thehackernews.com/2026/09/unpatched-oneplus-flaws-let-installed.html
  - https://attack.mitre.org/techniques/T1476/
author: Security Arsenal
date: 2026/09/18
tags:
  - attack.initial_access
  - attack.t1476
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains:
      - 'pm install '
      - 'cmd package install'
      - 'adb install'
  filter_managed:
    User:
      - 'mdm_agent'
      - 'device_policy'
  condition: selection and not filter_managed
falsepositives:
  - Developer devices with ADB enabled for legitimate build deployment
  - IT staging/provisioning workflows (tune by provisioning window)
level: medium

KQL — Microsoft Sentinel / Defender

Assumes Android fleet telemetry reaches Sentinel via Syslog/CEF ingestion from your MDM or MTD platform (Microsoft Defender for Endpoint on Android, Lookout, Zimperium, etc.), or via CommonSecurityLog. The hunt pivots on root artifacts and SELinux state changes.

KQL — Microsoft Sentinel / Defender
// Hunt: root escalation artifacts on managed Android fleet (OnePlus/OPPO exposure)
// Tables: Syslog (MDM/MTD forwarded logcat + audit logs), fallback CommonSecurityLog
let rootIndicators = dynamic(["su", "setenforce 0", "magisk", "remount,rw", "avc: denied", "ro.secure=0", "Superuser.apk"]);
union isfuzzy=true
    (Syslog
    | where TimeGenerated > ago(7d)
    | where SyslogMessage has_any (rootIndicators)
    | extend Indicator = extract(@"(setenforce 0|magisk|remount,rw|avc: denied|ro\.secure=0|Superuser\.apk|/su\b)", 1, SyslogMessage)
    | project TimeGenerated, Computer, HostIP, ProcessName, Indicator, SyslogMessage, Source = "Syslog"),
    (CommonSecurityLog
    | where TimeGenerated > ago(7d)
    | where Message has_any (rootIndicators)
    | extend Indicator = extract(@"(setenforce 0|magisk|remount,rw|avc: denied|ro\.secure=0|Superuser\.apk|/su\b)", 1, Message)
    | project TimeGenerated, Computer = DeviceName, HostIP = SourceIP, ProcessName = ApplicationProtocol, Indicator, SyslogMessage = Message, Source = "CEF")
| summarize Events = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            Indicators = make_set(Indicator) by Computer, HostIP, ProcessName, Source
// Devices showing BOTH su execution and SELinux weakening are high-confidence rooted
| extend Confidence = iff(array_length(Indicators) >= 2, "High — probable rooted device", "Medium — single artifact, investigate")
| order by Confidence desc, Events desc;

Follow-up triage query to pull the full timeline for any device flagged High:

KQL — Microsoft Sentinel / Defender
// Timeline for a flagged device — replace <DEVICE_NAME>
let targetDevice = "<DEVICE_NAME>";
union isfuzzy=true
    (Syslog | where Computer == targetDevice),
    (CommonSecurityLog | where DeviceName == targetDevice)
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any (dynamic(["pm install", "cmd package install", "su", "setenforce", "magisk", "avc", "mount", "remount"]))
   or Message has_any (dynamic(["pm install", "cmd package install", "su", "setenforce", "magisk", "avc", "mount", "remount"]))
| order by TimeGenerated asc
| project TimeGenerated, Computer, ProcessName, Message = coalesce(SyslogMessage, Message);

Velociraptor VQL — endpoint artifact hunt

For organizations running Velociraptor against rooted-capable Android test devices via an on-device collection agent, or against Linux-based MDM/EMM infrastructure hosting device backups and pulled file systems, this artifact hunts for canonical rooting artifacts.

VQL — Velociraptor
-- Hunt for Android rooting artifacts consistent with post-exploitation state
-- of the OnePlus/OPPO OxygenOS privilege escalation chain
-- Deploy against device filesystem mounts, backups, or on-device collectors

SELECT FullPath, Size, Mtime, Btime,
       CASE
         WHEN FullPath =~ 'su$' THEN 'su binary present'
         WHEN FullPath =~ '(?i)magisk|zygisk|kernelsu' THEN 'root manager framework'
         WHEN FullPath =~ '(?i)superuser|supersu' THEN 'root management APK'
       END AS ArtifactType
FROM glob(globs=[
  '**/system/bin/su',
  '**/system/xbin/su',
  '**/sbin/su',
  '**/data/local/tmp/su',
  '**/data/local/tmp/**magisk**',
  '**/data/adb/magisk/**',
  '**/data/adb/ksu/**',
  '**/*Superuser*.apk',
  '**/*SuperSU*.apk'
])
WHERE FullPath !~ '(?i)baseline|known_good'
ORDER BY Mtime DESC

Pair it with a process hunt for live root-manager activity on instrumented hosts:

VQL — Velociraptor
-- Live process hunt for root managers and shell-with-root on instrumented Android/Linux endpoints
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(magiskd|kernelsu|/su\b|setenforce|daemonsu)'
   OR (Name =~ 'sh' AND Username =~ 'root' AND Ppid > 2)
ORDER BY CreateTime DESC

Verification and hardening script (Bash)

Run this over ADB against fleet devices (or adapt for your MDM's remote shell capability) to audit current exposure state: sideloading posture, root artifacts, SELinux enforcement, and installed packages outside managed sources.

Bash / Shell
#!/usr/bin/env bash
# Security Arsenal — Android root-exposure audit for OnePlus/OPPO fleets
# Usage: ./android_root_audit.sh <device_serial>
# Requires: adb, device connected with ADB authorized (managed enrollment recommended)
set -euo pipefail
SERIAL="${1:?Usage: $0 <device_serial>}"
ADB="adb -s ${SERIAL} shell"
REPORT="root_audit_${SERIAL}_$(date +%Y%m%d_%H%M%S).txt"

echo "=== Android Root Exposure Audit: ${SERIAL} ===" | tee "${REPORT}"

# 1. Device identity — flag OnePlus/OPPO models pending the vendor fix
echo -e "\n[1] Device identity" | tee -a "${REPORT}"
${ADB} "getprop ro.product.manufacturer; getprop ro.product.model; getprop ro.build.version.release; getprop ro.build.version.security_patch" | tee -a "${REPORT}"
MFR=$(${ADB} "getprop ro.product.manufacturer" | tr -d '\r')
if echo "${MFR}" | grep -qiE 'oneplus|oppo'; then
  echo "[!] AFFECTED VENDOR — unpatched OxygenOS/ColorOS root chain applies. Treat as high-risk until patched." | tee -a "${REPORT}"
fi

# 2. SELinux enforcement state — anything but Enforcing is a red flag on production devices
echo -e "\n[2] SELinux state" | tee -a "${REPORT}"
${ADB} "getenforce" | tee -a "${REPORT}"

# 3. Root artifacts
echo -e "\n[3] Root artifact check (su / magisk / kernelsu)" | tee -a "${REPORT}"
for p in /system/bin/su /system/xbin/su /sbin/su /data/local/tmp/su /data/adb/magisk /data/adb/ksu; do
  if ${ADB} "[ -e ${p} ] && echo FOUND" | grep -q FOUND; then
    echo "[!] ROOT ARTIFACT: ${p}" | tee -a "${REPORT}"
  fi
done
${ADB} "pm list packages | grep -iE 'magisk|supersu|superuser|kernelsu|zygisk'" | tee -a "${REPORT}" || true

# 4. Sideloading posture — unknown sources should be off on managed devices
echo -e "\n[4] Unknown sources / install posture" | tee -a "${REPORT}"
${ADB} "settings get global install_non_market_apps; settings get secure install_non_market_apps" | tee -a "${REPORT}"

# 5. Recently installed packages (last 7 days) — review anything outside managed Play
echo -e "\n[5] Recently installed/updated packages" | tee -a "${REPORT}"
${ADB} "dumpsys package | grep -E 'Package \[|firstInstallTime|lastUpdateTime' | tail -n 120" | tee -a "${REPORT}"

# 6. Play Integrity hint — developer options / USB debugging should be off on prod fleet
echo -e "\n[6] Debug posture" | tee -a "${REPORT}"
${ADB} "settings get global adb_enabled; settings get global development_settings_enabled; getprop ro.debuggable; getprop ro.secure" | tee -a "${REPORT}"

echo -e "\n=== Audit complete: ${REPORT} ===" | tee -a "${REPORT}"

Remediation

There is no vendor patch at time of writing. Your remediation posture is compensating controls plus patch-readiness. In priority order:

  1. Inventory and risk-tier the fleet today. Enumerate every OnePlus and OPPO device in your MDM/EMM. Until OnePlus publishes the affected-model list, treat all OnePlus and OPPO devices on OxygenOS/ColorOS as potentially vulnerable — the vendor told the researcher the scope is broad. Devices holding corporate email, MFA authenticators, or VPN access get priority treatment.
  2. Enforce install-source lockdown via MDM. Disable unknown-sources installation device-wide (Android Enterprise: install_unknown_sources_allowed = false; block the "Install unknown apps" toggle per-app). The delivery vector is an installed app — cutting off sideloading removes the most realistic infection path. Audit existing installed packages against an allowlist.
  3. Force Play Integrity / device attestation into conditional access. Configure your identity provider (Entra ID, Okta) to deny or step-up-authenticate sessions from devices failing Play Integrity MEETS_DEVICE_INTEGRITY / MEETS_STRONG_INTEGRITY verdicts. A device rooted via this chain will fail attestation — this converts an unpatched device compromise into an access denial.
  4. Root-detection compliance policies. In your MDM (Intune, Workspace ONE, etc.), set rooted/jailbroken device detection to non-compliant → block corporate data / wipe work profile. Validate the detection actually fires: use the audit script above against a test device.
  5. Deploy or tighten MTD. Mobile threat defense (Defender for Endpoint on Android, Lookout, Zimperium) with on-device root detection provides the runtime signal your SIEM hunts above consume. Ensure telemetry forwarding to Sentinel/your SIEM is actually enabled — this is the most common gap we find during assessments.
  6. Patch-readiness. Subscribe to OnePlus security bulletins and OPPO security updates. When the OxygenOS/ColorOS fix ships, push it as an emergency change with a defined SLA (we recommend 7 days for internet-adjacent and BYOD-adjacent populations, given a public PoC exists). Expect carrier-branded OPPO variants to lag — track them separately.
  7. User guidance for BYOD. Communicate plainly: do not install apps from links, QR codes, or third-party stores on OnePlus/OPPO devices until patched; treat unexpected app-install prompts as phishing. The attack needs the user to install something — awareness is a real control here.
  8. Incident response trigger. Any device flagged by the detections above (su execution from app UID, SELinux permissive, attestation failure) should be treated as a full compromise: revoke sessions and tokens, rotate credentials reachable from the device, and consider the work profile burned. Root on Android defeats the sandbox retroactively — assume data already on the device was exposed.

The uncomfortable reality: for the exposed window, prevention is thin. Detection of the rooted state and automatic revocation of corporate trust are what stand between this chain and a data breach. Build that muscle now, before the technical write-up makes the chain script-kiddie accessible.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.