Security is becoming an epidemiology problem

2026-04-11 · Matt Horn

An AI lab has announced Mythos, a model it is not releasing publicly. On the lab’s own accounting, Mythos discovers and exploits multi-step vulnerability chains across most major operating systems, browsers, and widely used infrastructure software. Each chain strings several separate flaws together, none enough on its own, and some of the flaws Mythos found had gone unnoticed for 27 years. More than 50 organizations¹ are working through the findings, and Jerome Powell and Treasury Secretary Scott Bessent met with bank CEOs this week to discuss the implications.

If you have more patches queued than you can apply, you need a way to choose which to take first. Epidemiologists have something like one, and I tried to borrow it. It doesn’t transfer cleanly to software, but I got a rule out of the attempt: rank each flaw by how many known exploit chains need it, patch from the top of the list, and report your coverage as the fraction of known chains missing a link. I don’t know whether that coverage would hold against an attacker who re-targets.

A lab can do two things with a capability like Mythos. If it released the model openly, it would hand attackers a working toolkit against infrastructure most of the internet runs on. Routing the same capability to the vendors and maintainers who can ship a patch is closer to an inoculation: a measured exposure, given to the party able to respond to it.

We’ve borrowed medicine’s vocabulary for a long time. Consumers call self-replicating malware a “virus,” many strains are polymorphic and rewrite their own code on the fly to evade detection, and we quarantine a compromised machine. We never borrowed the arithmetic. Zero-days turn up constantly in the software everyone depends on, and staying current takes a continuous drip of patches at every level of the stack. Miss them and your machine is exposed to exploits that are already public and packaged.

Physical isolation used to bound the blast radius of a compromise. Almost every significant financial transaction now happens digitally, in traditional banking and in cryptocurrency alike, so it no longer matters where the attacker is. And increasingly, whoever holds the right credentials controls the organization, or the government office.

Attackers now adapt faster than the software they attack. Exposing software to attack in careful measure does harden it, though calling the result immunity is a stretch. The software didn’t learn anything on its own; a human still had to read a report and ship a patch.

One risk is that an organization with different release incentives ships an equivalent capability without access controls. A harder problem is deciding what to patch first. There is always more patching queued than teams can do, and it’s hard to say which fix buys the most.

Epidemiologists have a version of that answer, and it depends on an assumption that matters here. If a population mixes at random, then once some fraction of it is immunized, each infected person passes the infection on to fewer than one other person on average, and transmission dies out on its own. That fraction is the herd immunity threshold.

Software doesn’t map onto this cleanly. It doesn’t come in well-defined individuals the way animals do, and a patched server mainly protects itself. At the host level, that breaks the analogy, because herd immunity works only through indirect protection: the immunized shield everyone who isn’t.

Patching OpenSSL upstream is not indirect protection. An unpatched server is just as exploitable no matter how many of its peers updated. Log4Shell is the example: servers went on running the vulnerable version for years after the Log4j logging library was fixed. Only the fix moves through the dependency graph. The upstream maintainers manufacture the dose, and every downstream project still has to take it.

The question is still worth asking if you change the unit. We have been counting flaws, but most of these attacks chain several flaws together, so a defender’s unit of work has always been the chain. Do the arithmetic over the links that chains reuse: rank the links by how many chains need them and patch from the top of that list. Then you can state your coverage as the fraction of known chains missing a link.

That is a different rule from patching the most popular library, which is what dependency scoring does. It is close to what attack-graph analysis has done since the late nineties; an attack graph maps the routes an attacker could take through a network by chaining its flaws. It is also adjacent to two current methods: EPSS, the Exploit Prediction Scoring System, which ranks what is being exploited, and reachability analysis, which ranks what is actually callable from an application’s own code.

My guess is that the recurring links are primitives, the reusable building blocks a chain needs, like a sandbox escape. Popularity is a poor proxy for that. Close one primitive and the attacker has to find another for every chain that needed it, which is a real cost to them and a temporary one. A corpus of real chains would settle it. Corpora do exist, in CISA’s exploited-vulnerabilities catalogue, Project Zero’s in-the-wild tracker, and the Pwn2Own writeups, though they are incident records, assembled after the fact and skewed toward the chains that got caught.

That makes the threshold question the one worth answering, and it’s the one I can’t answer alone. A pathogen only diffuses, whereas an attacker re-targets, and that undermines the threshold itself: close a primitive, the attacker substitutes another, and whatever coverage you bought decays. I don’t know how much of the epidemiological arithmetic survives that, or what to hand you as the host, the transmission event, or the infectious period. If you model infectious disease for a living and have an hour and an opinion, I’m at matt [at] matthorn [dot] io.

All posts · Home