A researcher took a known vulnerability in a programmable logic controller, the kind of device that runs a factory floor or a water treatment plant, and used AI tools to port a working exploit for it. The whole exercise took hours and cost a few hundred dollars. No team of specialists, no months of reverse engineering, just a patch note, a model, and an afternoon.
That result, reported by SecurityWeek as an experiment rather than a live attack, is the number that matters here. Everything else in this piece is about what happens once that afternoon-and-a-few-hundred-dollars figure is true for everyone, including people with no interest in being careful about it.
The quarterly patch cycle was built for a slower adversary
Most organizations still treat patching as a scheduling problem. A vulnerability gets disclosed, a ticket gets filed, the fix goes into the next release window, maybe next month, maybe next quarter if the system is sensitive enough that nobody wants to touch it outside a maintenance slot. That cadence was never fast, but it used to be fast enough, because turning a disclosure into a working exploit took real engineering time on the attacker's side too. The two clocks, patch-and-deploy on one side, reverse-engineer-and-weaponize on the other, ran at roughly comparable speeds. Defenders could lose that race and still not lose badly.
The PLC experiment removes that assumption. If porting an exploit for industrial control hardware is now an afternoon's work with an AI assistant, then the gap between "a fix exists" and "an attack exists" is no longer measured in the weeks it takes a human team to reverse-engineer a patch. It is measured in however long it takes someone to decide it is worth doing. The defender's clock has not sped up. The attacker's clock just did.
The pattern is already visible, not hypothetical
This is not a warning about some future risk. It is already showing up in the disclosure logs. Hackers started exploiting a critical vulnerability in Langflow, an AI workflow tool, not long after it became public. A critical vulnerability in JFrog Artifactory, the kind of software repository that sits underneath a huge amount of build infrastructure, was reportedly being exploited in the wild as well. And separately from any single named vulnerability, nearly 22,000 Microsoft Exchange servers were found sitting exposed to hijack attacks, simply because patching had not happened yet, on infrastructure that has been a known target for years.
None of these are exotic. They are the software that marketing teams, agencies and the vendors serving them actually run day to day: workflow tools, build pipelines, mail servers. The lag between "patch available" and "patch applied" used to be a manageable risk because the lag between "patch available" and "exploit available" was also long. Now one of those lags has collapsed and the other has not moved at all.
Repeatable beats clever
There is a useful reframe buried in the reporting on how threat actors actually operate: they do not want better attacks, they want repeatable ones. A novel exploit is expensive to find and use once. A fast, cheap, repeatable process for turning any disclosed vulnerability into a working exploit is worth more, because it scales across every unpatched target rather than just the one it was built for.
That is exactly what AI-assisted exploit porting produces: not a single brilliant attack, but a pipeline. A disclosure comes out, the pipeline runs, a working exploit comes out the other end, and the same pipeline runs again on the next disclosure. The skill required to be dangerous keeps dropping toward zero, which is the same shift visible elsewhere in current attacker behavior. Iranian-linked groups have been posing as recruiters to deliver cross-platform remote-access trojans through fake coding tests, a social-engineering trick that scales the same way a technical exploit pipeline does: build it once, run it against everyone who applies for a job. Separately, Iranian cyber-espionage activity has also been reported targeting aviation and fintech developers with new malware, another case of a repeatable approach aimed at a specific, valuable population rather than a one-off target.
The financial motive tells the same story from a different angle. Five Venezuelans pleaded guilty in a US court to ATM jackpotting, a fraud technique that, like a good exploit pipeline, is valuable precisely because it can be run again and again against different machines with minimal retooling. And a ransomware gang has claimed a data breach against Nutex Health. None of these require the attacker to be a genius. They require the attacker to have a process that works more than once.
What this does to procurement and vendor risk
If exploit development is now fast and cheap, the question a buyer needs answered from a vendor is not "how often do you patch." It is "how long between a public disclosure and a fix actually reaching production." Those are different questions with different answers, and most vendor questionnaires still only ask the first one.
There is already a document responding to that gap. The Collective Cyber Defense letter has effectively written the next generation of vendor questionnaires, pushing procurement conversations toward shared responsibility and faster verification rather than a checkbox about patch frequency. A financial watchdog has separately flagged cyber risk from frontier AI as the most immediate concern to the global financial system right now, which is a strong signal that this is not only a technical problem sitting with the security team. It is a procurement problem, a contract problem, and for anyone buying or recommending martech, adtech or agency infrastructure, a due-diligence problem that changes what a credible answer to "are you patched" actually has to include.
Untested systems are the same risk, just slower to notice
None of this requires the target to be glamorous. A whistleblower has raised concerns about the USPS deploying new, untested IT systems governing mail-in ballots, which is a reminder that the danger is not limited to obviously exposed software like an Exchange server or an AI workflow tool. Untested infrastructure carries the same exposure whether or not anyone has bothered to write an exploit for it yet, and the Schneier on Security "Rewiring Democracy" series has been tracking exactly this kind of quiet infrastructure risk as it applies to the machinery that underpins public trust rather than just corporate uptime.
The common failure mode across all of this, election infrastructure, industrial control systems, build pipelines and mail servers, is the same one: a gap between when something is known to be a risk and when it actually gets fixed, sized on the assumption that attackers are slow. That assumption is the part that is now wrong, and it is the part that patch schedules, vendor contracts and procurement questionnaires have not yet caught up to.