OnePlus confirmed the root chain, warned of legal liability, and shipped nothing in 159 days

A hundred and fifty nine days, and the phone is still rootable

On 18 April 2026 the researcher Rasmus Moorats reported two flaws in OnePlus's own software to OnePlus. Chained, they let an ordinary app, installed by the owner and requesting no permissions at all, take root on a stock OnePlus 15 running current OxygenOS.

OnePlus confirmed the flaws on 20 May, thirty two days later, and told him it holds the exclusive right to decide when a vulnerability is made public, warning that publishing without permission could lead to legal liability. On 22 June it asked him to delay; he agreed not to publish before 17 September. He asked for a progress update on 20 July and again on 11 September, and received no reply to either.

He published on 24 September, a hundred and fifty nine days after the report and seven days after the date he had agreed to wait for. There is no CVE. There is no patch. OnePlus has said the same flaws affect many more of its devices and OPPO's, without saying which.

What this does not establish. It does not establish that anyone has been attacked: no exploitation is reported and the researcher reports none. It does not establish remote risk, because the attack needs an app already installed and running on the device; nothing here is reachable from the internet. It does not establish which models are affected, because OnePlus has not published a list and the researcher tested two devices. And it does not establish that OnePlus is doing nothing, only that it has published nothing.

What it does establish is that a permissionless app can take complete control of a current flagship, that the vendor has known for five months, and that the vendor's most specific communication in that time was about the researcher's right to publish.

Two services, and why the second one is needed

This briefing describes the mechanism at the level a defender needs and deliberately omits the method names, transaction identifiers and the proof of concept sequence, all of which are in the researcher's own write up for anyone doing vendor side work.

The first flaw is in a OnePlus diagnostic service that runs as root and accepts calls from any process on the device without checking who is calling. One of the calls it accepts takes attacker supplied text, stores it in a system property, and starts a OnePlus debugging binary that puts that property into a shell command without sanitising it. Any app that can make the call gets command execution as root.

That would normally be the end of the story, but Android's SELinux policy means root is not one thing. The process that runs lands in the dumpstate domain, which is deliberately constrained: it cannot load kernel modules and it cannot do raw input and output. Plenty of damage, but not the whole device.

The second flaw removes that constraint. A OnePlus vendor component exposes a method that runs an arbitrary shell command, and its only guard is a check that the caller is already uid 0, which the first flaw has just provided. The process it starts inherits a vendor shell domain that holds essentially the full capability set, including module loading, raw input and output, and process tracing.

So the chain is not two ways in. It is one way in and one way out of the box that was supposed to contain it.

The control that worked, and the one that undid it

It is worth being precise about what succeeded here, because it is the part most reporting skips.

SELinux did its job. The first flaw produced root, and root was not enough, because the policy said processes in that domain may not do the things that matter most. That containment is exactly why Android's security model treats domains as the real boundary rather than the user identifier.

The second component then handed out a shell in a far more capable domain, gated on a check that only asks what the caller's user identifier is. Once the first flaw made that identifier zero, the guard was satisfied. A policy boundary was defeated by a component that checks identity rather than authority, which is the same mistake in a different costume: the caller was authenticated, and nobody asked whether it was authorised.

That pattern travels. Any privileged helper whose access control is a uid comparison is one privilege escalation away from being a general purpose tool for whoever wins that race.

The correspondence

Dates from the researcher's write up, with days from the report computed for this briefing

Date	What happened	Days
18 April 2026	Both flaws reported to OnePlus	zero
29 April 2026	Researcher follows up	11
14 May 2026	OnePlus asks for details, receives them the same day	26
20 May 2026	OnePlus confirms the flaws across multiple products, and raises legal liability over publication	32
1 June 2026	Researcher states he will publish within 90 days	44
22 June 2026	OnePlus asks for a delay. He agrees not to publish before 17 September	65
20 July 2026	Update requested. No reply	93
11 September 2026	Update requested again. No reply	146
24 September 2026	Published. No CVE, no patch	159

Two things about that table deserve saying plainly, and they point in opposite directions.

The researcher behaved well. He reported privately, gave the vendor more than three months, accepted a delay when asked, held past his own stated ninety days, asked twice more before acting, and published seven days after the date he had agreed to, with the correspondence attached. He also says what he has not published, flagging a further area of the same service as unexamined rather than quietly holding it.

OnePlus confirmed quickly and then went quiet. Its clearest documented position in five months is about who controls publication. A vendor is entitled to ask for time, and coordinated disclosure works precisely because researchers grant it. What it cannot do is ask for silence and then stop answering, because the only leverage the other side has is the date.

What to do about it

There is no patch to apply, which makes this an exposure management question rather than a patching one.

The question this leaves

Coordinated disclosure is a bargain. The researcher gives up the certainty of publishing immediately, and the vendor gives up the option of ignoring it. Both sides normally keep to it, which is why the system works at all and why most serious flaws reach users as patches rather than as surprises.

What happened here is the bargain breaking in the quietest way available. Nobody refused anything. OnePlus asked for time and got it, then did not answer two requests for an update, and the deadline arrived with nothing shipped. From the outside it is indistinguishable from a fix that is nearly ready and a fix that was never started, and the vendor is the only party who can tell the difference and the only party not saying.

So the question is for anyone whose organisation receives vulnerability reports: when your team asks a researcher for more time, who owns the obligation to keep answering them, and what happens in your process on the day you go quiet?