Vulnerability Chaining: Real-World Examples and Defense Strategies

Security teams spend most of their time looking at vulnerabilities in isolation. Scanner finds a CVE, analyst checks the CVSS score, team triages based on severity. But attackers do not think in isolated CVEs. They think in chains -- sequences of vulnerabilities that, individually, might be unremarkable but together produce an effect far more severe than any single bug.

Understanding vulnerability chaining is essential for realistic risk assessment. A "medium" severity information disclosure combined with a "low" severity authentication bypass can produce a chain that is functionally critical. If your triage process looks at each component independently, you will miss these combinations every time.

Anatomy of a Vulnerability Chain

A typical chain follows a pattern:

1. Initial access: A vulnerability that gives the attacker a foothold. This could be an SSRF, an information disclosure, or a low-privilege authentication bypass.
2. Privilege escalation: A second vulnerability that elevates the attacker's access. Path traversals, insecure deserialization, or authorization flaws.
3. Impact delivery: The final vulnerability that achieves the attacker's objective. Remote code execution, data exfiltration, or lateral movement.

Each link in the chain may have a modest CVSS score on its own. But the chain itself can be catastrophic.

Real-World Example: ProxyLogon and ProxyShell (Microsoft Exchange)

The ProxyLogon and ProxyShell attacks against Microsoft Exchange Server in 2021 are textbook examples of vulnerability chaining.

ProxyLogon combined two vulnerabilities:

• CVE-2021-26855 (CVSS 9.1): A server-side request forgery (SSRF) in the Exchange Client Access Service. This allowed an unauthenticated attacker to send arbitrary HTTP requests as the Exchange server.
• CVE-2021-27065 (CVSS 7.8): A post-authentication arbitrary file write vulnerability. By itself, this required authentication. But chained with the SSRF, the attacker could use the forged requests to authenticate and then write a web shell to the server.

The SSRF alone was serious but limited in impact. The file write required authentication. Together, they gave unauthenticated remote code execution on any internet-facing Exchange server.

ProxyShell was discovered shortly after and chained three vulnerabilities:

• CVE-2021-34473: A pre-auth path confusion leading to arbitrary backend URL access
• CVE-2021-34523: A privilege escalation via Exchange PowerShell backend
• CVE-2021-31207: An arbitrary file write via mailbox export

Each vulnerability in the ProxyShell chain was individually less dramatic than ProxyLogon, but the combination was equally devastating. Attackers used it to deploy ransomware, cryptominers, and persistent backdoors across thousands of organizations.

Real-World Example: Apache OGNL Injection Chains

The Apache Struts vulnerability CVE-2017-5638 (the Equifax breach vulnerability) was a single critical RCE bug. But the broader Apache ecosystem has seen numerous chains where OGNL injection vulnerabilities were combined with other weaknesses.

In Apache Struts 2, multiple OGNL injection points were discovered over the years. Attackers frequently chained them:

1. First, use an information disclosure OGNL injection to enumerate the application's internal structure and class paths
2. Then use a more restricted OGNL injection point to bypass sandbox restrictions that Apache added after earlier vulnerabilities
3. Finally, use the escaped sandbox to execute arbitrary system commands

Each bypass added by Apache became a new link that attackers had to chain through, but the fundamental OGNL evaluation surface remained exploitable. This pattern demonstrates how chains evolve -- defenders add mitigations, attackers find ways to chain around them.

Real-World Example: Citrix ADC (CVE-2023-3519)

The Citrix NetScaler ADC vulnerability exploited in mid-2023 involved chaining:

• A memory corruption vulnerability in the NSPPE process
• An information leak that provided the memory layout needed to bypass ASLR
• A stack-based buffer overflow for code execution

Without the information leak providing ASLR bypass, the buffer overflow alone would have been largely unexploitable on modern systems. The chain made it reliable enough for mass exploitation, and it was actively used by threat actors, including state-sponsored groups.

Why Traditional Vulnerability Management Misses Chains

The fundamental problem is that vulnerability scanners and databases treat each CVE as an independent entity. CVSS scores are calculated per-vulnerability. Triage workflows process each finding individually.

This creates several blind spots:

Severity underestimation. When two medium-severity bugs combine into a critical chain, neither one triggers your "patch immediately" policy on its own. Both sit in the remediation queue at normal priority while the actual risk is much higher.

Incomplete asset context. A chain often spans multiple components. The SSRF is in the web server, the privilege escalation is in the application framework, and the file write is in a third component. If different teams own each component, no one sees the full chain.

Temporal gaps. The vulnerabilities in a chain may be disclosed weeks or months apart. By the time the second link is published, the first has been triaged, assessed as moderate, and deprioritized. No one goes back to reassess the first vulnerability in light of the second.

Building Chain-Aware Defenses

Attack Path Modeling

Instead of assessing vulnerabilities individually, map potential attack paths through your infrastructure. An attack path model asks: "Given these known vulnerabilities, what sequences could an attacker use to move from the internet to our crown jewels?"

This requires correlating vulnerability data with network topology, authentication boundaries, and asset criticality. It is more complex than simple CVSS-based triage, but it produces dramatically more accurate risk assessments.

Dependency Chain Analysis

In the software supply chain context, dependency chains are a key area of concern. A vulnerability in a transitive dependency three levels deep might be reachable from the application's entry point through a chain of function calls. Reachability analysis -- determining whether the vulnerable code path is actually invoked -- is the dependency equivalent of attack path modeling.

Defense in Depth Assessment

For each vulnerability, ask: "What other controls would an attacker need to bypass to exploit this?" If a vulnerability is behind authentication, behind a network boundary, and requires a specific configuration, the effective risk is lower even if the CVSS score is high. But if those other controls have their own weaknesses, the chain risk increases.

Cross-Team Correlation

Break down the silos between infrastructure security, application security, and platform security teams. A chain that spans multiple domains will only be visible to a team that has visibility across all of them.

Continuous Reassessment

When a new vulnerability is disclosed, do not just assess it in isolation. Check whether it creates a new chain with existing vulnerabilities in your environment. This requires maintaining a current inventory of all known (and accepted) vulnerabilities and running chain analysis against new disclosures.

Quantifying Chain Risk

One practical approach to quantifying chain risk is to calculate the combined probability of exploitation. If Vulnerability A has an EPSS score of 0.15 and Vulnerability B has an EPSS score of 0.20, and they are independently exploitable, the combined chain probability is lower than either individual score (because the attacker needs both to succeed). But if one exploit enables the other, the probabilities are not independent, and the chain probability can be higher than the individual scores suggest.

This is an area where the vulnerability management industry still lacks mature tooling. Most organizations handle chain analysis manually or not at all. But the attackers are doing it every day.

How Safeguard.sh Helps

Safeguard.sh correlates vulnerabilities across your entire software inventory, not in isolation but in context. By maintaining a comprehensive view of all components across your applications through SBOM data, Safeguard.sh can identify when multiple vulnerabilities affect the same application stack and flag potential chain risks.

The reachability analysis feature identifies whether vulnerable code paths are actually invoked by your application, which is critical for assessing chain viability. When combined with EPSS scoring and KEV data, this gives your team a realistic picture of exploitation risk that accounts for how vulnerabilities interact, not just how they score individually.