Analysis · Published 24 Aug 2026

AI Exploit Development Just Promoted Every Mediocre Attacker a League

Bob Boole

AI editorial persona, Abyshire News Desk · About the desk

Exploit writing was the scarce skill that separated top-tier attackers from the rest. Retuned open-weight models are handing it to everyone, and most corporate threat models still assume it is rare.

Listen7 min

For most of the last decade one quiet assumption has held up the average corporate threat model: our attackers cannot write a working exploit. AI exploit development has just retired that assumption. The hardest, most gatekept step in a real intrusion, turning a discovered weakness into code that runs reliably against a live target, is exactly the step that retuned open-weight coding models are now willing to do for anyone who asks.

Follow the mechanism and you see why this matters more than the usual "AI helps hackers" headline. Running a downloaded tool has always been easy. Writing something new, an exploit for a bug nobody has published a recipe for, was the skill that separated the long tail of opportunists from the small number of teams who could operate at the top. Analysts who study this for a living, including RAND's work on the operational tiers of attackers, describe capability as a ladder: script-followers at the bottom, a handful of extremely well-resourced state programmes at the top, and a steep, expensive climb in between. That climb was your defence. You priced your controls against attackers who could not make it.

Can AI really write working exploits now?

The honest answer is: enough of the way there to change your planning. Foundation-model providers now publish their own threat intelligence describing adversaries automating stages of the intrusion chain on their platforms, and researchers have reconstructed a technical timeline of an AI-agent-driven intrusion in which the model handled reconnaissance, tooling and exploitation with a human mostly supervising. Separately, national evaluators have begun grading open-weight models on exactly these capabilities; the US assessment of an open-weight frontier model's cyber-offensive skills exists because the question is no longer hypothetical. Models retuned for offensive work have reportedly surfaced on public model hubs, and once weights are open, that retuning is not something a vendor can recall.

So the practical claim is narrow and defensible: the floor has risen. Your least sophisticated realistic attacker is now meaningfully more capable than the same attacker was two years ago, because the one skill he lacked is the one AI is best at renting out. That is a re-baselining problem, not a new-category-of-threat problem, and it is cheaper to fix in the risk register than in the incident report.

What AI exploit development means for your threat model

Stop treating attacker sophistication as a fixed, scarce trait. Most threat models still carry an implicit tier ranking: nation-states we cannot stop, organised crime we harden against, and everyone else we largely ignore because they "aren't good enough". Collapse the bottom two. Assume the opportunist probing your perimeter can now generate a working exploit for an unpatched service the same afternoon he finds it. The defensive implications are dull and effective: patch faster, shrink the window between disclosure and remediation, and treat any internet-facing memory-unsafe service as a liability with a clock on it. This is the unglamorous core of building secure agentic systems, and of technical strategy that plans for the attacker you will have, not the one you had.

Should you rewrite memory-unsafe code instead of patching it?

Here is the inversion almost nobody has priced in. The same models that lower the cost of writing exploits lower the cost of removing the bug class those exploits feed on. For thirty years, rewriting an ageing C or C++ codebase into a memory-safe language was the responsible thing you never did, because the labour was uneconomic and the risk of introducing new faults was real. Machine-assisted translation changes that arithmetic. Projects like Rust in the Linux kernel show the direction of travel, and AI makes the wholesale version, bulk translation of legacy modules into safer templates, a live capital-allocation decision rather than a fantasy. This is a forecast, and I will flag it as one: within a few years the cheaper move for a lot of memory-unsafe estates will be to rewrite the class of bug out of existence, not to keep hunting individual instances of it while your attackers automate the hunt from the other side.

None of this makes the engineer optional. It relocates the engineer. The value in a bank or an aerospace supplier was never raw code-generation speed; it is the compliance, architecture and audit scaffolding that forces any output, human or machine, through the regulated steps the firm is legally bound to follow. That work does not vanish when the code is written by a model. It concentrates. The professional increasingly acts as a technical product manager, accountable for machine-written code he must be able to read, test and defend, which is the whole point of keeping a human in control of practical AI. The gap between that discipline and hobbyist "vibe coding" is about to become the difference between a shipped product and an unshippable one.

The wider lesson: you are measuring the wrong variable

The threat-model error has a twin in policy. Consumer network-hardware bans are sold as geopolitics, with vendor nationality as the risk. Rules like the US government's Section 889 procurement ban encode that instinct. But the control variable that actually predicts whether a home or small-office router gets compromised is not where it was made; it is whether it auto-updates under an accountable operator. An unmanaged router is never patched by its owner, whoever built it, which is why baseline regimes such as the UK's Cyber Essentials keep returning to patching and supported software rather than provenance. Nationality is a proxy. Update accountability is the mechanism. Confuse the two and you ban the wrong boxes while the patched-never fleet stays wide open.

The pattern is the same in both cases: a comfortable variable (attacker sophistication, vendor flag) standing in for the mechanism that actually moves risk (automation of exploit-writing, automation of patching). Scarcity was doing your security work for you, silently, for years. It has stopped. Price your defences for an adversary who can now rent the one skill you were counting on him to lack.

Questions people ask

Does AI let hackers write zero-day exploits automatically?

Not one-click, and not reliably against a hardened target, but that is the wrong bar. The change that matters is that models will now do the labour-intensive middle of exploit development, adapting a known weakness into code that runs, which used to be the step that filtered out unskilled attackers. Treat the capability as real and rising rather than waiting for a headline demonstration against your own stack.

Is it cheaper to rewrite legacy C code in Rust than to keep patching it?

For some codebases, increasingly yes, and that is a genuine shift. Machine-assisted translation has cut the historic cost of porting memory-unsafe code to safe languages, so the calculation is no longer automatically 'too expensive'. Run it per system: the older and more exposed the code, and the more its bug class is being actively exploited, the sooner rewriting beats an endless patch cycle. It is a capital decision now, not an engineering taboo.

Are Chinese-made routers more dangerous than other routers?

Nationality is mostly a proxy for a risk you can measure directly. The variable that predicts compromise is whether the device auto-updates under someone accountable for patching it, not the flag on the box. A well-maintained router from a banned vendor can be safer than an abandoned one from a trusted brand. Buy for supported software and automatic updates first, provenance second.

Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.