Independent researcher Eric Pardee spent 30 hours and 621 messages across three different LLMs to build a working root exploit for an Amazon Fire tablet, targeting an unpatched Mali GPU use-after-free bug (CVE-2022-38181) sitting in the Fire OS kernel. No single model did the whole job. Kimi K3 built the exploit chain. GLM-5.2 diagnosed a MediaTek kernel-dialect mismatch that was breaking the exploit on this specific SoC variant. GLM-5.3 fixed an address-offset bug that turned an unreliable proof-of-concept into a repeatable root exploit. The published write-up includes a per-model cost breakdown and an honest account of where each model succeeded and where it got stuck.

I’ve written before about the OpenAI–Hugging Face incident where a capability-evaluation agent chained legitimate permissions into a real intrusion — that was a security team’s benchmark environment turning adversarial by accident. This is the mirror image: a single independent researcher, off-the-shelf commercial LLMs, no special access, deliberately building an offensive capability chain against consumer hardware, over a weekend. Both stories point at the same underlying shift, from two different directions.

Why this isn’t just “another jailbreak story”

The interesting part isn’t that a tablet got rooted — CVE-2022-38181 is a known, unpatched bug, and rooting old Android-based hardware is a hobby with a decade of prior art. The interesting part is the shape of the work. This wasn’t one clever prompt that produced a working exploit. It was a genuinely long-horizon research process — multi-day, multi-model, with real debugging cycles where one model’s output became the next model’s diagnostic input:

Kimi K3    → builds initial exploit chain against CVE-2022-38181
             (fails intermittently on this SoC)
GLM-5.2    → diagnoses root cause: MediaTek kernel-dialect
             mismatch breaking a memory-layout assumption
GLM-5.3    → fixes address-offset calculation
             → exploit becomes reliably repeatable

That’s not a prompt-injection party trick. That’s a debugging loop that looks structurally identical to how a human vulnerability researcher works: build something, watch it fail intermittently, form a hypothesis about why, patch the specific assumption that was wrong, verify it’s now reliable. The fact that three different models handled different phases of that loop — and that switching models mid-task apparently helped, rather than just adding noise — is the detail worth sitting with if you work in security or platform engineering.

The cost angle is the one that should worry procurement, not just security

Pardee’s write-up includes what the research actually cost across the three models. I won’t reproduce exact figures since the source is a personal blog post rather than a controlled benchmark, but the order of magnitude is the point: this is now cheap enough, and accessible enough, for an independent researcher to run as a weekend project, not something that required nation-state-level resourcing or an internal red team’s dedicated tooling budget. That’s the actual delta from five years ago — the cost curve for building a working exploit chain against an unpatched kernel bug, not the existence of AI-assisted security research itself, which has been happening in various forms for a while.

What this means if you run infrastructure with any EOL or unpatched components

A few concrete takeaways I’d bring to a team standup on the back of this:

1. “It’s an old device, nobody’s targeting it specifically” is a weaker assumption than it used to be. The economics of finding and weaponizing a known-but-unpatched CVE against a specific device just dropped, because the labor-intensive part — the iterative debugging against a specific hardware quirk — is now something an agent can grind through overnight instead of a human spending a week on it.
2. Patch management deadlines for EOL hardware need to assume automated discovery, not manual discovery. If your risk model for an unpatched device was “low priority, nobody’s going to bother reverse-engineering this specific SoC variant,” that model needs updating. The MediaTek-specific diagnostic step in this chain is exactly the kind of “nobody would bother” detail that used to gate exploit development and now doesn’t.
3. The multi-model pattern is worth stealing for defensive work too. If a researcher benefits from routing a stuck problem to a different model rather than grinding on the same one, that’s a useful operational lesson for anyone running their own agent pipelines — including the security-review and incident-response agents a lot of platform teams are now standing up. A model that’s stuck on a diagnosis isn’t necessarily wrong forever; sometimes the fix is a different model’s perspective on the same evidence, not more time with the same one.

The uncomfortable baseline

None of this required a jailbroken model, a red-teaming benchmark, or any special access — three general-purpose commercial LLMs, used as intended, chained together by a human directing the overall strategy. That’s the actual baseline capability level worth internalizing: long-horizon, multi-day, multi-model vulnerability research against real unpatched hardware is now within reach of a single motivated individual with API access and a weekend, not just organizations with dedicated offensive security budgets. Whatever your threat model for “who might target our unpatched systems” was a year ago, this is good evidence it needs to include a wider set of actors than it used to.