When you spawn the PDFy challenge instance, you are presented with a simple web interface featuring a single input box. The application expects a user-submitted URL, which it processes to generate a downloadable PDF "screenshot" of that webpage. Examining the Client-Side Code

When accessing the web target, you are met with a clean user interface containing a single input box labeled .

Download one of the successfully generated PDFs (such as the Google snapshot) and analyze its metadata using exiftool . This helps identify the backend engine processing the HTML-to-PDF conversion: exiftool downloaded_file.pdf Use code with caution.

Create a file named index.php in the root of your local web server's directory. The content should be:

wget https://dirtypipe.exploit-db.com/cgi-bin/dl_view.cgi?item=50149

To successfully exploit this, we need a server that is accessible from the internet. The PDFy application must be able to reach our server to fetch our malicious HTML file.

: Older versions of wkhtmltopdf are highly susceptible to SSRF and Local File Inclusion (LFI). If the engine processes HTML containing local file system schema URI pointers ( file:// ), it natively attempts to embed those local files into the generated document.

run

When the application successfully processes a standard external URL (such as a public web server), look closely at the generated PDF metadata. You can download the PDF and inspect it using command-line utilities like pdfinfo or by checking how the elements are structured.

(Related search suggestions prepared.)

When you spawn the target machine and navigate to the web interface, you are greeted by a simple form containing a single input field: Enter URL to convert to PDF .