- › Anthropic's Mythos model derived a key-recovery attack on the HAWK-256 post-quantum signature scheme in about 60 hours for roughly $100,000, against a design human experts had reviewed for over two years.
- › The same effort produced a 200- to 800-fold speedup on an attack against seven-round AES-128, and none of it breaks the cryptography you have deployed today.
- › VulnCheck reports that fewer than 2% of AI-assisted vulnerability discoveries have been turned into working exploits, so discovery is scaling far faster than weaponization.
- › That gap is the actual news. Your queue will fill with real but mostly unexploited findings, and triaging by severity score will drown you.
- › Invest in two things: exploitability-based triage so you work the findings that can actually be used, and crypto agility so a broken algorithm is a configuration change instead of a rewrite.
Two stories landed this week that look like they contradict each other, and the space between them is the most useful thing a security leader can think about right now.
The first: Anthropic says its Mythos model helped derive an end-to-end key-recovery attack against HAWK-256, a post-quantum signature scheme, by exploiting a symmetry in the underlying lattice that nobody had used before. Human cryptographers had been reviewing that design for more than two years. The model got there in roughly 60 hours at about $100,000 in API cost. The same work produced a 200- to 800-fold speedup on an attack against seven-round AES-128.
The second: VulnCheck reports that fewer than 2% of AI-assisted vulnerability discoveries have been turned into working exploits.
Read those together and the headline writes itself in a way that most headlines this week got wrong. Machines are getting dramatically better at finding flaws. They are not, so far, getting proportionally better at turning those flaws into attacks that work against real systems. Discovery and weaponization have come unglued from each other, and almost every practical decision you make this year should account for that gap.
What the Cryptography Result Actually Says
Start with what did not happen, because the temptation to panic is strong and unhelpful.
Your TLS did not break. Your VPN did not break. AES-128 as you deploy it did not break, because the speedup applies to a seven-round reduced variant, which is a research construct used to probe the security margin of the full cipher. Cryptographers attack reduced-round versions the way structural engineers load-test a scaled model. Finding a faster attack on seven rounds tells you something real about the margin and tells you nothing about whether the full algorithm is at risk today.
HAWK-256 is a different matter, and still not a fire drill for most organizations. It is a candidate post-quantum signature scheme, which means it was in the queue of designs being evaluated for the future, not the algorithm signing your certificates this morning. A key-recovery attack against it is a serious cryptanalytic result that likely removes it from contention. That is the peer review process working, which is exactly what candidate schemes exist to undergo.
So what changed? The economics of cryptanalysis. Sixty hours and $100,000 is a rounding error for a nation-state and a manageable budget for a well-funded criminal group. Serious review of a cryptographic design used to require scarce human expertise applied over years. Now a meaningful fraction of that review can be bought. That is a genuine shift, and it cuts both ways: the same capability that could find a weakness in a scheme you depend on is the capability that just found this one before it got deployed.
The practical consequence is not that cryptography is failing. It is that the review cycle for cryptography just got much faster, which means the shelf life of any given algorithm is now less predictable than it was. That is an argument for agility, and I will come back to it.
The Gap Is the Real Story
Now the 2% number, which got a fraction of the attention and deserves more.
If frontier models were handing attackers a decisive advantage, we would expect the pipeline from AI-discovered flaw to working exploit to be short and busy. VulnCheck’s data says it is neither. Finding that something is broken turns out to be a very different problem from reliably exploiting it against a specific target, and the second problem has not yielded the way the first one has.
This makes sense if you have ever done the work. A discovered vulnerability is a hypothesis. Turning it into an exploit means defeating memory protections, dealing with version differences, surviving whatever mitigations the target actually runs, achieving reliability, and doing it without crashing the thing you want to keep access to. That chain has many links, and models are currently much better at the first one than at the rest.
Two caveats, because I do not want to sell false comfort. First, this is a snapshot, and the trend line matters more than the number. The same curve that made discovery cheap will work on exploitation, and the 2% figure should be re-checked, not memorized. Second, a low weaponization rate across a much larger pile of findings can still mean more real exploits in absolute terms. Two percent of an enormous number is not nothing.
But the shape of the problem for defenders is clear. You are going to receive far more genuine vulnerability findings than before, and a very small fraction of them will ever be used against you. If your program responds to that flood by working the queue in severity order, you will spend the year patching things nobody was ever going to exploit while the handful that mattered sits somewhere in the middle of the list.
Triage on Exploitability, Not Severity
This is the same argument I made when the window from patch to exploit collapsed in our piece on N-day becoming N-hour, approached from the opposite direction. There, the point was that you cannot win a race measured in hours with a process measured in weeks. Here, the point is that most of the race is not real. Both lead to the same place: stop treating a CVSS score as a work order and start asking whether a given finding is reachable and usable in your environment.
The mechanics of that are well established and underused. VEX, the Vulnerability Exploitability eXchange, exists precisely so a vendor can tell you that a vulnerable component in their product is not actually exploitable in the configuration you run, and so you can record the same determination for your own software. Paired with an SBOM, it turns “we contain a vulnerable library” into “we contain a vulnerable library in a code path that is never reached,” which is the difference between an emergency and a note in the backlog.
Three questions belong in front of every finding, before anyone schedules a change window:
Is it reachable? Can an attacker get to the affected code path from somewhere they can stand? An unauthenticated flaw on an internet-facing service and the same flaw in a library that only runs during an offline batch job deserve completely different responses.
Is it usable? Does a working exploit exist, or is this still a research finding? Exploit availability is a fact you can check, and it is a far better prioritization signal than a severity number assigned in the abstract.
Does something already stop it? If the exploitation technique hits a control that holds, the unpatched flaw is contained while you schedule the fix properly. This is the layered thinking behind our ransomware prevention framework, applied to triage instead of response.
None of this is an argument to stop patching. It is an argument to spend your finite change windows on the findings that can actually hurt you, which is the only way to survive a discovery pipeline that has gotten this productive.
Build Crypto Agility Before You Need It
Back to the cryptography, because it deserves a specific answer rather than a shrug.
The lesson from HAWK is not that post-quantum cryptography is unreliable. It is that any algorithm’s status can change faster now, because the cost of finding out has dropped. The organizations that handle that well are the ones that can swap an algorithm without rewriting an application, and that capability has a name: crypto agility.
Most organizations do not have it, and discover this at the worst possible time. Algorithms get hardcoded into applications. Key sizes get baked into protocols and file formats. Certificates get issued with parameters nobody wrote down. When an algorithm becomes untrustworthy, the work is not a configuration change, it is an archaeology project across every system that ever touched it.
The groundwork is unglamorous and worth doing now, and it is the same inventory work that underpins any post-quantum migration roadmap. Know which cryptographic algorithms your systems actually use, including inside third-party components. Know where the implementations live. Abstract cryptographic operations behind interfaces so an algorithm is a parameter rather than a permanent decision. And run the exercise of asking how long it would take to replace one, because the answer today is the answer you will get on the day it matters.
If your honest estimate is measured in years, that is your finding. It is more important than any individual CVE in your queue.
What This Week Should Change
The takeaway is narrower than the headlines and more useful.
AI has become a serious instrument of vulnerability discovery, including against mathematics that resisted human review for years. That is real and it is not going to reverse. What has not happened, at least yet, is a matching collapse in the difficulty of turning those discoveries into working attacks, and that gap is the window you get to work in.
So use it. Build the triage discipline that separates reachable and usable findings from the growing pile of real-but-inert ones. Build the agility that lets you replace a cryptographic algorithm on a normal schedule instead of an emergency one. Both of those are investments in your ability to absorb a faster discovery cycle, which is the durable condition here, rather than reactions to any single result.
The machine found the flaw. Almost nobody weaponized it. The program that survives the next few years is the one that can tell the difference, quickly and repeatedly, without burning its people on the 98%.
If you want to know which of your exposures are actually reachable and exploitable rather than merely rated critical, and how long it would really take you to swap a cryptographic algorithm, that is the work we do. Start with our free Human Attack Surface Score, or contact Grab The Axe and we will map it the way an adversary would.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
