Attack Chaining: When Low-Severity Vulnerabilities Combine into High-Risk Attack Paths

Your backlog is full of low- and medium-severity vulnerabilities nobody is planning to fix. A profile page leaking information. A reset endpoint with no rate limit. A form missing a CSRF check. These are all medium-severity issues which are reasonable to defer in isolation. However, together they add up to a critical exploit. The leak reveals how reset tokens are built, the missing CSRF check delivers a reset request through the victim’s browser, and the missing rate limit buys unlimited guesses until one works.

Three medium-severity issues suddenly combine into a full account takeover.

This is attack chaining. And as AI-enabled attacks get better at identifying and linking long-ignored lower-severity issues into high-risk exploits, severity scoring one finding at a time leaves you blind to the risk that actually gets you breached.

Key Highlights

• Severity describes one vulnerability but does not account for the risk of multi-vulnerability paths, so three mediums can chain into a compromise without any link crossing the fix threshold.
• CISA and the FBI documented two real exploit chains against Ivanti Cloud Service Appliances in a joint advisory, assembled from four separate CVEs.
• Most links in an application environment are not CVEs but secrets, pipeline permissions, infrastructure defaults, and AI-generated code, each sitting in a different tool.
• Chain awareness has to remove work rather than add it, which is what Cycode’s Context Intelligence Graph, AI Exploitability Agent and Agentic Code Scanning are built to do.

What Is Attack Chaining?

Attack chaining is what happens when several individually lower-rated security findings combine into a working attack path, often with every link in that path staying below the severity threshold that would have triggered remediation. The completed route is critical by any reasonable definition, while no one of the findings that make it up would ever be described that way. Nothing in a conventional prioritization workflow is designed to notice the difference between those two facts.

The underlying pattern is not new, and offensive security teams have been assembling routes out of unremarkable findings for as long as the discipline has existed. What has changed is the sheer volume of findings now competing for a fixed amount of remediation capacity. What has also changed is how quickly an AI-equipped attacker can reason across application vulnerabilities to escalate a critical attack path.

Attack Chaining vs. Toxic Combinations

These two terms describe closely related problems and get used interchangeably in practice, which causes real confusion once a remediation conversation actually starts. The distinction is worth holding onto, because each term implies a different question and points toward a different fix. Treating them as interchangeable is how a chain ends up recorded as handled while every link in it stays exactly where it was.

A toxic combination is a fact about the current state of your environment, and a chain is a fact about attacker behavior within it. The difference decides what remediation actually looks like, because a combination asks which factor to strip from one asset while a chain asks which link to break along a route that crosses several. The second question is harder, since the answer rarely belongs to a single team.

Academic work suggests the blind spot is more widespread than most teams assume. An exploratory study on vulnerability chaining found that IT and security professionals had real difficulty identifying chained vulnerabilities at all, largely because prioritization and remediation workflows are not built to surface them. The researchers gave the problem a name, vulnerability chaining blindness, and it fairly describes most programs running today.

Why CVSS Severity Scores Miss Chained Attack Paths

CVSS misses chains because it was built to describe one vulnerability considered in isolation, and the specification contains no field for surrounding context. It cannot record what else runs on the same host, which service account sits nearby, or whether the finding two rows further down your queue happens to unlock this one. None of that context is missing by accident, because the score was only ever built to travel between organizations that share nothing but the vulnerability itself.

What a severity score actually measures

A CVSS base score describes the properties of a single flaw, covering how it is reached, how difficult it is to trigger, and what it does to the affected component. Those are legitimate questions, and the answers are genuinely useful for triage and for coordinated disclosure. The trouble begins when that number becomes the only input to a decision about what gets fixed first.

The score stops cleanly at the boundary of the affected component, and it was designed to do exactly that. Nothing in the specification asks what sits next to the vulnerable service or what that service can reach once somebody controls it. That surrounding information is precisely the material a chain gets built from.

• The base score is calculated once and then travels unchanged into every downstream ticket, dashboard, and report.
• Two findings carrying identical severity scores can produce completely different risk consequences in two different environments.
• The format has no way to represent a relationship between one finding and another.

Why risk scoring vulnerabilities in isolation does not close the gap

Risk-based triaging goes beyond CVSS and severity to weigh factors like business impact, exposure, exploitability, and threat intelligence. CISA’s Binding Operational Directive 26-04 replaces flat severity-driven remediation timelines with a four-variable model covering public exposure, known exploitation, exploit automation, and technical impact. FedRAMP has also published its own alignment response, and the approach will likely spread into commercial programs the way the Known Exploited Vulnerabilities catalog did.

