Project Glasswing and the CVE Avalanche: Why Your Cloud Blast Radius Is the New Control Plane

On April 7, 2026, Anthropic announced Project Glasswing, a partnership with over 40 organizations and $100 million in model credits, aimed at finding and fixing vulnerabilities in the software the world depends on. The instrument is Claude Mythos Preview, an unreleased frontier model that, on Anthropic’s own benchmarks, outperforms its predecessors on every cybersecurity task measured. The stated goal is to give maintainers of critical infrastructure a head start before the same capability proliferates.

One signal of what “head start” looks like: a community-maintained tracker, Anthropic-Credited-CVEs, already lists 51 CVEs credited to Anthropic researchers in the roughly two months from February 19 to April 23, 2026. Almost every entry is critical or high CVSS, and almost every project is open-source.

Anthropic’s own announcement contains a quote security teams should print and put on the wall. Elia Zaitsev, CrowdStrike’s CTO:

The window between a vulnerability being discovered and being exploited by an adversary has collapsed. What once took months now happens in minutes with AI.

If Zaitsev is right, the patching gap is no longer a project-management problem that can be solved with better processes. It is a structural mismatch between the speed at which vulnerabilities can be found and weaponized, and the speed at which organizations can ship patches across heterogeneous fleets. At PanIAM, we believe that this mismatch makes a particular class of cloud security control, identity-graph and blast-radius analysis, no longer a nice-to-have but a first-line defense.

What the CVEs Already Tell Us

The 51 CVEs are not a random sample. Twenty-one are in Mozilla Firefox, a code base that already has a mature fuzzing program and bug bounty. Eleven are in cryptographic libraries (OpenSSL, wolfSSL, BC-JAVA), some of the most scrutinized code on the internet. The rest fall across FreeBSD, NGINX Plus, AWS Firecracker, and Ghost CMS: software that runs inside every cloud account.

What does not appear in the CVE tracker is just as informative: findings that got fixed silently. OpenBSD 7.8 errata quietly shipped a patch on March 25, 2026, for a 27-year-old TCP SACK kernel crash that Anthropic’s Frontier Red Team later confirmed Claude Mythos had found, at a discovery cost under $50. No CVE was filed because the outcome is a remote crash rather than full exploitation. In any cloud where availability matters, “no CVE” is not the same as “no problem”.

Taken together, the public CVEs and the silent OpenBSD fix tell a consistent story. AI-assisted vulnerability discovery is already shipping into the open-source supply chain that every cloud workload depends on, partly through public CVEs, partly through silent patches, and at a volume trending up month over month.

Mythos Is Not Special: the “System over Model” Case

A natural reaction to the numbers above is: this is about Anthropic’s frontier model, so the risk is gated by access to that model, and only well-resourced defenders and researchers are likely to use it. Project Glasswing even makes this argument explicit: Mythos Preview is intentionally not generally available, and a partner program gates access.

Stanislav Fort at AISLE has made that argument obsolete.

In “System over Model: Zero-Day Discovery at the Jagged Frontier”, Fort points a single-file scanner running a small, cheap model at the FreeBSD kernel: 35,000 files, 7.5 million lines of code, scanned in roughly 10 hours for under $100 of API spend over a weekend. It found two confirmed bugs in NFS RPCsec_gss and a 26-year-old memory-safety issue in FreeBSD networking code. A 3.6-billion-parameter open-weights model reliably reproduced detection of one of Mythos’ own flagship findings across multiple runs. The cheapest open-weights pipeline he tested is roughly 600 times cheaper per token than Mythos.

The thesis of the post, quoted verbatim, is pointed:

A single brilliant model may reason more deeply about each piece of code, but a much cheaper model can look literally at every piece of code.

What this means for a defender is simple and uncomfortable: the capability to find deep, long-lived bugs in open-source code has moved from “requires a frontier model” to “fits in a weekend and under $100”. That is not hypothetical. It has been demonstrated, disclosed to maintainers, and open-sourced.

For any threat model that includes well-resourced adversaries (state actors, organized crime, established ransomware groups), those adversaries already run this kind of pipeline, or soon will, and they are not disclosing findings to maintainers. They are sitting on them. Chainalysis’ 2024 Crypto Crime Report puts 2023 ransomware payments above $1 billion, with individual strains reportedly clearing nine-figure annual revenue: a $100 weekend pipeline is a rounding error at that budget. We wrote previously about why backups and paying the ransom are not a real plan; commodity-cost bug discovery is exactly the kind of capability increase these groups absorb without friction.

The Glasswing gate controls access to one frontier model. It does not control access to the category of capability the model represents. That category now runs on a laptop.

The Exploit-Time Gap Is the Real Problem

Put Zaitsev’s “minutes” next to ordinary cloud patching, which most fleets measure in weeks for typical workloads and months for anything requiring a maintenance window, change review, vendor coordination, or appliance firmware update. Those timelines exist for legitimate operational reasons, not incompetence.

The first line of defense can no longer be “patch quickly”. It has to be “assume any given workload or identity will be compromised faster than you can patch, and design the cloud such that the compromise does not expand”. That design principle has a name (zero trust) and a set of operational subprinciples (least privilege, strong identity boundaries, explicit trust relationships, and smallest-possible blast radius). What it demands, in practice, is a clear answer to two questions:

