This educational lab demonstrates how three individually medium-severity web vulnerabilities—stored XSS, CSRF token bypass, and file upload validation bypass—combine into a Critical-severity attack chain that achieves automatic remote code execution on a DVWA server. The article argues that real-world application attacks operate through vulnerability chains rather than isolated exploits, and teaches practitioners to identify, execute, document, and report chained vulnerabilities rather than individual findings. Understanding vulnerability chaining is essential for accurate security assessment and significantly impacts bug bounty payouts.
- Vulnerability chaining removes sequential obstaclesEach vulnerability in the chain solves a specific problem blocking the attacker's progress. Stored XSS solves the lack of code execution within authenticated sessions; same-domain XSS execution solves CSRF token unavailability; file upload bypass solves file type validation; and the complete chain solves the requirement for server-level code execution without direct server exploitation. The chain's power comes from this logical progression where each step enables the next.
- Stored XSS serves as automated delivery mechanismThe attack payload is injected into the DVWA guestbook via stored XSS by expanding the textarea maxlength attribute in DevTools from 50 to 2000 characters, then storing JavaScript that executes automatically whenever any authenticated user loads the guestbook page. The payload requires no additional user interaction beyond normal page viewing, making it completely automated and affecting every user who accesses the guestbook post-injection.
- XSS extracts CSRF tokens via same-domain fetchThe XSS payload uses the Fetch API to request the file upload page from within the victim's authenticated browser session. Because XSS code executes on the same domain with the victim's existing authentication cookies, the response body is fully readable despite CSRF token being a hidden form field. A regex match extracts the token value from the HTML: `html.match(/user_token.*?value='([^']+)'/)`, completely bypassing CSRF protection through same-origin execution privileges.
- Forged upload bypasses MIME type validationThe XSS constructs a multipart/form-data POST request using FormData and the Fetch API, exactly mimicking what a browser would send during a legitimate upload. The File constructor's type parameter sets MIME type to 'image/jpeg' while the actual content is PHP code: `new File([''], 'shell.php', {type:'image/jpeg'})`. DVWA's Low security setting only validates the Content-Type header, which is attacker-controlled in FormData, allowing PHP code to pass validation designed for images.
- Webshell enables OS-level command executionThe uploaded PHP file contains a single-line command shell: ``. Once accessible at the predictable upload path `/dvwa/hackable/uploads/shell.php`, it accepts commands via URL parameters like `?cmd=id` and executes them using PHP's system() function with web server privileges (www-data on Linux). This grants immediate access to file system operations and configuration files containing database credentials.
- Chain severity exceeds individual component ratingsThe article demonstrates that three independently Medium-to-High severity vulnerabilities combine to produce a Critical finding. A standalone stored XSS might be rated Medium, CSRF bypass High, and file upload bypass High—but the chain's terminal impact is server-level RCE with automatic deployment. Bug bounty payouts reflect this: the same stored XSS pays approximately $300 alone but $10,000+ when chained to RCE, making chain identification a primary income differentiator for researchers.
- Fixing one chain link leaves rebuilding pathway openIf only the stored XSS is patched with output encoding, the CSRF bypass and file upload bypass vulnerabilities remain. Any future XSS discovered anywhere on the same domain—reflected XSS in search parameters, DOM-based XSS in third-party scripts, or any new stored XSS—can immediately chain with the still-present file upload vulnerability to re-achieve RCE. Complete remediation requires fixing all three vulnerabilities simultaneously; the report must explicitly state that patching only one link is insufficient.
- Practical chain reporting prioritizes terminal impactThe article prescribes reporting vulnerability chains as single findings with the terminal severity (Critical in this case) rather than three separate Medium/High reports. The title should name the outcome: 'Stored XSS chains with CSRF token bypass and file upload bypass to achieve Remote Code Execution.' Remediation sections must address all three vulnerabilities and explicitly explain why fixing only one leaves the attack pathway rebuildable, fundamentally different from reporting isolated vulnerabilities.
Bottom line: Vulnerability chaining transforms medium-severity individual findings into critical-impact attack sequences by logically connecting each vulnerability to solve the obstacle blocking the next step; practitioners must identify, execute, and report chains as unified findings rather than isolated vulnerabilities to accurately reflect real-world attack impact and maximize bug bounty outcomes. Complete remediation requires fixing all chain links simultaneously, as patching only one leaves the pathway
FREE
Part of the DVWA Lab Series — 30 Labs
In a real engagement, XSS isn’t the finding — it’s the step that enables CSRF token theft, which enables the account takeover, which enables the admin file upload, which enables remote code execution. The individual vulnerabilities are links. The chain is the attack.
DVWA Vulnerability Chaining Lab 22 is where everything you learned in Labs 1 through 21 connects. I’m walking you through a four-stage attack chain against DVWA where each stage uses the result of the previous one: XSS cookie theft → session hijack → CSRF → authenticated file upload → RCE. Run through this once and you’ll never look at a single vulnerability in isolation again.
🎯 What You’ll Master in Lab 22
⏱️ 60 min lab · 3 terminal exercises · Localhost DVWA only
📋 Prerequisites — Complete Before Lab 22
- Lab 19: XSS Cookie Theft — same-domain XSS execution that enables CSRF token extraction
- Lab 20: CSRF Advanced — CSRF token bypass via XSS; Lab 22 extends this to file upload
- Lab 21: SQL Injection High Security — multi-vector attack thinking applied to chaining
- Lab 6: File Upload Lab — PHP webshell upload technique used in the final chain step
📋 DVWA Vulnerability Chaining Lab 2026
The Three-Vulnerability Chain Architecture
I want to reframe how you think about vulnerability chaining before we touch the keyboard. It’s not about clever combinations — it’s about following the logical consequence of each vulnerability to its next step. In this chain, each vulnerability removes one specific obstacle between the attacker’s initial foothold and the final objective of server-level code execution.
Problem 1: The attacker wants to upload a PHP webshell to the server. DVWA’s file upload endpoint requires an authenticated session and a valid CSRF token. The attacker cannot directly forge a valid upload request because they don’t have the CSRF token. XSS solves this: by injecting JavaScript into the stored XSS guestbook, the attacker runs code within the victim’s authenticated browser session on the same domain — code that can read the CSRF token from any page on the same domain.
Problem 2: Even with the CSRF token, the file upload endpoint validates that only image files are accepted. Raw PHP shell scripts are rejected. File upload bypass solves this: changing the Content-Type header, using double extensions, or embedding PHP code in a file with an image extension bypasses client-side and basic server-side validation.
Problem 3: The attacker wants this to happen automatically without the victim taking any action beyond loading a page. Stored XSS solves this: a payload stored in the guestbook fires automatically for every authenticated user who views it — no user interaction required beyond page load.
Attacker injects XSS payload into guestbook — stored, fires on every pageview
Authenticated admin views guestbook → XSS JavaScript runs in their browser
XSS fetch() reads CSRF token from file upload page (same domain, allowed)
XSS uses token to forge multipart POST — uploads shell.php disguised as shell.php.jpg
Attacker accesses /uploads/shell.php → remote code execution on the server
Step 1 — Stored XSS as the Delivery Mechanism
The chain starts with the stored XSS guestbook vulnerability from Lab 19. The key technique is identical: use browser DevTools to expand the maxlength attribute on the message textarea from 50 to 500 characters, then inject the full attack JavaScript payload into the message field. The payload will fire for every authenticated user who loads the guestbook page after the injection.
For the chaining lab, the stored XSS serves as the delivery mechanism rather than the primary attack itself. The payload is significantly longer than in Lab 19 because it needs to perform multiple sequential operations: fetch the upload page to get the CSRF token, parse the token from the HTML response, construct a multipart form data upload request with the PHP webshell content, and submit the forged upload request using the stolen token.
Step 2 — CSRF Token Extraction and Forged File Upload
The CSRF token extraction technique is identical to Lab 20: same-domain XSS makes a fetch request to the file upload page, reads the response HTML, and parses the hidden user_token value using a regex. Because the XSS executes within the victim’s authenticated browser session, the fetch request is same-origin and the response body is fully readable — the CSRF protection is completely bypassed by the same-domain code execution that XSS provides.
The forged file upload uses the Fetch API with FormData to construct a multipart/form-data POST request identical to what the browser would generate if the victim manually submitted the upload form — but with the attacker’s PHP webshell as the file content. The DVWA Low security file upload performs only a basic check on the uploaded file’s Content-Type header (which is attacker-controlled in the FormData) rather than examining the file’s actual content. Setting the file’s MIME type to image/jpeg in the FormData File constructor satisfies this check while the actual content is PHP code.
⏱️ 20 minutes · Kali + DVWA security=LOW + Burp Proxy
📸 Screenshot the RCE output (uid=www-data) and the CSRF token alert. Post to #lab-22-chaining on Discord.
Step 3 — Webshell Deployment and RCE Confirmation
The PHP webshell used in this chain is a single-line command execution shell: <?php system($_GET["cmd"]); ?>. Once uploaded, it accepts commands via the cmd URL parameter and executes them using PHP’s system() function, returning the output in the HTTP response. The webshell runs with the privileges of the web server process — typically www-data on Linux systems — which is sufficient to read web application source code, access database credentials from configuration files, and potentially escalate further if other vulnerabilities exist.
The upload path in DVWA is predictable: files are placed in /dvwa/hackable/uploads/ with their original filename. The webshell stored as shell.php is immediately accessible at http://localhost/dvwa/hackable/uploads/shell.php. For the full automated chain, the XSS payload doesn’t need to notify the attacker of the upload path — it’s a known location. The attacker simply checks the uploads directory after the guestbook page has been viewed by an authenticated user.
The Automated Full Chain — One Payload, Complete Compromise
The complete automated chain combines all three vulnerabilities into a single stored XSS guestbook entry. When any authenticated DVWA user loads the guestbook page, the payload fires automatically: it fetches the upload page, extracts the CSRF token, constructs the multipart webshell upload, and submits it — all within the user’s authenticated session, all in background JavaScript, with no visible indication to the user that anything happened beyond the guestbook page loading normally.
⏱️ 25 minutes · Kali + DVWA security=LOW · F12 DevTools
📸 Screenshot the RCE output and config file read. Post to #lab-22-chaining on Discord with tag #chainlabcomplete
Reporting Vulnerability Chains in Bug Bounty
Vulnerability chain reports require a different structure from single-vulnerability reports because the severity is a product of the chain, not any individual component. The report must communicate: the individual vulnerability chain steps and their individual severities, the combined attack sequence step by step with proof-of-concept evidence for each step, the final combined impact as the actual severity, and remediation requirements for every link in the chain.
The title should name the outcome: “Stored XSS chains with CSRF token bypass and file upload bypass to achieve Remote Code Execution on the web server.” The severity should reflect the terminal impact: if the chain ends in RCE on a production web server, that is Critical regardless of what the starting vulnerability’s individual severity would have been. Include explicitly in the remediation section that patching any one link is insufficient — all three vulnerabilities must be fixed to close the chain, and fixing only XSS while leaving file upload bypass means any future XSS restores the full chain.
⏱️ 15 minutes · Review your lab notes + write the report section
Write a one-line title that names the terminal impact:
“[Starting vulnerability] chains to [terminal impact] via [intermediate steps]”
Assign severity based on terminal impact: what is RCE on the web server?
Step 2: Attack chain summary (3-5 sentences)
Describe the complete chain in plain English.
A non-technical reader should understand:
– What the attacker injects and where
– What triggers automatically without victim action
– What the attacker achieves at the end
Step 3: Individual component evidence
For each vulnerability in the chain:
Name | CVSS-equivalent severity | Individual impact
What evidence would you include for each?
Step 4: Remediation section (most important)
For each of the three vulnerabilities:
What is the correct fix?
Which fix provides the highest risk reduction?
Why is fixing only one link insufficient?
State explicitly that all three must be patched together.
Step 5: Combined impact calculation
If this were a real web application with 50,000 users:
How many users would be affected if the guestbook receives 1,000 views/day?
At what point after injection does the first user trigger the chain?
What is the CVSS Base Score for this combined finding?
📸 Screenshot your written impact statement and remediation section. Post to #lab-22-chaining on Discord. Tag #lab22complete #dvwalabseries
🧠 QUICK CHECK — Vulnerability Chaining
📋 Vulnerability Chaining — Lab 22 Reference
🏆 Mark Lab 22 Complete — DVWA Vulnerability Chaining
You have completed the DVWA core vulnerability series. Lab 22 brought together every attack class from the previous 21 labs into a single coordinated chain. The remaining 8 labs in the series move to OWASP Juice Shop and VulnHub walkthroughs — applying these same skills to more realistic application environments.
❓ Frequently Asked Questions — DVWA Vulnerability Chaining 2026
What is vulnerability chaining?
What is the XSS + CSRF + file upload chain?
Why is vulnerability chaining important for bug bounty?
How do you find chainable vulnerabilities?
How do you report a vulnerability chain in bug bounty?
Is fixing only XSS enough to close the full chain?
Lab 21: SQL Injection High Security
DVWA Lab Series Hub — All 30 Labs
📚 Further Reading
- Lab 20: DVWA CSRF Advanced — The CSRF token bypass via XSS technique that is the core of Lab 22’s chain — Lab 20 establishes it in isolation before Lab 22 weaponises it within the full attack chain.
- Lab 6: DVWA File Upload — PHP Shells and RCE — The standalone file upload exploitation that becomes the terminal step of the Lab 22 chain — ensure Lab 6 is complete before Lab 22.
- DVWA Lab Series Hub — Full 30-lab overview — Lab 22 is the final core DVWA lab; remaining labs apply these techniques to Juice Shop and VulnHub environments.
- PortSwigger — Exploiting XSS to Perform CSRF — PortSwigger’s XSS exploitation guide covering the CSRF chain technique at the heart of Lab 22 with guided labs for more complex real-world variants.
