{"id":10393,"date":"2026-02-04T21:08:27","date_gmt":"2026-02-04T19:08:27","guid":{"rendered":"https:\/\/the-s-unit.nl\/?p=10393"},"modified":"2026-02-05T11:22:44","modified_gmt":"2026-02-05T09:22:44","slug":"pdf-generatie-als-aanvalspad-naar-server-secrets","status":"publish","type":"post","link":"https:\/\/the-s-unit.nl\/en\/pdf-generatie-als-aanvalspad-naar-server-secrets\/","title":{"rendered":"PDF generation as an attack path to server secrets"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

What The Hack<\/a><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

PDF generation as an attack vector: from input field to server secrets<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"PDF-generatie\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In What the Hack, Wesley, an ethical hacker at The S-Unit, shares a real-world example from an anonymous penetration test. A vulnerability in a PDF generator opened the door to sensitive server data.<\/strong><\/p>

How could this vulnerability be exploited, and what can you as a developer do to close off this attack path?<\/strong><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

First contact: PDF generator with potential<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

With a few well-established security principles in mind, I started a penetration test on an application handling highly sensitive and private personal data. My first step was to explore the application, understand the developers\u2019 intent, and identify where design choices might unintentionally allow exploitation.<\/p>\n

The application enabled users to complete questionnaires, share meeting notes between two trusted parties, and generate PDF reports. When I noticed that last feature, it immediately caught my attention. PDF generation often expands the attack surface, so I decided to take a closer look. I tested all input fields to see whether I could visibly inject HTML into the generated PDF.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Jackpot: improper user sanitization<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Jackpot! When reviewing the questionnaire responses, one thing immediately stood out: the input was not sanitized. My test payload appeared in bold in the PDF without any issues. I conduct much of my testing using PortSwigger\u2019s Burp Suite, a powerful tool for uncovering the inner workings of a web application. This was already a clear finding\u2014but I continued to make the real impact visible.<\/p>\n

We\u2019re getting somewhere!<\/strong><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Digging deeper: escalation through unknown functionality <\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Public libraries speed up development, but sometimes introduce unnoticed attack paths. The PDF generator used by the client turned out to be extensively documented. Its accompanying wiki clearly described the available features, quickly revealing the library\u2019s capabilities, even while the application itself was still largely unexplored.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Local file read via PDF-generation<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In the documentation of the PDF generator, I discovered a feature that allowed attachments to be added to a generated PDF. This functionality enabled references to local files via a file:\/\/ handler. To gain more insight into the underlying system, I attempted to read a well-known Linux file with general read permissions using the right payload. Sure enough, after generating the PDF, the file was attached. The resulting document contained a copy of the server\u2019s password file as an attachment.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

A turning point in the investigation<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

This marked a clear turning point in the investigation. With read access to local files, I could immediately examine the configuration of the server running the PDF generator. The password file already provided an initial indication of the users and the privileges under which the process was running. This raised the next set of questions: what exact privileges did this process have, and what additional information became accessible now that I could read files?<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

All the juicy stuff! (principle of least privileges)<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Development teams often store sensitive information such as secrets, keys, and passwords in environment variables. The process responsible for generating PDFs turned out to be running as root, which gave me read access to environ, where these variables are stored. Because the PDF generator process was granted overly broad privileges, this provided insight into credentials for, among other things, Keycloak, databases, Amazon S3 buckets, and multiple internal systems.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Lessons learned: where do you close off this attack path?<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

How can you prevent this attack? With a few targeted decisions, this attack path could have been closed off early on.<\/p>