IonStack Turns One Link Into Full Root on Your Android Phone

IonStack You tap one link, and root is already running on your Android 17 phone. You never download a file or approve a permission box because the page does the work itself while it loads.

The same flaw sits in the Linux kernel behind servers, cloud platforms, and containers, so the phone is only where it starts. Researchers built the attack, put it online, and now anyone can watch it root a device on their own screen.

The attack is called IonStack, and a security startup named Nebula Security showed it off in late June.

The trick is that they take two separate bugs and run them one after the other, and each bug has its own small job. The first one sits in the Firefox browser, and all it does is get the attacker a tiny way in. The second one sits far deeper, inside the Linux kernel, which is the core that Android itself is built on top of, and its job is to take that tiny opening and blow it wide into root. Root is the account that is allowed to do anything at all on the phone, with nothing held back.

On its own, neither bug gets an attacker very far. Run them together in the right order and they carry you from an ordinary web page you clicked all the way down to that root account.

Start with the browser. Firefox has a piece inside it whose only job is to make JavaScript run fast. It takes the JavaScript on a page and turns it into raw machine code on the spot, so pages feel quick instead of slow. That piece has a name, IonMonkey, the browser’s JIT compiler.

The researchers found a place where IonMonkey turns that code into machine instructions the wrong way. That is the first bug, CVE-2026-10702. The wrong result let them reach into memory they were never meant to touch, and once you can do that, you can run your own code right inside Firefox.

Code running inside the browser is not supposed to reach the phone itself. A boundary called the sandbox keeps a web page separated from everything else on the device. They got past it.

This first step almost never failed for them, close to 100 out of 100 tries. Mozilla has already fixed it in Firefox 151.0.3, out since the second of June.

Getting past the sandbox drops the attacker onto the phone, but only as a plain, low level user with hardly any rights. That is where the second bug takes over.

The second bug is the interesting one, the one to slow down on. Its name is GhostLock, CVE-2026-43499.

Picture two programs that both want the same piece of data at the same instant. They cannot both have it, so the kernel makes one of them wait its turn. That waiting arrangement is a lock. GhostLock hides inside a special kind of lock built for urgent jobs, the sort that programs set up and tear down constantly. Its full name is a priority inheritance futex.

Inside that code sits a small cleanup step called remove_waiter. Whoever wrote it took one thing for granted, that the thread doing the cleanup is always the same thread that was waiting on the lock. Almost always, that holds. But there is one path, where a waiting thread gets handed from one lock to another, where it does not hold at all.

On that path the kernel cleans up the wrong thread. It leaves behind a pointer aimed at a scrap of kernel stack memory that has already been freed and handed out again for something else. The pointer still trusts that old spot, even though what lives there now is different.

That misplaced trust is the bug itself. It has a name that comes up a lot in kernel work, a use-after-free.

And that is where the attack got its name. Ion from IonMonkey in the browser, stack from this use-after-free sitting on the kernel stack.

From that one slip, they built a full takeover, step by step.

First they grab back the memory the kernel threw away, and drop a fake version of that lock structure into the same spot. That fake gives them one precise write into the kernel’s own memory. They aim that write at a table the kernel keeps of network handlers, the code it jumps to when certain traffic comes in. Then they send a single loopback UDP packet, the kind a machine sends to its own address, which makes the kernel jump into the handler they just rewrote. Now they steer the kernel. A last change to a setting called core_pattern gets their own code running as root.

Start to finish, it took about five seconds. It worked 97 times out of 100 in their own tests.

The fix that stops all of this is tiny. One change tells that cleanup step to work on the thread that was really waiting, instead of the one that happened to be running the cleanup:

1
2

commit 3bfdc63936dd
rtmutex: Use waiter::task instead of current in remove_waiter()

This kernel half is the reason the damage spreads so far. The bug slipped into Linux back in 2011 and then sat there, untouched, for more than 15 years. It covers kernel versions 2.6.39 all the way through 7.1, which is fifteen years of ordinary Linux builds that people have been running all along.

It asks for almost nothing to work. One setting has to be turned on, CONFIG_FUTEX_PI, and that setting is already on by default in the distributions they checked. The attacker needs no special rights and no network access. A plain user who can run a program on the machine is enough.

On a shared server that small detail turns into a big problem. The same bug lets someone break out of the container they were stuck inside and land on the host underneath, and once they are there, the other customers sharing that same machine are within reach.

Here is the part that should make you sit up. No human went hunting for these two bugs by reading the code line by line. A tool did it. The team calls it VEGA, a scanner that reads through source code on its own and points at the weak spots, and they aimed it at old kernel code few people had opened in years.

GhostLock is not the only one showing up this way. Take Copy Fail, CVE-2026-31431, a nine year old bug that also hands a normal user root. CISA put it on its Known Exploited Vulnerabilities list back in May, after signs that people had started using it. Same story underneath: old code that had sat unread for years, now getting picked apart by machines.

Google took GhostLock seriously enough to pay the team $92,337 through its kernelCTF bounty program.

One thing to be clear about before you go patch anything. The team did this the careful way. They told Firefox and the kernel people first, gave them time, and there is no sign anyone used IonStack against a phone before the details came out.

That said, the code is out in the open now, posted as open source, free for people to download. Their demo will even run the attack on your own phone, and if it succeeds your wallpaper changes as proof it worked. A phone it does not know how to root just restarts, no damage done. So from here on the danger is live, and the patch is the thing that stops it.

What to do

• → Update Firefox to 151.0.3 or later. You can see your version in the menu, or from a terminal:

1

firefox --version

• → On Android, install the June 2026 security patches or later. If your phone maker is slow with updates, look under Settings, then System, then Security update.

• → On any Linux machine, install your distribution’s current kernel, not just the first patched build that showed up. The first fix for GhostLock brought a separate crash bug tracked as CVE-2026-53166, and the clean version landed a bit later, so the newest kernel is the one you want. Do not assume you are covered because you patched once. The fix reached different distributions at different times, and in early July Ubuntu still had 24.04, 22.04 and 20.04 marked vulnerable or in progress, while Red Hat, Amazon Linux and SUSE were still shipping theirs. Check the kernel you run, and whether the vulnerable option is built into it:

1
2

uname -r
grep CONFIG_FUTEX_PI /boot/config-$(uname -r)

A line ending in =y means the priority inheritance feature is compiled into your kernel, which is the default across common distributions, so the kernel update is what removes the risk. Compare your version against your distribution’s advisory rather than assuming a patch is already in place.

• → You cannot switch this off at runtime, because the vulnerable option is set when the kernel is built, which leaves the kernel update as the fix. On servers you cannot reboot straight away, a live patching service is the stopgap until you can.

• → On shared hosts and container platforms, put this near the top of the list, since the container escape lets one compromised workload reach the rest of the host.

Attacks like IonStack come down to understanding how each layer of a system works and where it fails, then chaining those weak points into one path. That mindset, the one that keeps asking what happens if I change this, is what my ethical hacking course is built around. You start from zero and work hands-on through Linux, networking, reconnaissance, network and WiFi penetration testing, web application attacks like SQL injection and XSS, privilege escalation, and social engineering:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Nebula Security | Mozilla | NVD