What Anthropic Mythos Means for Cybersecurity

Last Updated on April 29, 2026 by Arnav Sharma

On April 7, 2026, Anthropic dropped a bomb on the security industry. Their new AI model, Claude Mythos Preview, can autonomously find zero-day vulnerabilities in major operating systems, web browsers, and cryptography libraries, and then write working exploits for them. Not with human hand-holding. Not with detailed instructions. With little more than a prompt that says “find a security vulnerability in this program.”

The oldest bug it found? A 27-year-old flaw in OpenBSD, an operating system whose literal brand identity is security.

This isn’t a research paper or a proof of concept. Anthropic found thousands of high and critical severity vulnerabilities across some of the most audited code on the planet. They reported a 17-year-old remote code execution bug in FreeBSD’s NFS server (CVE-2026-4747) that grants root access to unauthenticated users from anywhere on the internet. That one was discovered and exploited end-to-end by Mythos with zero human involvement.

If you work in security, this changes how you plan your next twelve months. Here’s why, and what to do about it.

The Capability Jump That Matters

To understand why Mythos is different, you need to see where the bar was a few months ago.

Anthropic’s previous model, Opus 4.6, was already good at finding vulnerabilities. When pointed at Firefox’s JavaScript engine, it identified real bugs that Mozilla patched. But turning those bugs into working exploits? Opus 4.6 managed that twice out of several hundred attempts. Its autonomous exploit development success rate was basically zero.

Mythos Preview ran the same benchmark and produced 181 working exploits. That’s not an incremental improvement. That’s a capability that didn’t exist before.

The model wasn’t specifically trained for offensive security work, either. These capabilities came as a side effect of general improvements in code reasoning and autonomous problem-solving. The same skills that make the model better at patching bugs also make it better at exploiting them. If you’ve been hoping that offensive AI capabilities would stay bottled up in purpose-built tools, that hope just expired.

What Mythos Actually Did

The technical details from Anthropic’s red team blog are worth sitting with, because they illustrate the kind of work this model can do autonomously.

The OpenBSD TCP SACK Bug

Mythos found a vulnerability in OpenBSD’s implementation of TCP Selective Acknowledgement (SACK) that had been sitting in production code since 1998. The bug involves a subtle interaction between two separate flaws: a missing bounds check on SACK block start values, and a null pointer dereference that only triggers when signed integer overflow causes the kernel to satisfy two contradictory conditions at the same time.

Nobody would write a fuzzer to look for this. The bug depends on the math of 32-bit integer overflow interacting with specific linked-list traversal logic. Mythos identified it by reading the source code, forming a hypothesis about how the signed comparison could overflow, and then confirming that the resulting null pointer write would crash the machine.

That’s not pattern matching against known vulnerability classes. That’s reasoning about code behaviour.

The FreeBSD NFS Exploit

The FreeBSD remote code execution (CVE-2026-4747) is more straightforward in concept but impressive in execution. A stack buffer overflow in the RPCSEC_GSS authentication handler lets an attacker write 304 bytes of arbitrary content past a 128-byte buffer. Normally, stack canaries would prevent exploitation. But the buffer is declared as int32_t[32]rather than a char array, so the compiler’s -fstack-protector flag doesn’t instrument it. FreeBSD also doesn’t randomize kernel load addresses, so predicting ROP gadget locations is trivial.

Mythos handled all of this autonomously, including a trick where it split the full ROP chain across six sequential RPC requests because the usable overflow space was only 200 bytes. It even figured out how to obtain the kernel’s hostid and boot time through an unauthenticated NFSv4 EXCHANGE_ID call to bypass a handle authentication check.

The whole thing, discovery through working root-shell exploit, happened without a human touching it after the initial prompt.

Browser JIT Heap Sprays and Kernel Privilege Escalation

The blog also describes Mythos chaining four vulnerabilities together to build a JIT heap spray in a web browser that breaks out of both the renderer sandbox and the OS sandbox. For Linux kernel exploitation, Mythos independently identified and chained together separate read, write, and KASLR bypass primitives to construct full privilege escalation attacks.

I’ve worked with pen testers who would need weeks to pull off what this model did in hours. The cost for the FreeBSD exploit chain? Under $50 for the specific run that found the bug, though of course Anthropic ran many attempts across the codebase at a total cost under $20,000.

Why Restricted Release Was the Right Call

Anthropic decided not to release Mythos publicly. Instead, they created Project Glasswing, a consortium of 12 partner organisations including Amazon, Apple, Microsoft, CrowdStrike, Cisco, and the Linux Foundation. About 40 organisations total will get access to the preview.

Some people were angry about this. Some accused Anthropic of not having enough GPUs to run the model at scale and using safety as cover. Others pointed to the irony of an AI company building something dangerous and then deciding who gets to use it.

Both criticisms miss the point.

The partner list tells you everything you need to know about the intent. These are the organisations that maintain or depend on the most widely deployed software on earth. If Mythos can find thousands of critical vulnerabilities in the Linux kernel, FreeBSD, Chrome, Firefox, and major cryptography libraries, then the responsible thing is to get those bugs patched before the model (or a competitor’s equivalent) is publicly available.

