On 2026-09-24, security researcher Rasmus Moorats published a technical writeup (blog.nns.ee) of a two-bug exploit chain that escalates an unprivileged, zero-permission Android application to full root on OnePlus's OxygenOS, later syndicated by The Hacker News, Cyber Security News, and other outlets.

The first bug lives in AtlasService (`atlasservice`), a OnePlus telemetry/debugging system service that runs as root and accepts Binder calls without verifying the caller's identity. The service exposes a `setEvent(String8 name, String8 value)` method at Binder transaction code 2, handled internally by `OplusAtlasLogWriter::handleEvent`. When an app supplies the event name `atlas_event_multimedia_audio_dumpsys`, AtlasService calls `property_set("oplus.audio.dumpinfo.type", value)` with the attacker-controlled value and triggers `ctl.start=audiodumpinfo`. Per the service's init definition at `/system_ext/etc/init/audiodumpinfo.rc` (`user root`, `group root system everybody sdcard_rw`, `seclabel u:r:dumpstate:s0`, `oneshot`), this starts `/system_ext/bin/audioDumpInfo` as UID 0 in the `dumpstate` SELinux domain. That binary reads the attacker-controlled property and passes it, unescaped, into a `system()` shell call — a classic command-injection sink reachable with no Android permissions at all. The researcher's proof-of-concept injected the property value `x;sh</sdcard/Android/data/com.research.poc/files/boot.sh 2>&1|log -t AtlasOut;#`, using a shell metacharacter break-out to execute an attacker-supplied script staged in the app's own external files directory. This yields code execution as UID 0, but confined to the restricted `dumpstate` SELinux domain.

The second bug is in `olc2` (`vendor.oplus.hardware.olc2.IOplusLogCore/default`, backed by the binary `/odm/bin/hw/vendor.oplus.hardware.olc2-V3-service`), a vendor hardware-abstraction-layer (HAL) service meant to support hardware logging/diagnostics. Its `doShell(String cmd)` method (Binder transaction code 6) contains only a single check — `if (getCallingUid() == 0)` — before it forks and calls `execl("/vendor/bin/sh", "sh", "-c", cmd, NULL)`. Because the caller is already root (courtesy of the first bug), this check is trivially satisfied — a textbook confused-deputy failure where a privileged service trusts a caller's claimed UID instead of cryptographically verifying it. The researcher additionally located a permissive SELinux policy rule (`allow hal_oplus_olc_aidl_client hal_oplus_olc_aidl_server:binder { call transfer };`) that permits the `dumpstate`-domain process reached in stage one to make the Binder call into `olc2` at all — identified via `sesearch -A -s dumpstate -c binder sepolicy_clean.bin` against the device's compiled policy. Crucially, the shell spawned by `olc2` inherits the `vendor_qti_init_shell` SELinux domain, which carries an almost unrestricted capability bitmask (`CapBnd = 0x1ffffffffff`) including `CAP_SYS_MODULE` (kernel module loading) and `CAP_SYS_RAWIO` — a much less restricted context than `dumpstate`. Chaining the two bugs takes a zero-permission app from nothing to unrestricted root with kernel-level capability in two Binder calls.

Moorats reverse-engineered both services with Ghidra and documented that Java can call the vendor AIDL/HIDL HAL directly via `ServiceManager.getService()`, `Parcel.writeInterfaceToken()`, and `IBinder.transact()` — a pattern that "unexpectedly" worked without special HIDL bindings — and had to hand-implement the legacy `String8` wire format (int32 length + UTF-8 bytes + null terminator) for the `setEvent` call since the modern Android 35 Parcel API does not expose it. To execute arbitrary Java logic once root was reached, the researcher staged `classes.dex` from the PoC app's own APK to external (`media_rw_data_file`) storage at `/sdcard/Android/data/com.research.poc/files/classes.dex` — because `dumpstate` cannot read installed-APK data files directly — then launched it by setting `CLASSPATH` and invoking `app_process /system/bin com.research.poc.Pwn` from the `boot.sh` payload run inside the `olc2`-spawned root shell.

The vulnerability was confirmed on a OnePlus 15 (CPH2747) running OxygenOS 16.0.3.503 (February 2026 security patch level, kernel 6.12.23), and separately reproduced on an older OnePlus 12 Pro (CPH2581) used during reverse engineering, leading the researcher to expect the flaw is present across OxygenOS 16 generally. OnePlus's own Security Response Center told Moorats by email that the issue affects "all series of OPPO terminal products with universal security risks" — an admission of fleet-wide impact without naming specific additional models.

Disclosure did not go smoothly. Moorats reported both bugs on 2026-04-18 and followed up on 2026-04-29 after no reply; OnePlus requested further technical detail on 2026-05-14 (answered same day) and confirmed the bugs on 2026-05-20, simultaneously asserting "the exclusive final right of vulnerability disclosure" and warning that publication — even after a fix ships — could expose the researcher to "legal liabilities" under European cybersecurity regulation. On 2026-06-01 the researcher set a standard 90-day coordinated-disclosure deadline; OnePlus instead requested a delay to 2026-09-17 on 2026-06-22, which the researcher accepted. A 2026-07-20 status request went unanswered; the two sides exchanged messages regarding CVE-ID coordination around 2026-07-28, and OnePlus sent a further response on 2026-08-03, but no CVE identifier was ever publicly assigned. A final 2026-09-11 status request also went unanswered. Moorats published on 2026-09-24, roughly 159 days after the initial report and past the previously agreed embargo date. Reporting on the patch status is inconsistent across outlets: several outlets (Cyber Security News, The Hacker News, as of their 2026-09-24/25 publication) state no public patch or OTA is available, while the researcher's own writeup references OxygenOS build `16.0.10.500(EX01)` as containing a fix — it is unclear from public reporting whether that build has been broadly rolled out to the affected device fleet, particularly the OPPO-branded devices OnePlus itself says are impacted. No CVE has been assigned to this flaw as of 2026-09-27.

The disclosure lands amid a broader pattern of OEM-added-code privilege escalation on Android flagships: on 2026-08-31, independent researcher Lukas Maar (Calif) published "OEMpocalypse," a distinct zero-permission-to-root technique exploiting a page use-after-free in OEM-specific kernel drivers, demonstrated against locked-bootloader Samsung Galaxy S26/S26 Ultra, Xiaomi 17, OPPO Find X9 Ultra, and OnePlus Ace 6 Ultra devices. OEMpocalypse is a separate bug class (kernel memory corruption vs. this chain's userspace confused-deputy/command-injection pair) but underscores the same underlying theme reporters connected it to: manufacturer-added system code on Android flagships, not upstream AOSP or chipset-vendor drivers, is an increasingly common root of unprivileged privilege-escalation chains.

No real-world exploitation of the AtlasService/olc2 chain has been reported. Exploitation requires local app installation (e.g., sideloading or an app obtained outside vetted stores) but no Android runtime permissions and no user interaction beyond installing the app; impact at the end of the chain is full root with unrestricted Linux capabilities, meaning arbitrary access to other apps' data, the ability to install persistent code, tamper with or disable on-device security tooling, and load kernel modules.