1. Which entry point in my cloud, if compromised, puts the most sensitive data at risk?
2. For any given configuration or CVE, which workloads or identities can reach which sensitive resources?

These questions cannot be answered by reading individual policies. They require a model of the cloud that knows every identity, every resource, every trust edge, and every possible path.

Two Scenarios, One Answer

Glasswing plays out one of two ways over the next twelve to twenty-four months, and a defender should prepare for both.

Scenario A: the avalanche. Glasswing partners publish hundreds to thousands of CVEs against the open-source software every cloud runs on. Vendors ship patches on 90-plus-45-day timelines, cloud providers ship them downstream at their own cadence, and most users patch at whatever cadence change management allows. Attackers, with a few days to a few weeks of pre-disclosure visibility, have a wide window to operationalize exploits against unpatched fleets. The question is not “what is patched” but “if a workload running this vulnerable component is compromised, what data is reachable?”, and that is a graph query on the identity and resource model of the cloud.

Scenario B: silence. Glasswing does not produce an avalanche. Partners use Mythos Preview quietly, ship patches without CVEs (the way the OpenBSD SACK fix did), and the public CVE stream stays manageable. This is, in some sense, worse for defenders: well-resourced attackers running their own AISLE-style pipeline will find the same bugs and not tell anyone. There is no CVE to patch. The only defensible posture is, again, assume compromise and constrain blast radius.

Both scenarios converge on the same defensive to-do list:

1. Enforce least privilege on every identity in the cloud, continuously. “Periodic audit” is not enough when the threat timeline is days.
2. Enumerate and rank entry points by blast radius. Not every public-facing workload is equally risky. The ones connected to identities that reach crown-jewel data are the ones that matter.
3. Detect lateral-movement paths that do not require a CVE at all. Permission misconfigurations already let an attacker expand access without exploiting any code bug, as we documented in our recent post about vulnerabilities that hide within trust policies.
4. Prioritize remediations by risk reduction, not CVSS. A critical CVE on a workload that cannot reach anything sensitive can wait. A medium CVE on a workload that holds the keys to the kingdom cannot.

All four items are graph problems.

The Cloud Identity Graph Is Your Control Plane

A modern cloud account, regardless of provider, has the same shape. There are identities (users, roles, workloads, external principals), resources (compute, data, secrets), and trust edges (identity policies, role-assumption rules, resource policies, network rules). The state of the cloud is a graph, and almost every real attack path is a path in that graph. PanIAM models this graph.

Consider a concrete question triggered by a Glasswing CVE. Suppose a critical CVE drops against libexpat, a widely-used XML parser that sits in many server-side stacks. A defender needs to answer three questions, in order:

1. Which of my workloads have a reachable code path through the vulnerable component?
2. If any of those workloads is compromised, what identities and roles does it inherit?
3. From those identities and roles, what sensitive resources are reachable, directly or via further lateral movement?

Without a graph, each question requires a bespoke investigation. With a graph, each question is a query.

The first question is answered by combining software inventory with network reachability. Which hosts expose the vulnerable code on a network boundary? PanIAM’s Remediations feature integrates CVE and exploit data directly with the identity and resource graph, so the question “which of my vulnerable workloads are actually reachable by an attacker” is a first-class query, not a three-tool investigation.

The second question is where the graph pays off. A compromised VM is not just a compromised Linux box. It is every identity attached to it (the instance profile, a chain of assumed roles, cached SSO credentials). Each of those identities has a policy surface that can be extremely wide or extremely narrow depending on configuration. The identity surface of the compromised workload is what the attacker inherits. A graph makes that surface explicit.

The third question is the one that matters for blast radius. For every identity the attacker now holds, what can they reach? This is a closed-form query on the graph, not a manual policy review. It includes obvious edges (an object-store bucket the role can read) and non-obvious ones (a role this role can assume, a trust policy this role can modify, a secret this role can read that unlocks further access). We wrote a full post on one of the non-obvious ones, iam:UpdateAssumeRolePolicy. There are many others.

The same graph answers a forward-looking question, too: before any CVE drops, which entry points are most dangerous? An entry point is any identity or workload compromisable from outside the account (a public IP, an SSO user, a federated role, a CI/CD webhook). Ranking entry points by reachable blast radius gives a prioritized hardening list. Ranking remediations the same way gives a prioritized fix list that reflects actual risk reduction, not CVSS: a few high-impact changes, not long lists of low-impact ones.

The Take

Project Glasswing is both good news and bad news for the software the world depends on. Good, because a well-resourced partner consortium is now systematically looking for bugs that human review missed for decades. Bad, because the same capability is available to less well-meaning parties at commodity cost, and the window between a vulnerability existing and a vulnerability being exploited has collapsed to something shorter than most organizations can patch.

Regardless of how many CVEs Glasswing publishes, and regardless of whether those CVEs reach your fleet before attackers do, the defensive posture is the same: assume compromise will outrun patching, and design the cloud so that compromise does not expand. The graph of identities, resources, and trust edges is the surface on which that design happens. It is not only a visualization. It is your control plane.

PanIAM computes that graph for cloud accounts, ranks entry points by blast radius, ranks remediations by risk reduction, and answers the “if this is compromised, what is reachable” question as a query rather than a project. If you want to see what your own cloud graph looks like before the next Glasswing disclosure hits the newswire, get secure now.