Vulnerability Chaining, the New Attack Vector

Your vulnerability dashboard is green. Every open finding on your Linux fleet is rated medium or below. Nothing breaches an SLA. Nothing gets escalated.

An AI model looks at the same findings and sees a path to root.

This chapter explains how that happens, why the scoring systems most programs run on cannot see it, and what to change.

What Chaining Is

Vulnerability chaining means composing several individually limited flaws into one attack path with far greater impact than any single link.

It is not new. Top exploit developers have built chains for decades, and every serious browser or mobile exploit you have read about is a chain. What changed in 2026 is who can build them and how fast. Anthropic's red team described Mythos Preview autonomously chaining multiple Linux kernel vulnerabilities into local privilege escalation, and writing a browser exploit that linked four separate flaws to escape both the renderer sandbox and the operating system sandbox.

The capability underneath is specific: reasoning about how the output of exploiting one bug becomes the input needed to exploit the next. That is a reasoning problem, and reasoning is what improved.

Anatomy of a Chain

Modern systems stack defenses. To get from "I can send this process some input" to "I control the machine," an attacker usually has to beat several of them in sequence. Each stage needs a different primitive, and each primitive often comes from a different bug.

The walk-through below is a generalized privilege escalation chain of the type Anthropic described. The scores are illustrative, but the structure is how real chains work.

Stage 1: The information leak. Address Space Layout Randomization (ASLR), and its kernel equivalent KASLR, place code and data at unpredictable addresses so an attacker cannot aim. A small out-of-bounds read that returns a few bytes of adjacent memory looks harmless: no crash, no write, no data corruption. Scanners rate it medium. But those bytes often contain pointers, and pointers reveal where everything else lives. ASLR is now defeated.

Stage 2: The write primitive. Next the attacker needs to change memory they should not be able to touch. A race condition, two threads touching the same object without proper locking, can open a narrow window where freed memory is reused or a length field is modified mid-operation. Humans find these hard to exploit reliably because the timing is fiddly. A model can reason about the window, construct a trigger, and retry until it lands. Alone, it is medium again: the window is small and the attacker does not know where to aim.

Stage 3: Aim and fire. Combine stages 1 and 2. The leak says where a sensitive structure lives. The race lets the attacker overwrite it. Redirect a function pointer, flip a credentials field, or corrupt a security check.

Stage 4: The objective. Kernel-level code execution or credential change means root. From there it is persistence, data access and lateral movement.

Link	Example flaw	Typical standalone rating	Role in chain
1	Out-of-bounds read	Medium (CVSS ~4)	Defeats address randomization
2	Race condition	Medium (CVSS ~5)	Provides a memory write
3	Missing check on a privileged path	Medium (CVSS ~4.5)	Turns the write into control
Chain	All three together	Critical (effective ~9.8)	Full privilege escalation

Three findings on three tickets with three 60 to 90 day SLAs. One critical compromise.

The Browser Case

Browsers are the clearest case because they are built as layered prisons. Web content runs in a renderer process with few privileges. The renderer sits inside an operating system sandbox. Escaping to the real system means breaking out of both.

Anthropic's description of the Mythos browser work outlines the canonical structure: a chain of four vulnerabilities, including a JIT heap spray, that escaped both the renderer sandbox and the OS sandbox. In general terms, chains like this follow a recognizable pattern:

1. A JIT or type confusion bug lets crafted JavaScript make the engine treat one kind of object as another, producing fake objects with attacker-controlled internals.
2. Heap shaping arranges memory so those fake objects overlap with something useful.
3. Arbitrary read and write inside the renderer follows, which gives the attacker control of the content process.
4. A flaw in a more privileged component, often in how it handles messages from the renderer, carries the attacker out of the sandbox.

Each step alone is constrained by the next layer of defense. Together, they turn a malicious web page into full compromise. The 181 working Firefox exploits Anthropic reported, against two from the previous model, show how much better models became at assembling these pieces.

For background on how browser security architecture creates these layers, see my browser security analysis.

Why CVSS Breaks Under Composition

The Common Vulnerability Scoring System rates vulnerabilities one at a time. Attack vector, complexity, privileges required, user interaction, scope, impact: all evaluated for a single flaw in isolation. There is no input for "and there is also a race condition three functions away."

That design was reasonable when chaining was rare and expensive. It is not reasonable when chaining is cheap.

