During testing, I encountered a PDF export feature that allowed users to preview and download generated reports. The application provided multiple predefined templates each producing a dynamically generated PDF.

All screenshots shown are locally reproduced in a controlled environment to maintain real target confidentiality.

At first, everything appeared normal. The preview functionality worked as expected and each download returned a randomly named PDF file.

However, while inspecting the network requests behind the download action, I noticed something unusual.

The application was passing a filesystem path directly as a GET parameter.

Instead of referencing a logical identifier (such as a report ID), the p parameter contained an absolute path on the server.

That was the first red flag.

Why the Path Disclosure Mattered

The disclosed path revealed several critical details:

• The application was reading files directly from server’s filesystem.
• The home directory of the system user was exposed
• The webroot was hosted inside a privileged system user directory
• There was no visible attempt to sanitize or restrict the input

This suggested that the application was blindly trusting user input to locate and serve files.

At this point, I suspected a Local File Inclusion (LFI) vulnerability.

Confirming the LFI

To validate the issue, I replaced the PDF path with a known system file.

The server responded with the contents of /etc/passwd, confirming that arbitrary files could be read from the filesystem.

The response included the application user account proving that the process had sufficient permissions to read sensitive system files.

This confirmed unrestricted local file inclusion.

Escalating the Impact

Once arbitrary file reads were confirmed, I tested whether application-level secrets were also accessible.

I attempted to retrieve the environment configuration file:

The request successfully returned the .env file.

This file contained sensitive information such as:

• Database credentials
• Application secrets
• Internal configuration values

At this stage, the vulnerability escalated from file disclosure to full application compromise.

Access to environment variables alone is often enough to pivot into database access, authentication bypass, or further internal exploitation.

Critical Misconfiguration: Privileged Webroot

One of the most serious issues here was how the application was hosted.

The web application was running from a privileged system user’s home directory, rather than a restricted webroot.

This is a dangerous configuration.

What went wrong:

• The webroot was hosted under a system user with broad permissions
• The application process had access to sensitive directories
• File inclusion instantly became high-impact

What should have been done:

• Web applications should run under a low-privileged user
• The webroot should be isolated (e.g. /var/www/html)
• Ownership should be restricted to www-data or an equivalent service account
• The application should not have read access outside its intended directory

Running a web application under a privileged system user turns simple bugs into critical vulnerabilities.

In this case, the LFI would have been far less damaging if proper privilege separation had been enforced.

Why This Vulnerability Existed

This issue occurred due to a combination of mistakes:

• User-controlled input was directly used to read files
• No path allowlisting or normalization was applied
• Absolute paths were trusted without validation
• The application ran with excessive filesystem privileges

Individually, each mistake is bad.
Together, they resulted in a high-impact LFI.

Have you ever found a critical bug in a feature as simple as a PDF export?

If you’re interested in real-world vulnerability discoveries, follow me here on Medium.

I write about:

• Practical exploitation techniques
• Real security mistakes found during testing
• Lessons that help developers and testers avoid repeating them

Every write-up is based on hands-on analysis, not theory.