This is a significant advance in vulnerability triaging, and it presents a real improvement over sorting a queue by a single technical severity number. However, most risk scores still evaluate one vulnerability at a time. It delivers smarter triaging of a single finding, but it does not evaluate the risk posed by adjacent vulnerabilities and attack chains. The scores do not elevate something that becomes serious only when combined with additional vulnerabilities.

• The strongest public prioritization framework available today still scores every vulnerability in isolation.
• Better questions about one finding cannot reveal a relationship between that finding and another.
• Complete risk assessments need to account for adjacent vulnerabilities and attack chains

Real-World Attack Chaining Example: The Ivanti CSA Advisory

In September 2024, attackers moved through Ivanti Cloud Service Appliances along two separate routes, and the CISA and FBI joint advisory published four months later documents both of them. One route paired an administrative bypass with two remote code execution flaws to reach code execution on the appliance. The other route paired that same administrative bypass with a SQL injection bug.

The bypass is the part worth noticing, because it appears in both routes and accomplishes very little on its own. Federal responders wrote the incident up as a chain for the straightforward reason that this is how it actually happened, which is what vulnerability chaining looks like once it leaves a pentest report. Most vulnerability management programs would have received the same four CVEs as four unrelated rows in a queue.

• The four exploited flaws were CVE-2024-8963, CVE-2024-8190, CVE-2024-9379, and CVE-2024-9380.
• CVE-2024-8963, the administrative bypass, served as the shared entry point for both chains.
• The first chain combined that bypass with CVE-2024-8190 and CVE-2024-9380, both remote code execution flaws.
• The second chain combined the same bypass with CVE-2024-9379, a SQL injection flaw.
• The result was initial access, remote code execution, credential theft, and web shells on victim networks, with lateral movement to two more servers in at least one confirmed compromise.

Where Attack Chaining Hides in the Software Development Lifecycle

Many chain links in an application environment are not CVEs, which is the detail that gets lost whenever this topic is treated purely as a vulnerability management problem. Mention chaining, and most people picture CVEs stacking up on a server, but inside a software factory, the CVEs are frequently the least interesting links available. Chains often start with leaked secrets, misconfigurations, and excessive permissions.

Hardcoded secrets and non-human identities

A leaked credential is the link that lets an attacker skip several steps at once rather than working through them individually. It converts a slow lateral path into a single hop, and it rarely carries a severity rating that reflects what it genuinely unlocks. Scanners tend to report the exposure itself rather than the blast radius sitting behind it.

Hardcoded secrets are also unusually durable compared with most other findings in your backlog. A key committed two years ago and never rotated is still a perfectly functional link today, long after the developer who added it changed teams or left the company. Detection alone does nothing to change that, because the credential remains valid until somebody actually rotates it.

• A valid credential bypasses every control that assumed an attacker would first have to escalate.
• Non-human identities routinely hold broader permissions than the humans who originally created them.
• Rotation rather than detection is what actually breaks this particular link in a chain.

CI/CD pipeline permissions

Pipelines are the highest-value link in most chains because they sit upstream of everything an organization ships. A build runner with broad access converts a small foothold into effective control over every artifact your customers eventually receive. Reaching the pipeline usually removes any need to attack the things downstream of it.

CI/CD misconfigurations rarely present themselves as vulnerabilities in the first place. They present as settings, which means they surface in a different console with no severity score attached for anyone to compare against. A finding with no score does not lose the argument about priority, because it never enters that argument at all.

• Service accounts frequently retain write access to repositories that nobody audits regularly.
• A compromised build runner can modify shipped artifacts without ever touching source code.
• Pipeline findings and application findings almost never arrive in the same queue.

Infrastructure as code defaults

Generated and copied infrastructure code inherits whatever insecure default happened to be most common across its source material. Public storage buckets, permissive IAM roles, and containers running as root are the results that turn up most often. Those patterns propagate quickly, because templates get reused considerably more often than they get reviewed.

Each of those findings reads as a low or medium posture issue when it is assessed on its own terms. Each is also a step that meaningfully shortens somebody’s path toward the data you care most about protecting. The gap between those two readings is where chains quietly survive quarter after quarter.