Bruce Schneier put it well in his IEEE Spectrum piece with Barath Raghavan: Mythos is a real but incremental step. The question isn’t whether this capability was coming. It was. The question is how we adapt to it.

What This Means for Your Security Programme

Patch Cycles Need to Get Faster. Much Faster.

The N-day exploit demonstrations are the scariest part of the Anthropic blog, even though they use already-patched vulnerabilities. Mythos took a list of 100 CVEs from 2024 and 2025, filtered them to 40 candidates, and turned more than half into working privilege escalation exploits. Each one started from nothing but a CVE identifier and a git commit hash.

That pipeline, going from public vulnerability disclosure to working exploit, used to take a skilled researcher days or weeks. Mythos does it in hours for under $2,000.

This compresses the window between patch release and active exploitation to almost nothing. If your organisation’s patch cycle is measured in weeks or months, you’re going to have a very bad time. Auto-update everywhere you can. Treat CVE-carrying dependency bumps as urgent, not routine. Push your vendors to ship out-of-band fixes faster.

Your Vulnerability Management Programme Needs a Rethink

Alan Osborne, CISO at Paysafe, made a good point in his TechTarget interview: most organisations already identify more vulnerabilities than they can fix. Mythos doesn’t change that fact. It makes it more visible.

The shift here is from “how do we find vulnerabilities?” to “how do we decide which ones matter?” Traditional severity ratings become less reliable when an AI can chain together three “medium” findings into a working root exploit. Your risk-based prioritisation model needs to account for the fact that exploit chains are now cheap to construct, not just for nation-state actors, but for anyone who can access a capable model.

I’ve seen too many organisations treat vulnerability management as a compliance checkbox. You run a scan, export a spreadsheet, assign tickets, and close them when the auditors come around. That model is dead. Vulnerability management is now a time-critical operations function.

Friction-Based Defences Are Losing Value

Here’s a line from Anthropic’s blog that security architects should pin to their wall: “Mitigations whose security value comes primarily from friction rather than hard barriers may become considerably weaker against model-assisted adversaries.”

Think about what this means. A lot of our defence-in-depth measures don’t actually prevent exploitation. They make exploitation tedious. They add complexity that a human attacker has to grind through. A model like Mythos grinds through those steps quickly and cheaply, running for hours without getting bored or making careless mistakes.

Hard barriers still matter. KASLR, W^X (write XOR execute), memory tagging, sandbox boundaries with separate privilege domains. These impose real constraints that even a capable model has to work around. But security controls that just add “steps” without adding hard stops? Those need re-evaluation.

Legacy and Unpatchable Systems Need Isolation, Not Hope

Schneier’s taxonomy is useful here. Sort your systems into two categories: patchable and unpatchable. Then sort again: easy to verify and hard to verify.

For patchable systems that are easy to verify (your cloud applications, your SaaS stack, your phones and browsers), the defence wins eventually. Patch faster, test harder, deploy AI-driven vulnerability scanning on your own code before someone else does.

For unpatchable systems (IoT devices, industrial control systems, embedded firmware, that legacy banking application from 2003 that nobody wants to touch), the answer hasn’t changed, but the urgency has. Wrap them in restrictive network controls. Put them behind firewalls that are themselves continuously monitored and patched. Stop letting your fridge talk to the internet.

If you’re responsible for a code base that hasn’t been updated in years and can’t easily receive patches, start planning a contingency now. Not next quarter. Now. What happens when someone reports a critical vulnerability in a product whose original development team no longer exists?

Start Using AI for Defence Today

This is the part where I tell you to fight fire with fire, and I know it sounds like vendor marketing. But the data supports it.

Anthropic’s own data shows that their previous model, Opus 4.6, found high and critical severity bugs almost everywhere it looked, even in heavily audited code bases like the Linux kernel and FFmpeg. Mythos finds more, but the gap between “publicly available frontier model” and “no model at all” is already enormous.

Here’s a non-exhaustive list of what you can do right now with models that are generally available:

• Run frontier models against your own source code to find bugs before attackers do
• Use AI-assisted triage to evaluate incoming vulnerability reports for severity and exploitability
• Have models write reproduction steps and draft patches for confirmed bugs
• Scan cloud environments for misconfigurations
• Integrate model-assisted code review into your pull request workflow
• Use models to de-duplicate and prioritise incoming bug reports

None of this requires Mythos-level capability. It requires deciding to start, building the scaffolding, and learning what works. The organisations that invest in these workflows now will be better positioned when more capable models become broadly available.

Incident Response Needs Automation Too

If vulnerability discovery is about to accelerate by an order of magnitude, so will exploit attempts. Your SOC is going to see more incidents. Your incident response team is going to need help.

Models can already handle alert triage, event summarisation, investigation hypothesis generation, and preliminary root cause analysis. During an active incident, they can capture artifacts, pursue investigation threads in parallel, and draft the initial post-mortem while the human team focuses on containment and recovery.

I’m not saying replace your IR team with a chatbot. I’m saying the volume of work is about to outstrip what any human team can handle without automation.