The consequences show up in four places:

• SLAs. Remediation deadlines are keyed to individual severity, so chain links sit in long queues.
• Dashboards. Leadership sees counts by severity. A cluster of mediums on one critical system looks like moderate risk.
• Exceptions. Medium findings are the easiest to defer with a risk acceptance, and nobody re-reviews the acceptance when a neighboring bug appears.
• Board reporting. "No open criticals" becomes a statement about scoring, not about exposure.

I find it useful to describe residual risk to leadership in three tiers:

1. Known knowns: vulnerability classes your tools detect reliably and you remediate on schedule.
2. Known unknowns: classes your tools cover partially, such as logic bugs in custom code.
3. Compositional risk: paths built from several individually acceptable findings. This is where AI-driven attackers will look first, and where most programs have no visibility.

Why Existing Tools Do Not See Chains

Each standard tool category is blind to composition for a structural reason, not a tuning problem.

• SAST analyzes functions and data flows against rules. It can flag two separate weaknesses but has no model of whether exploiting one supplies a primitive for the other.
• Fuzzers optimize for observable failures. Leaks and races often produce no crash at all, so the most useful chain links are the ones fuzzers rank lowest.
• SCA reports known CVEs per dependency. It does not know whether two dependency flaws combine, or whether either is reachable from your code.
• Infrastructure scanners list missing patches and misconfigurations independently. A permissive IAM role plus an unpatched service is two line items, not one path.

From Vulnerability Management to Attack Path Management

The fix is a change of question. Stop asking "how severe is this bug?" Start asking "what paths does this bug open, given everything else in this system?"

That shift needs three capabilities:

1. System-level correlation. Group findings by the asset, process and trust boundary they share, not by the tool that found them. A medium bug in a sandboxed utility and the same bug in a privileged authentication service are different risks.
2. Exploitability reasoning. For findings that share a boundary, determine whether one provides a primitive another needs: a leak plus a write, a weak permission plus a reachable service.
3. Path construction. Assemble plausible routes from entry points to crown jewels and rate the path, not the parts.

Practical steps that work without buying anything new:

• Start with five systems. Pick the assets whose compromise would hurt most, typically identity providers, payment systems, customer data stores, CI/CD and production cloud accounts.
• Merge the findings. Pull SAST, DAST, SCA, cloud posture and pentest results for those five into one view per asset.
• Run AI against your own findings. Ask a capable model, inside your own environment, to propose chains from the merged list. You are using the attacker's method on your own data.
• Fix the link that breaks the most paths. If one leak appears in four candidate chains, it is now your top priority regardless of its score.
• Report paths upward. Replace "open criticals" on the board slide with "known attack paths to critical assets, and days open."

Prioritizing by path also works in your favor. A chain is only as strong as its weakest link. You do not need to fix all four bugs to kill a four-link chain. You need to fix one, quickly.

Authentication Chains

Authentication infrastructure deserves its own section because of its blast radius. It sits where every trust boundary meets, and a chain that compromises it compromises everything downstream.

When I was building identity infrastructure at scale, the incidents that worried me most were never a single dramatic bug. They were combinations:

• Weak token randomness plus a timing leak in validation can let an attacker predict or forge session tokens.
• A session binding flaw plus an authorization check that reads the wrong attribute can let one user act as another.
• A partial API key comparison plus a rate limit that resets per IP can let an attacker enumerate valid keys.
• An open redirect plus loose OAuth redirect URI matching can leak authorization codes to an attacker-controlled site.

None of these links looks critical on its own. Every one of these combinations is now something a model can find by reading your code.

Modern authentication design removes whole classes of these chains. Phishing-resistant, public-key credentials leave far less for an attacker to forge or replay. My FIDO2 implementation guide covers how to build that layer correctly.

Key takeaways

• Chaining combines individually limited flaws into one high-impact path. AI made it fast and cheap.
• CVSS scores flaws one at a time, so chain links sit in long, low-priority queues.
• Standard tools are structurally blind to composition.
• Attack path management, starting with your five most important systems, is the practical fix.
• Fix the link that breaks the most paths, and report paths, not counts, to leadership.

Chaining makes each bug more dangerous. At the same time, the window between disclosure and exploitation is shrinking, while the queue of unfixed bugs is growing. Chapter 4 looks at that bottleneck with real data.