PDF That Steals Data - The DocDrop Exploit
Summary
A malicious PDF embeds an invisible 1×1‑pixel image within itself whose source is a remote URL. When any PDF viewer or browser opens the document, it automatically fetches that invisible image that leaks the viewer’s IP address, User‑Agent (OS/browser) and other HTTP headers to the attacker’s server.
Description
I found this vulnerability in one of the website from bug bounty program where I had an option to upload PDFs which can be viewed by other invited users. Initially I uploaded a PDF that gave a normal XSS pop-up, however PDF cannot access DOM properties unless the website is using FontMatrix, so I created a PDF that helps tracks the user’s data like browser and OS details and there IP address. Once this PDF is uploaded, another user just needs to open the PDF and the data will be dumped on the attacker’s server.
Anatomy of JavaScript execution within PDF on Different Browsers
The Tracking PDF works with Chrome browser only and it will not execute the in-built javascript on Firefox or Edge due to below reasons:
- Chrome’s built‑in viewer (PDFium)
Chrome ships its own PDF engine (PDFium) which executes a subset of Acrobat‑style JavaScript including submitForm() without asking the user. That’s why, when the PDF is opened in Chrome, the submitForm('<LOGGER_URL>') runs immediately and hits the attacker’s server. - Firefox’s viewer (pdf.js) disables JS by default
Mozilla’s pdf.js intentionally ignores or blocks embedded JavaScript for security. Even though recent versions of Firefox can support JS if you really enable it, by default any /JavaScript actions in a PDF are simply skipped. - Edge’s built‑in viewer also won’t execute PDF JS
Although Edge is now Chromium‑based, Microsoft has locked down PDFium in a “no‑scripting” mode. In practice, /JavaScript actions inside PDFs are not executed at all in Edge’s integrated PDF reader.
NOTE: I am continuously doing a research that how can we leverage this exploit into other critical things and also make it work for other browsers.
How I found this vulnerability ?
- I had an option of + Add Attachment where I can upload the Tracking PDF which can be viewed by all other invited users
2. I went to https://iplogger.org/tracking-pixel/ for creating a tracking pixel which I can embed in PDF, making it a Tracking PDF
3. After the link was created, I copied the link and pasted it in the PDF within the JavaScript code snippet
4. After the Tracking PDF was uploaded, I went to another account and clicked on the View option to open the PDF
5. When the PDF was opened I click on the “ClickHere” text and the victim’s data was logged on the IP Logger’s website
NOTE: In the above steps I played both the roles, attacker and victim so please don’t get confused.
Why this happened ?
In my opinion,
this happened because when the PDF file was uploaded using the + Add Attachment option, the server did not check the contents of the PDF which has embedded javascript code within that performed the victim’s data logging to the IP logger’s website.
NOTE: You can download the Tracking PDF from my Github.
Impact
An attack can identify which IP addresses opened the PDF and along with User‑Agent strings (e.g. “Windows 10 / Chrome”) and other HTTP headers. This information can help attacker to craft targeted social‑engineering attacks.
CVSS Score & Explained
Vector String: CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N
Score: 3.1 Low
Explanation:
Attack Vector (Network): The attacker can access the project over the network, as it’s a web application.
Attack Complexity (High): This bug currently only works with Chrome browser which raises its complexity
Privileges Required (None): The attacker does not need any privilege to perform this attack
User Interaction (None): Additional user interaction is needed where the victim needs to open and click on the PDF
Scope (Unchanged): The affected application is maintained by the same security authority.
Confidentiality (Low): There is an exposure of user’s data like browser details, OS name and IP address
Integrity (None): The attacker is not able to modify any data here
Availability (None): The overall website remains accessible
Mitigation
- Disable remote resource loading in your PDF previewer:
- Configure your PDF viewer or web‑app sandbox to block any /F (file-fetch) entries pointing to external URLs.
- For web‑based viewers, strip or rewrite XObject /F entries before streaming the PDF to users.
2. Sanitize uploaded PDFs server‑side:
- Use a PDF‑sanitization library (e.g. QPDF, poppler-utils’ pdfimages/pdftocairo) to remove all external references
- Flatten annotations and XObjects so that only embedded (in‑document) images remain.
3. Enforce Content Security Policy (CSP) for PDF rendering:
- If you display PDFs in an <iframe> or object element, apply a CSP that restricts img-src to self or to approved domains only.
