News Date: 2026-09-24
Two vulnerabilities in software shipped with OnePlus phones can be chained to give an ordinary installed application root-level control without requesting sensitive Android permissions. The research was demonstrated on a current OnePlus 15 running the latest available OxygenOS and was also reproduced on an older OnePlus model.
Vendor Services Create the Privilege Path
The first weakness affects AtlasService, a privileged OnePlus component used to gather debugging information. According to the researcher, the service accepts requests from applications without adequately verifying the caller. Crafted input can reach a debugging utility and become part of a system command.
This initial step provides root privileges inside a restricted security domain. Although powerful, that environment does not provide unrestricted control over the entire device. The second vulnerability removes that limitation.
A hardware-related service called olc2 contains functionality that can execute shell instructions when called by a root process. By combining the root access obtained through AtlasService with the olc2 command interface, the malicious application can move into a security context with broad low-level Linux capabilities, including the ability to load kernel code.
No Special Permissions or User Prompt
The attack is local rather than remotely triggered, meaning a malicious application must first be installed and launched. However, the application does not need to request dangerous permissions or display the usual Android authorization prompts. That characteristic could make an apparently simple application far more dangerous than its permission list suggests.
OnePlus reportedly confirmed the flaws in May 2026 and said they also affect other OnePlus and OPPO products, although it did not identify every vulnerable model. At the time of public disclosure, no CVE identifiers, detailed vendor advisory or security update addressing the chain were available. There was also no public evidence that attackers had exploited the weaknesses.
Risk Reduction Until Patches Arrive
- Install applications only from trusted publishers and managed stores.
- Remove sideloaded or unnecessary applications from affected devices.
- Use mobile threat defense tools to monitor unexpected command execution.
- Separate privileged corporate access from unmanaged mobile devices.
- Apply vendor firmware updates as soon as a confirmed correction becomes available.
In my view, this case highlights a weakness in Android security assessments that focus too heavily on application permissions. Vendor-added system services operate outside the standard application model and can quietly introduce powerful attack paths. Enterprises should evaluate device manufacturers, update responsiveness and disclosure practices as part of mobile procurement, not merely compare hardware specifications.