• A single permissive role can connect two environments that were deliberately meant to stay separate.
• Containers running as root remove the isolation that would have made an application flaw survivable.
• Misconfigurations persist for years because nothing about their behavior ever appears broken.

AI-generated code and its dependencies

Volume is a larger problem here than quality, although both deserve attention. Roughly 40% of AI-generated programs in one academic sample contained an exploitable flaw, and hallucinated package names have become a supply chain attack technique in their own right. Both of those problems scale with output rather than with headcount.

Cycode’s 2026 State of Product Security research found that every surveyed organization already has AI-generated code somewhere in its codebase. Only 19% of those organizations report full visibility into where and how AI is being used across their development environment. More links are entering the environment faster, in places where nobody is currently watching.

• Generated code reproduces insecure patterns at whatever speed developers accept the suggestions.
• Invented package names hand attackers a predictable target they can register in advance.
• Review capacity has not grown anywhere near the rate at which code volume has.

What a complete chain looks like end to end

Consider a path along which no scanner flags anything as critical at any point. An internal endpoint sits documented in an old README and is marked informational, while a service elsewhere accepts a URL parameter and fetches it, rated medium. A container in the same environment runs as root and is rated medium-severity.

The CI service account has write access to the production repository, which is a configuration reality rather than a finding that appears anywhere in a queue. None of that trips a remediation threshold at any stage of the process. Taken together, it forms a route from a public application all the way to the artifact that ships to customers.

• Four findings, four separate tools, and four owners who have never been in a meeting together.
• Every link sits comfortably below the line at which remediation work actually gets funded.
• The end of the path is the software your customers download and install themselves.

How AI Is Making Vulnerability Chaining Cheaper and Faster

Chaining has always required expensive expert time, and that cost was the defender’s real protection even if nobody ever stated it that plainly. An attacker had to want your specific environment badly enough to pay a specialist to study it properly. Anything less valuable than that simply did not justify the effort involved.

That protection is thinning quickly, and the evidence is now public rather than speculative. When Anthropic previewed its Mythos model, one documented result was a browser exploit that chained four separate vulnerabilities to escape both the renderer and the operating system sandbox, produced without expert human guidance. The associated defensive coalition has since reported more than 10,000 high- and critical-severity flaws found across widely used software.

Two things follow from that. First, AI floods the backlog as vulnerability detection further outpaces remediation capacity, meaning more issues get deferred. At the same time, reasoning across a large number of findings to construct a viable exploit path has become genuinely cheap. The backlog grows and buries attack chains security teams miss and attackers target.

How to Build a Chain-Aware Prioritization Program in 5 Steps

A chain-aware program correlates findings before scoring them, adds environmental context, validates exploitability, remediates at choke points, and assigns ownership for the route rather than for the individual links. The five steps below are presented in order because each one depends on the one before it. None of them require replacing the tooling you already run, only changing what happens to the findings once they arrive.

1. Consolidate duplicate findings across scanners before scoring them

A static analysis result, a container finding, and a runtime alert that all trace back to the same service should arrive as a single item with a single owner. Three separate tickets sitting in three separate queues guarantee that nobody ever sees the shape of the underlying problem. This is consolidation rather than chaining, since it collapses several reports of the same weakness instead of linking different ones together.

This is a data problem well before it becomes a security problem. If your tools cannot resolve findings to a shared identity for each asset, no amount of analyst effort downstream will reliably collapse the duplicates. Everything else on this list depends on getting that foundation right first.

• Resolve every incoming finding to a single canonical asset identity before anything else happens.
• Deduplicate across scanners before you rank the results rather than afterwards.
• Keep duplicate findings and adjacent findings apart, because only the second kind forms a chain.
• Treat ownership as a property of the asset itself rather than of the individual ticket.

2. Add exposure and runtime context to every finding

Whether code is actually deployed, whether it is reachable from the internet, and what privileges it holds will change the meaning of an identical vulnerability by an order of magnitude. A critical sitting in a dormant branch and a medium running in a production payment service are not remotely comparable problems. The published score cannot distinguish between them, but your own environment certainly can.

Context works in both directions, which is the part teams routinely forget when they build these programs. Confirming that something is genuinely unreachable is how you justify deferring it to an auditor without a lengthy argument. That evidence has to be captured at the time, because reconstructing it afterwards is far more expensive.

• Record deployment status on every finding as a first-class field rather than a comment.
• Track what each affected service can reach, not merely what happens to run on it.
• Preserve the evidence behind every deferral decision, because somebody will eventually ask for it.

