Phpinfo.php.save

Key Takeaways

• Critical Vulnerability: The presence of a phpinfo.php.save file is a high-severity information disclosure risk that can facilitate targeted server attacks.
• Origin of Risk: These files are typically accidental artifacts created by text editors (like Vim or Nano) during the editing of a standard phpinfo.php file.
• Data Exposure: A single exposure can leak over 50 unique data points, including PHP versions, loaded modules, environment variables, and absolute file paths.
• Reconnaissance Facilitation: Attackers use this data to map the attack surface, identifying specific CVEs (Common Vulnerabilities and Exposures) applicable to your exact environment.
• Mitigation Strategy: Prevention requires strict .gitignore policies, automated security scanning (e.g., Nuclei, Nikto), and proper web server configuration to deny access to backup extensions.

Introduction

In the realm of web administration and cybersecurity, the most devastating breaches often do not begin with a sophisticated zero-day exploit. Instead, they start with a single, overlooked file left in a public directory. One such file is phpinfo.php.save. While it may look like a harmless temporary backup, to a malicious actor, it is a comprehensive blueprint of your entire server architecture.

The phpinfo() function is a built-in PHP utility designed to output a massive amount of information regarding the current state of the PHP environment. While developers use it for debugging, leaving the output accessible via a web browser is a violation of the principle of least privilege. The situation escalates from a "configuration error" to a "security catastrophe" when a text editor creates a .save or .bak version of this file. Because web servers are often configured to serve any file they recognize, these backup files bypass the intended logic and expose sensitive data to anyone with a browser.

As of 2024, automated reconnaissance bots scan millions of IP addresses daily, specifically looking for file extensions like .save, .swp, .bak, and .old. If your server hosts a phpinfo.php.save file, it is not a matter of if it will be found, but when.

Deep Analysis

The Anatomy of the Leak: What is inside phpinfo.php.save?

When a user executes phpinfo(), the engine generates an HTML document containing a massive table of configuration directives. A .save file is essentially a static snapshot of this dynamic output. Unlike the original .php file, which requires the PHP interpreter to run, the .save file is often treated as plain text or HTML, making it incredibly easy for bots to scrape.

The data exposed typically falls into four critical categories:

1. Environment Variables (The Gold Mine): This is the most dangerous section. Many modern applications (using Docker or Kubernetes) inject sensitive credentials—such as DB_PASSWORD, AWS_SECRET_ACCESS_KEY, or API_TOKEN—directly into the environment. A phpinfo.php.save file will list these in plain text under the "Environment" or "PHP Variables" sections.
2. System Paths and Architecture: The file reveals DOCUMENT_ROOT, SCRIPT_FILENAME, and the exact operating system version (e.g., Ubuntu 22.04.3 LTS). Knowing the exact path (e.g., /var/www/html/config/) allows an attacker to craft precise Local File Inclusion (LFI) attacks.
3. Module and Version Specifics: It lists the exact version of PHP (e.g., 8.1.12) and every loaded extension (e.g., mod_ssl, imagick, memcached). If a specific version of a module has a known vulnerability (like a buffer overflow), the attacker now knows exactly which exploit to deploy.
4. Configuration Directives: Settings like display_errors, allow_url_fopen, and open_basedir are revealed. If allow_url_fopen is set to On, it significantly lowers the barrier for Remote File Inclusion (RFI) attacks.

The Lifecycle of a Vulnerability

Understanding how this file appears is crucial for prevention. The lifecycle usually follows this pattern:

1. Development/Debugging: A developer creates phpinfo.php to troubleshoot a module issue.
2. The Editing Incident: The developer opens the file using a terminal-based editor like Vim or Nano via SSH.
3. The Artifact Creation: During a crash, a forced exit, or a specific save command (e.g., :w filename.save), the editor creates a temporary backup file.
4. The Deployment Error: The developer uses git add . or an FTP client to sync the directory, inadvertently uploading the .save file to the production web root.
5. Discovery: An automated scanner or a "Google Dork" (e.g., filetype:save "PHP Version") identifies the file.

Statistical Impact of Information Disclosure

While specific real-time statistics on .save files are proprietary to security firms, industry trends from OWASP (Open Web Application Security Project) suggest that Information Exposure (CWE-200) remains a top-tier risk. In large-scale automated scans, servers with exposed configuration files see a 300% increase in subsequent brute-force and injection attempts within 24 hours of the initial discovery.

Comparison / Alternatives

Developers often need to inspect PHP configurations. However, using phpinfo() or leaving backup files is not the only way. Below is a comparison of methods for inspecting environment settings.

Common Mistakes / Misconceptions

Myth 1: "The file is not a .php file, so the server won't execute it, making it safe."

Fact: This is the most dangerous misconception. While the server won't execute the PHP code inside a .save file, it will serve the contents as plain text. An attacker doesn't want to execute the file; they want to read the data inside it. A text file containing your database credentials is just as lethal as an executable script.

Myth 2: "I deleted the original phpinfo.php, so the .save file is useless."

Fact: The .save file is a static copy. It contains the same data that was present when it was created. Deleting the source file does nothing to remove the information already leaked into the backup file.

Mistake: Improper use of Git

Many developers use git add . to stage changes. If your local environment has editor artifacts like .swp or .save, these are added to the repository and pushed to the production server. This turns a local convenience into a global vulnerability.

Expert Tips

FAQ