Anthropic's Project Glasswing gave limited access to Claude Mythos Preview — a model reportedly able to identify and exploit zero-day vulnerabilities across major operating systems and browsers, including multi-stage exploit chains. Anthropic says more than 99% of the vulnerabilities it found remain unpatched.
That is the data point that matters.
The usual reaction to announcements like this is a philosophical debate about how many of those bugs were already known to someone and just unreported. That is a rabbit hole not worth digging. Assume the less flattering answer - act on that.
Software will not suddenly stop working. Codebases are not worthless. Nobody has to rewrite everything next quarter.
What changed is the economics of offense.
What actually got cheaper
A model like Mythos does not need to invent new classes of vulnerabilities to cause disruption. It only needs to reduce the skill, time, and cost required to find real bugs, weaponize them, and chain them together.
Anthropic explicitly warns that defenses whose main value is friction rather than a hard barrier will erode against model-assisted attackers, because models can grind through tedious exploit-development work at scale.
An example of what "friction" means in practice: a stripped closed-source binary that used to cost a specialist a weekend of reverse engineering to map. A heap-grooming sequence only one in ten offensive researchers could reliably land. A logic bug buried three layers deep in a state machine nobody wanted to audit by hand.
That kind of work compresses.
Mythos reportedly found memory-corruption bugs, logic bugs, cryptographic implementation weaknesses, browser exploit chains, and vulnerabilities inside closed-source binaries via reverse engineering. Five bug classes. One pipeline.
The short version:
- exploit development gets faster
- exploit chaining gets easier
- reverse engineering gets cheaper
- patch windows get more dangerous
- "annoying but probably fine" exposures get less fine
What software companies should actually do
Most writing about AI risk becomes either philosophy or panic. Neither is operationally useful. Here is the triage.
1. Build an honest asset inventory
Not a compliance spreadsheet. An actual map: what is internet-facing, what runs with elevated privilege, what is written in memory-unsafe languages, what parses untrusted input, what sits before authentication, what cannot be patched quickly, what third-party components quietly expand the attack surface.
Without this, you are not doing prioritization. You are doing vibes.
2. Split the estate into rewrite, isolate, monitor
Rewrite: high-risk parsers, security-critical low-level services, old C/C++ components exposed to hostile input, brittle auth or crypto-adjacent implementations.
Isolate: legacy services you cannot replace in 12 months, components with known rough edges and clear business dependency, anything that can be boxed into stricter privilege boundaries, seccomp profiles, sandboxes, or service segmentation.
Monitor: lower-risk business logic, standard SaaS code in managed runtimes, internal tooling with constrained exposure.
The point most teams miss: the right response to Mythos is not "rewrite everything." It is "be much more honest about what deserves rewriting first."
3. Make patch latency an executive KPI
If 99% of Mythos-found vulnerabilities remain unpatched, the bottleneck is not discovery. It is organizational response speed.
The question is no longer could someone find this bug? It is could we fix, validate, and deploy the patch before someone industrializes it?
Patch velocity is now a business capability. Not just a security metric.
4. Discount "attacker effort" in your severity model
A vulnerability that used to be dismissed as "the exploit path is too tedious" is more dangerous than it looked six months ago. A chain that used to require an unusually strong offensive researcher may increasingly be available to a competent operator with a good model and enough compute.
That does not mean every bug is suddenly critical. It does mean your severity rubric should stop leaning on attacker inconvenience as a mitigation.
5. Default new security-critical code to memory-safe stacks
Not ideology. Risk concentration. You do not need to rewrite mature systems tomorrow. You should probably stop creating fresh long-term exposure in exactly the places where a language choice removes entire bug classes.
6. Add model-assisted workflows to defense now
Anthropic's own framing is that the long-run equilibrium may still favor defenders — the way fuzzers eventually did — but the transitional period favors attackers if defenders are slower to adapt.
That means AI-assisted code review, exploitability analysis, dependency triage, fuzzing and testcase generation, and regression verification after patches.
If offense becomes automated while defense stays ticket-driven and manual, the gap widens fast.
7. Stop treating architecture as separate from security
The companies that look smartest in 18 months will not be the ones that wrote the most urgent memos.
They will be the ones that quietly reduced blast radius.
Least privilege, segmentation, sandboxing, narrow interfaces, ephemeral credentials, isolated parsers, fast rollback paths. All of those become more valuable when exploit development gets cheaper.
The real question
Mythos does not mean software companies need to rewrite everything.
It means they have to stop pretending their backlog is neutral.
A lot of organizations have accumulated technical debt under the quiet assumption that the exploit-development bottleneck was mostly on the attacker side. That assumption is weakening.
What used to be "we should clean this up eventually" is increasingly "this is a compounding liability."
The next 12 months are not about panic. They are about sorting your projects into three buckets:
- things you can still safely defer
- things you must isolate now
- things you should never have built that way again
Not "do we rewrite everything?"
But "which parts of our system can no longer rely on attacker friction to stay safe?"
That is a much better executive question.
And a much more expensive one to answer late.
Top comments (0)