N-day Exploitation with Frontier Models

As always, take reports from Anthropic with a grain (or several) of salt. Still, this result is worth considering:

[Mythos] not only produced a full chain exploit, but produced eight distinct exploits, at a cost of $15,700 in API credits—an average of about $2,000 per privilege escalation. The binding constraint to N-days is now just a few thousand dollars and API access, which expands the pool of capable N-day attackers dramatically.

Also, it’s time to stop putting any weight on Microsoft’s exploitation predictions, if you still were.

2 Likes

Obvious grains of salt standing out to me, given I am done giving Anthropic any benefit of the doubt:

Firefox is once again not exploited as-a-whole but instead it only tests against the standalone version of the engine:

Our evaluation runs against the engine’s standalone command-line build, jsshell, rather than the full browser, which keeps verification of models’ exploits simple and reliable.

I personally am lacking the experience to assess to which degree these would be transferable into actual browser exploits and, in my opinion more importantly, how this translates into the capability to develop browser exploits - in the end this is the extraordinary claim they are implying but very much not showing. This is also the second time they are pulling something like this for Firefox, see Reverse engineering Claude's CVE-2026-2796 exploit .

For Windows: The most interesting aspect imo is the conflation of BSOD and LPE exploits. Don’t get me wrong, a crash being triggerable by a low priv user IS a problem. But honestly, this feels like it actually backs up Microsofts assessment of “Exploitation Unlikely” - only one of the 14 “Unlikely” Vulns was actually exploited as an LPE. I’d love to compare this to the actual MS advisories but unfortunately Anthropic doesn’t actually provide a list & a quick attempt to filter for CVEs in that timeframe also doesn’t yield any really useful lists.

I also somewhat take issue with the selected vulnerability class, to be honest, especially as framed in the conclusion: LPEs are neat & especially in AD environments potentially catastrophic, but they very much still require a local foothold. I know, assume compromise and all that, but these aren’t the vulnerabilities that make me wanna move to the N-hour thought model for patching.

I’d honestly love to see a more technical/detailed report on this :pensive_face:

3 Likes

I perhaps misread, but as I understood it, they specifically separated crashes (what they call “PoCs”) from functional “exploits.”

First, we measured how well each model could turn a patch into a proof-of-concept (PoC) crash. A PoC is not yet an exploit, but it is one of the hardest steps in creating one: it proves that an attacker has located the bug, understands what triggers it, and can hit it on demand.

I agree however about the LPE level of concern. What I find interesting about this report is the testing against compiled code and patch diffs, which is fundamentally different from what has been shared previously.

If there is significant capability to reduce time-to-exploit across all N-days, not just LPEs (which are abundant and likely a good test case), that’s something.

Sorry, should have been more clear: I take issue with the “PoCs” as a metric in general but especially as it relates to the MS exploitability assessment, these likely aren’t assessed as DoS vulnerability & this framing is typical of Anthropic Red Team releases & why I’m done giving the benefit of the doubt.

The fundamental result, the ability to derive functional exploits from binaries with some (claimed) reliability is indeed interesting & as someone in the machine of enterprise vulnerability management something I have been spending a lot of thoughts on.

Previously we were operating on CVSS for BAU and KEV/assumed exposure for prioritization, unfortunately exposure didn’t yet play into BAU as do not have a good way to programmatically assess exposure (we have a very fragmented infrastructure), with teams being able to set their own patching cycle beyond emergency patches. This will indeed need to chance, not just due to automated exploit generation but definitely accelerated by it: For highly exposed systems (e.g. internet facing applications, browsers, widely accessible internal network applications cough AD stuff) we need to move away from the reactive KEV model and towards exploitation probability as well as cranking up patch cycles.

This is why I am honestly happy to the see comparison to MS Exploitability Assessments, even though it’s kinda obscured through the PoCs: 7/7 “Exploit likely” CVEs were successfully exploited, 1/14 non-likely CVEs were successfully exploited - not a perfect score but mostly correct, close enough that I’d be happy to build my VM program on top of it.

Obviously that’s just Microsoft - has anyone looked at usefulness of EPSS for the general case yet?