3. Prove exploitability instead of inferring it

Attributes can only suggest that a finding might be exploitable, whereas validation establishes that it actually is. That distinction determines whether a given path deserves engineering time or belongs in a backlog. It is also the difference between a defensible decision and a reasonably educated guess.

Without validation, chain analysis simply becomes a second theoretical queue stacked on top of the first one. Teams respond to that by losing confidence in both queues at roughly the same rate. The remedy is proof rather than progressively more sophisticated inference.

• Validate the complete path rather than confirming the presence of each individual link.
• Retest after remediation to confirm that the route in question has genuinely closed.
• Record what was proven, so the decision survives staff turnover and later audit questions.

4. Identify adjacent vulnerabilities that form attack chains, then remediate at choke points

Start by looking for findings that sit next to each other on the same route, where one weakness hands an attacker whatever the next one requires. Those adjacencies are what turn a set of unremarkable findings into a path worth walking, and they only become visible once findings carry ownership, reachability, and privilege alongside their scores. Ask which single change breaks the largest number of routes, and then prioritize that change first. The answer is frequently a finding carrying a lower severity rating that sits well below three criticals in the same queue. Ranking by path elimination rather than by severity is what makes the difference here. A chain holds only while every link holds, so the cheapest link to break is worth more than the highest score in the queue.

Cycode’s Agentic Code Scanning links related findings into a single multi-step path, grounded in the Context Intelligence Graph’s call relationships, ownership, and reachability, so the choke point to break becomes visible.

This step requires organizational cover before it can work in practice. Somebody senior enough has to be able to defend fixing a medium ahead of a critical when the question inevitably comes up. Agreeing that logic with audit and compliance in advance is considerably easier than defending it afterwards.

• Map which findings are adjacent on a route before deciding what to fix.
• Rank candidate fixes by how many exploitable risks they eliminate rather than by severity score.
• Anticipate that high-value fixes may look low-priority by severity but address critical exploitabilities.
• Agree the deferral logic with your audit function before you actually need to rely on it.

5. Give every chain a named owner

A path crossing application code, pipeline configuration, and cloud identity has no natural owner on most organizational charts. That absence is the real reason chains survive audits and reappear in the following year’s pentest report. The owner should be whoever owns the outcome sitting at the end of the path.

That person will not personally fix every link in the chain, and nobody should expect them to. Their actual job is to convene the owners of each link and make the trade-off call about which one gets broken. Most organizations already run precisely this pattern for incidents without ever having applied it to proactive findings.

• Assign ownership to the outcome at the end of the path rather than to individual findings.
• Give that owner genuine authority to sequence work across team and departmental boundaries.
• Reuse the escalation path your organization already runs for incident response.

Prevent Attack Chaining with Cycode

Cycode was built around a single graph rather than a collection of scanners that report their results separately, which matters here for one specific reason. You cannot reason about a chain when the links live in tools that never exchange information with each other. Correlation and identification of adjacent vulnerabilities has to be a property of the platform rather than a task assigned to an analyst.

The platform correlates findings across the software development lifecycle, validates which paths an attacker could exploit, and routes each resulting fix to whoever owns it. That converts a long list of unrelated low-severity rows into a much shorter list of decisions somebody can actually defend. The reasoning behind each decision gets recorded at the time rather than reconstructed later.

• Agentic Code Scanning catches the chain links rule engines structurally cannot express, such as missing authorization checks, and runs a synthesis pass that assembles related findings into a single validated path rather than a set of unconnected rows.
• The Context Intelligence Graph connects code, dependencies, pipelines, cloud infrastructure, identities, and ownership into one queryable model.
• Native scanning across SAST, SCA, secrets, IaC, and containers, plus more than 100 third-party connectors, so every link in a chain lands in the same place.
• The AI Exploitability Agent validates whether a weakness is actually reachable and exploitable, which separates proven paths from theoretical ones.
• Maestro orchestrates the agents that assess exposure, generate fixes, and open pull requests, with the reasoning recorded for later.
• Code-to-runtime tracing and ownership mapping, so a container finding resolves back to its root cause in code and forward to what it can reach in production.

None of this removes the need for human judgment about what your particular business can tolerate. What it removes is the excuse that the data needed to make that judgment was scattered across nine different consoles. Book a demo to see how Cycode separates the paths that matter from the ones that lead nowhere.