AI just found 10,000 vulnerabilities. Some of them are in your code.

The most important AI story of the last two months was not a chatbot or a benchmark. It was Anthropic’s Project Glasswing, which used an unreleased model — Claude Mythos Preview — to find more than ten thousand high- and critical-severity software vulnerabilities across the world’s most systemically important code. Thousands of those were zero-days: previously unknown to the maintainers and to everyone else. The headline discoveries included a 27-year-old bug in OpenBSD and a 16-year-old one in FFmpeg, code that thousands of expert human eyes had already passed over.

Read that the right way round. If a model can autonomously find a flaw that survived a quarter-century of human review in some of the most scrutinised software on earth, the bar for “our code is probably fine because nobody has found anything” has just moved. The capability that found those bugs is not staying in a research lab. It is becoming a tool — and tools cut both ways.

Why this is different from the last security-tooling cycle

Static analysers and fuzzers have existed for decades. They find a class of bug, they generate a wall of findings, and most of those findings are noise. What changed with the Glasswing class of capability is that the model reasons about the code the way a skilled attacker does — it follows the data flow, understands the intent, chains several weaknesses into a real exploit, and writes up why it matters. Anthropic briefed senior US officials privately that an uncontrolled release of this capability could make large-scale cyberattacks significantly more likely. You do not say that about a better linter.

For a normal business — not OpenBSD, not a critical-infrastructure operator — the practical implication is simpler and more uncomfortable. The same capability that the defenders are using through programmes like this will be available, in some form, to people who do not file responsible-disclosure reports. The asymmetry that protected most companies — “we are not interesting enough for anyone to spend a researcher-month attacking us” — erodes when the researcher-month becomes a model-hour.

Where the bugs actually are

In the code you wrote fast. Every business has a tier of internal software that was shipped under deadline, never properly reviewed, and quietly became load-bearing. The integration that moves data between two systems. The admin panel only three people use. The webhook handler nobody has looked at since it worked. That is where the findings cluster.

In the AI code you shipped this year. There is a particular irony arriving in 2026. The coding agents that boosted everyone’s throughput also generated a large volume of code that nobody read line by line. Some of it is excellent. Some of it has the kind of subtle authorisation and input-handling mistakes that a model is now extremely good at finding. The teams who treated AI-generated code as automatically trustworthy are carrying the most uninspected attack surface they have ever had.

In the dependencies. The OpenBSD and FFmpeg findings make the point: your exposure is not just your code, it is the open-source you build on. A model sweeping a dependency tree finds things human audits never had the hours to reach.

What to actually do about it

The wrong response is to panic-buy an AI security scanner, point it at everything, and drown in a thousand findings with no one to triage them. A scanner that produces output nobody acts on has made you feel busy, not safe. The right response treats this as a software-engineering problem, which is what it is.

• Inventory what you run. You cannot assess code you have forgotten exists. The fast-shipped integrations and the AI-generated modules are the priority surface.
• Put AI-assisted review into the pipeline, not beside it. The value is in catching the bug before it merges, on the diff, with a human engineer accountable for the call — not in a quarterly scan that lands as a PDF.
• Re-review the code your agents wrote. Treat a year of AI-generated commits as exactly what it is: code that needs the review it never got, prioritised by what touches authentication, money, and customer data.
• Fix the dependency hygiene. Know your tree, watch the advisories, and have a tested path to patch quickly when — not if — something in it turns out to be exploitable.

This is squarely a build discipline, not an AI novelty — which is why it sits inside our Software Development practice. Wiring AI-assisted review into a working pipeline, re-inspecting a backlog of agent-generated code, and getting the dependency hygiene to a defensible state is engineering work done by people who have been on-call for what they shipped. The model is one tool in that work. The judgement about what to fix first is the job.

The honest counter-argument

You could reasonably say this is a story about the frontier, not about you — that the partners on Glasswing are AWS, Apple, and JPMorgan, and that the offensive version of this capability is gated, expensive, and not pointed at your invoicing system. Fair, for now. The defensive capability is here today and worth using; the offensive one is not yet a commodity. But the direction is not in doubt, and the cost of getting ahead of it — knowing what you run, reviewing what your agents wrote, patching what you depend on — is work you should be doing regardless of who finds the next zero-day first. Doing it now, while it is a precaution rather than an incident response, is simply cheaper.

The lesson of Project Glasswing is not that the robots are coming for your code. It is that the era when obscurity was a security strategy is ending. The findings were always there. Now something can find them at scale — and the only question is whether your team or someone else gets there first.

Shipped a lot of code fast this year — some of it AI-generated, most of it never properly reviewed? Talk to Cravings about a code-and-dependency review. We wire AI-assisted analysis into your pipeline, prioritise by real exposure, and leave your engineers able to run it themselves — not a one-off scan you cannot act on.