The headline number that should reorganise your security budget
On 26 May 2026 Anthropic published its first proper update on Project Glasswing, the open-source security initiative it announced earlier this month with roughly 50 partner organisations including AWS, Apple, Cisco, Google, JPMorgan Chase and Microsoft. The number the press has rightly latched onto is large: 23,019 vulnerabilities flagged across more than 1,000 open-source projects scanned by Claude Mythos Preview, of which an estimated 6,202 are high or critical severity.
That is not the most important number in the update. The most important number is <1%. That is the share of those vulnerabilities that have actually been patched. Read that sentence twice. The bottleneck in open-source security has now visibly moved from detection to triage and remediation, and most teams have not noticed yet.
For builders shipping in India and the United Kingdom — where regulators are tightening patch-SLA expectations under the DPDP regime and the UK Cyber Resilience framework — that 1% number is closer to a board-level metric than a CISO curiosity. This piece is a practical breakdown of what changed, where the actual risk sits, and what to do this week.
What Glasswing and Mythos Preview actually are
Project Glasswing is the umbrella initiative. Mythos Preview is the model. The arrangement matters because it shapes who can use the results today.
- Glasswing is a co-ordinated programme between Anthropic and roughly 50 partner organisations, the goal of which is to systematically scan large swaths of the open-source ecosystem that everyone else builds on top of.
- Mythos Preview is a non-public capability — a Claude variant configured for autonomous vulnerability research. Anthropic has been clear that Mythos Preview is not going generally available. The plan is to ship new safeguards with a future Opus model and then, later, to "enable users to safely deploy Mythos-class models at scale".
- What partners get today is the output of those scans flowing into responsible disclosure channels. What the wider world gets is the aggregate numbers — and, for affected upstream maintainers, the bug reports themselves.
This is the same operating posture you saw with the original Mythos Preview launch piece and the Claude Security beta: capability is staged behind safeguards before it lands in customer hands. The shipped, generally-available tooling today is Claude Mythos 1 inside Claude Code and Claude Security preview, which is a meaningfully less aggressive capability than what Mythos Preview is doing inside Glasswing.
If a vendor pitches you "Mythos-class scanning" before Anthropic has shipped the safeguarded release, ask precise questions. Do they have a Glasswing partner relationship? Are they relying on the publicly-available Claude Security preview? Or are they fine-tuning open-weight models to approximate the capability? The honest answer should reshape what you pay them.
The wolfSSL example, and why it matters in IN and UK shops
The most concrete disclosure in the update is a wolfSSL bug. Mythos Preview did not merely flag a suspicious code path — it constructed a working exploit that would allow an attacker to forge certificates. The bug now lives in the CVE database as CVE-2026-5194 with a CVSS score of 9.1.
wolfSSL is the kind of dependency that almost never appears on an executive risk register and almost always appears in production. It is embedded in:
- IoT firmware shipped by Indian electronics manufacturers exporting to the EU.
- Point-of-sale and fintech terminal stacks across the UK high street.
- Government-grade devices and citizen-facing kiosks in both jurisdictions.
- The TLS path on a non-trivial chunk of embedded Linux out in the field.
"Forge certificates" is regulator-grade language. For a regulated entity in India operating under DPDP, or a UK firm subject to the Cyber Resilience regime, an unpatched 9.1 in a TLS library is not a backlog ticket. It is a material control failure waiting to be discovered by an audit.
Mythos Preview produced the proof-of-concept exploit privately and disclosed responsibly. That does not mean adversaries cannot rediscover the same code path the moment a public CVE exists. The window between CVE publication and weaponisation by hostile actors has compressed sharply over the last 24 months. Treat any AI-discovered critical as if a working exploit already exists, because it does — it was just built by the good guys first.
Why <1% patched is the actual story
Open-source security has had a quiet structural problem for a long time: the people who find bugs and the people who fix bugs are usually different people on different timelines, and the fixer often does it in their spare time. The arrival of an AI scanner that can outpace any individual researcher does not change that structural mismatch. It widens it.
If a small, busy maintainer of a widely-depended-on library was already triaging two CVEs a quarter, dropping forty new ones into the queue in a single week does not produce forty patches. It produces a backlog and a stressed maintainer. The patch rate is what it is for human-process reasons, not technical ones.
For builders, this means three things have flipped overnight:
- Scanning is no longer the differentiator. If you were planning to procure scanning tooling as your 2026 security headline, downgrade that budget line. AI-assisted discovery is rapidly commoditising.
- Patch latency is the new attack surface. The interesting metric is "median time from upstream CVE publication to patched in your prod" — and it needs to be under your control, not your upstream's.
- Vendor questionnaires need a new column. "Do you scan?" is the wrong question. "What is your SLA on the patches your scanning surfaces?" is the right one.
The regulatory backdrop in IN and UK
This is the part most engineering posts skip and most lawyers over-index on. The honest middle is straightforward.
India. The DPDP regime has matured to the point where CVSS-9-class vulnerabilities in production systems handling personal data trigger reporting obligations on a clock measured in days, not quarters. The DPDP Phase II compliance playbook and the DPDP deepfake-rules builder checklist both spell out the implication: a known unpatched critical in your dependency tree is a documented control gap, full stop. Healthcare entities under DPDP Phase II should treat any unpatched 9.x-class CVE in their stack as a finding their next regulatory submission has to address.
United Kingdom. The UK Cyber Resilience framework and the post-Brexit conformity-marking regime impose patch SLAs on shipped software, particularly anything embedded or sold as a connected product. The EU AI Act GPAI enforcement checklist overlaps in the security obligations a GPAI provider must demonstrate. UK SaaS and fintech shops that sell into both EU and UK customers now sit in the worst place — overlapping regimes, both with teeth, both pointing at the same patch-latency metric.
The hard ask procurement teams should be making
Drop this verbatim into your next vendor security questionnaire:
"Do you, or any of your scanning vendors, currently run AI-assisted or Mythos-class vulnerability scanning on your codebase or your dependencies? If yes, what is your documented SLA from CVE publication to patched-in-production for vulnerabilities at CVSS 7 and above? Provide median and 95th-percentile values from the last four quarters."
That single paragraph reframes the conversation away from theatre ("we are SOC 2") and onto operational reality ("here is our actual patch median"). Vendors who cannot answer it should be treated as a procurement risk.
What to do this week
A concrete, four-step plan for any builder team between five and five hundred engineers.
1. Inventory your OSS supply chain (one day)
You almost certainly already have an SBOM somewhere — generated by your build pipeline, sitting in a CI artefact nobody looks at. Surface it. Sort the dependencies by transitive blast radius, not direct usage. The TLS, parsing, and serialisation libraries are the ones that bite — wolfSSL, OpenSSL, libxml2, libxslt, expat, zlib. If you cannot generate an SBOM today, this is the prerequisite step.
2. Subscribe to upstream security feeds for your top-20 dependencies (half a day)
Most maintainers publish a security advisory feed, an RSS, or at minimum a tagged release-notes channel. Wire those into a single Slack or Teams channel that the on-call engineer actually watches. When an advisory appears, you should hear about it before your scanner does — your scanner only knows what the public CVE database knows, which is days behind the upstream advisory.
3. Set an internal CVSS-9-or-higher SLA in writing (one meeting)
Pick a number you can actually hit. 72 hours from upstream advisory to deployed patch is aggressive but achievable for most SaaS stacks. 7 days is the outer bound any regulator will respect. Write it down. Put it in the security policy. Reference it in your vendor questionnaire as the standard you hold yourself to. The number you commit to publicly is the floor — internal targets should be tighter.
4. Budget remediation hours, not just scanner licences (next quarter)
This is the budget shift the <1% patch number is screaming about. If you are spending fifteen thousand a year on scanning tooling and zero dedicated engineering hours on remediating what it finds, you are buying anxiety, not security. Reverse the ratio. Two engineer-days a sprint on dependency-CVE work, every sprint, is what closes the patch gap.
"We were running three scanners and patching exactly nothing — every Monday morning was a new dashboard full of red and the same conversation about who owned it. We dropped two scanners, kept the cheapest one, and bought ourselves an extra senior engineer with the saved budget who does nothing but ship dependency upgrades. Our median patch latency went from 'I don't know' to 11 days inside two quarters."
— Verified Builder, fintech platform team · BengaluruWhat to watch next
- The safeguarded Opus release. When Anthropic ships the future Opus with the planned Mythos safeguards, that is the moment Mythos-class scanning starts to land in customer hands. Treat it as the procurement decision point.
- Upstream maintainer capacity. Watch which heavily-depended-on libraries acquire funding or paid maintainers in response to the disclosure firehose. Those are the ones that will keep up; the rest will fall further behind.
- Insurance underwriting. Cyber insurers will start asking patch-latency questions at renewal. The firms that can answer with a number will pay less.
- Self-host scanning economics. As GPU pricing keeps coming down — see our H100 price-decline guide — running your own scanner stack on open-weight models becomes a real option for shops with the talent to do it.
Want to find security engineers who actually patch what they find?
AI Tech Connect lists Verified Builders across India and the UK with platform, security, and infra specialisations. Shortlist up to five and we'll email their contact details.
Browse Builders →The bottom line
Project Glasswing has decisively shown that AI-assisted vulnerability discovery works at scale. Anthropic has also, deliberately and visibly, kept Mythos Preview out of general customer hands until the safeguards are ready. That is the responsible call.
The unresponsible call would be for the rest of the industry to treat 23,019 found and <1% patched as a vendor problem. It is not. It is a budget problem, a process problem, and — for regulated builders in India and the UK — a compliance problem with a clock on it. The good news is that all four of the action items above can be started this week with no new tooling and no new headcount. The number that matters in 2026 is not how many CVEs you can detect. It is your median patch latency. Start measuring it.
Primary sources: anthropic.com/research/glasswing-initial-update and anthropic.com/glasswing. Press coverage: The Hacker News and Help Net Security.