A Patch Going Public Is an Attack Map Going Public

A patch going public is an attack map going public. For a large and growing class of bugs, the map is now enough.

We were running supply chain tests this week. Our AI Pentest agent pulled a security fix from an open-source dependency, read the diff, worked out what the fix corrected, built a working payload for that bug class, and ran it. Web search and basic reasoning. Nothing exotic.

That last part is the point. Nothing exotic.

Patch-diffing isn’t new. The labor was the bottleneck.

Attackers have been reverse-engineering fixes into N-days for decades - source diffs, binary diffs, the reliable rhythm of Patch Tuesday sliding into “Exploit Wednesday.” The diff was never the hard part. A fix tells you exactly what was wrong: it points at the vulnerable code, shows the guard that was missing, and frames the bug class for you. It is, quite literally, a map to the weakness.

What stood between that map and a working exploit was skilled human labor and time. You needed someone who could read the fix, understand the underlying flaw, and hand-build a payload that triggered it - an exploit-dev specialist and, often, a few days.

That’s what changed. The labor collapsed.

An agent and an afternoon

What used to need an exploit-dev specialist and a few days now needs an agent and an afternoon. On the bug classes where this works, it works end to end: logic bugs, auth bypasses, injection. The agent reads the diff, reasons about the corrected behavior, and constructs the trigger without being walked through any of it.

Be precise about the boundary, because it matters. Memory corruption against modern mitigations - ASLR, stack canaries, CFI - is still real work, and I’m not claiming an agent one-shots a browser exploit. But the easy-to-medium tier is most of what’s sitting in your dependency tree. The long tail of your software supply chain is not exotic memory-safety research. It’s logic and validation bugs in libraries you pulled in three years ago, and that tier is exactly where the labor just went to zero.

This isn’t a thought experiment. Anthropic’s red team published hard data measuring LLMs’ impact on N-day exploit development - the collapse in time-to-exploit is now something you can put on a chart.

The silent fix is the nastiest version

The version of this that should worry you most isn’t the CVE everyone is already tracking. It’s the silent fix - a security patch that lands in a commit with no advisory, no CVE, no fanfare. Maintainer fixes a bug, ships it, moves on. Your team never learns it was security-relevant, so it never gets prioritized. The commit just sits in the history looking like routine maintenance.

A human attacker might never notice it either. An agent scanning commit history doesn’t need to be told. It reads every commit, reasons about which ones changed security-relevant behavior, and flags the fix that your own team didn’t know to flag. The information asymmetry inverts: the automated attacker can end up understanding your dependencies’ security history better than you do.

The window didn’t move. The attacker’s time to cross it collapsed - so it now fits inside the gap where it used to sit outside.

The window didn’t move. Who’s racing across it did.

The exposure window has always existed: fix published, fix deployed, and a gap of days or weeks in between. That gap is a property of how software ships - you cannot deploy everything the instant it’s released. Nothing about that is new.

What’s new is who’s racing you across it, and how fast they move. When weaponization took a specialist a few days, the attacker’s timeline often ran longer than your deploy timeline, and you won the race by default more often than you’d like to admit. When weaponization takes an agent an afternoon, the attacker fits comfortably inside the same window - and now you’re losing that race by default instead.

Two honest caveats, because they matter

Reachability. A vulnerability in a dependency isn’t an exploit against you. Reachability still decides whether that code path is actually live in your application. Half your dependency tree may be dead weight the payload can never touch. This is real, and it’s the single biggest reason not to panic - but it’s a reason to prioritize by reachability, not a reason the window is safe.

N-day weaponization vs. package poisoning. This is N-day weaponization - turning a real, already-fixed vulnerability into a working exploit. It’s distinct from a poisoned-package supply chain hit, where an attacker plants malicious code in a dependency directly. Both ride in through your dependencies, and it’s easy to blur them, but the defenses are different and the threat models are different. Keep them separate.

What this actually changes

The direction is clear even where the details are still moving: offensive AI is weaponizing these windows faster than defensive AI has language for them. Sitting at the intersection of both - building agents that attack and agents that defend - gives you a front-row seat to the collision, and the uncomfortable view is that the offensive side is currently ahead on this specific problem.

So supply chain risk was never really “do you patch.” It was always whether your pipeline can outrun something that reads the fix faster than you can ship it. For years that was a comfortable question, because nothing on the other side could read the fix at machine speed. Now something can. The question is the same. The answer got a lot harder.