The Patch Window Just Got Shorter

An engineer at SecurityWeek recently set out to answer a narrow, practical question: how hard is it, in 2024's tooling, to take a disclosed vulnerability in a programmable logic controller and turn it into a working exploit against a different target. The answer was hours, and a few hundred dollars in compute and API calls. No team of specialists, no months of reverse engineering, no bespoke fuzzing infrastructure. Just an AI tool doing in an afternoon what used to require a rare and expensive skill set.

That single experiment is worth more than any amount of commentary about how attackers are getting more sophisticated, because it shows the opposite is happening. The skill required to exploit a known flaw is falling toward zero. What is not falling, anywhere near as fast, is the time organisations take to apply the patch that would have closed the flaw in the first place. That mismatch, not attacker genius, is the story this week's reporting keeps returning to.

The hours-and-hundreds-of-dollars problem

Exploit development used to be a bottleneck that worked in defenders' favour. A disclosed vulnerability might sit for weeks before anyone outside a nation-state programme could reliably weaponise it, and that lag was, in effect, free defensive time. The PLC porting experiment suggests that lag is gone for a meaningful class of vulnerabilities. If an AI-assisted researcher can port an exploit across targets in an afternoon for the cost of a nice dinner, then the assumption that "nobody will bother reverse engineering this obscure flaw" no longer holds. The economics have flipped: it is now cheaper to attempt exploitation than to guarantee you have patched against it in time.

Twenty-two thousand servers is the real number

Set that against BleepingComputer's finding that nearly 22,000 Microsoft Exchange servers are vulnerable to hijack attacks right now. These are not zero-days. They are known, patchable issues sitting exposed on the internet in numbers that dwarf any single attacker's exploit-development effort. You do not need an AI tool that can write a novel exploit in hours if there are 22,000 servers running software with a fix already published that the operator has simply not applied. The exploit-development story and the patch-latency story are not competing explanations for the current threat environment; they are two halves of the same failure, and the second half is the one organisations actually control.

Attackers want repeatable, not remarkable

The Hacker News made a version of this argument directly this week, under a headline worth taking at face value: threat actors don't want better attacks, they want repeatable ones. That is a rational response to an environment where tens of thousands of instances of the same unpatched software sit exposed at once. Why invest in a bespoke, high-cost attack chain against a hardened target when a repeatable playbook against known, common misconfigurations will work against thousands of targets with near-identical infrastructure? Sophistication is expensive and fragile. Repeatability, aimed at the population of systems that never got patched, scales.

The live exhibits

Two items from SecurityWeek this week are not hypothetical. A critical Langflow vulnerability is already being exploited in the wild. A critical JFrog Artifactory vulnerability is reportedly being exploited in the wild too. Both are the pattern in miniature: a flaw gets disclosed, a fix exists, and before organisations have finished rolling it out, someone is already using it. These are not edge cases. They are what "the patch window just got shorter" looks like when you go looking for it in real time rather than in a forecast.

It is worth noting, for balance, that not every current threat needs AI at all. Five Venezuelans pleading guilty in a US court to ATM jackpotting is a reminder that plenty of profitable crime still runs on old-fashioned physical technique rather than novel code. Defenders are not facing a single, uniform adversary that has been transformed overnight. They are facing the same range of old and new methods they always faced, except the new end of that range now moves at a pace the old end never did.

State-linked patience, commodity speed

The Record and The Hacker News both reported this week on Iranian activity that has nothing to do with exploit-porting speed and everything to do with patience: hackers posing as recruiters to deliver cross-platform remote-access trojans through fake coding tests, and separate campaigns targeting aviation and fintech developers with new malware. These are social-engineering operations built on trust and time, not on how fast a flaw can be weaponised. The uncomfortable point is that organisations now face both ends of the threat spectrum simultaneously: slow, patient espionage campaigns that exploit human trust, and fast, commodity exploitation that exploits unpatched software, often against the same organisation, often at the same time.

Institutions are starting to say the quiet part

A financial watchdog has now stated plainly that cyber risk from frontier AI is the most immediate concern to the global financial system, according to The Record. That is a striking sentence for a regulator to put in writing, and it lines up with what the PLC experiment demonstrates at ground level: the tools that compress exploit development also compress the time a financial institution has to notice, patch, and verify before something built on that institution's infrastructure is used against it. CyberScoop's reporting on the Collective Cyber Defense letter shaping vendor questionnaires shows procurement teams starting to catch up, asking harder questions of vendors before contracts are signed. That is a sensible response, but questionnaires move on a quarterly cycle. Exploits, per this week's evidence, move in an afternoon.

The consequences of getting the timing wrong are not abstract. SecurityWeek reported a ransomware gang's claim of a data breach at Nutex Health this week, one more entry in a list of organisations that found out, after the fact, which side of the patch window they were standing on.

The democracy angle nobody patches

Two other stories this week point at a version of the same problem outside the usual enterprise-security frame. CyberScoop reported a whistleblower's account that the US Postal Service is deploying new, "untested" IT systems governing mail-in ballots. Bruce Schneier's Rewiring Democracy series has been asking, in parallel, what it means for democratic infrastructure to be run on systems built and deployed faster than they can be properly scrutinised. Neither of these is a story about exploit code. Both are stories about the same underlying failure mode as the Exchange and Langflow cases: deployment speed outrunning verification speed. An untested system governing ballots and an unpatched server governing email are different in almost every respect except the one that matters here, which is that both represent infrastructure put into service before anyone had confirmed it was safe to trust.

What the number actually says

None of this requires believing attackers have become smarter. The PLC experiment shows the opposite: the skill floor for producing a working exploit has dropped to a level where cost, not capability, is the limiting factor, and the cost is now hundreds of dollars and a few hours. Against that, 22,000 exposed Exchange servers is not a statistic about attacker capability at all. It is a statistic about how long it takes an organisation to apply a fix once one exists, and that number has not moved anywhere near as fast as the number on the attacker's side of the ledger. The argument this week's reporting adds up to is not that defence is impossible. It is that defence has stopped being primarily a detection problem and become, again, a scheduling one: the organisations getting hit are, disproportionately, the ones whose patch cycle assumed it still had the weeks that AI has just taken away.