```html

phpinfo.php Old: The Hidden Information Leak That's Exposing Your Server (2026 Security Playbook)

If your server still runs an old phpinfo.php file sitting in a web-accessible directory, you are broadcasting your entire PHP stack to attackers. This playbook tells you exactly how to find it, eliminate it, and lock down what comes next—before a scan turns your config into someone else's roadmap.

Key Takeaways

• phpinfo.php exposes everything—PHP version, loaded extensions, server API, environment variables, database constants, and full $_SERVER dump.
• Old files are low-hanging fruit. Scanners continuously probe for /phpinfo.php, /info.php, and /test.php across the entire internet.
• Removing it is one command. But verification matters—caches, CDNs, and backups can resurrect the leak.
• Alt-plan: lock it behind authentication if you genuinely need live diagnostics (use Require valid-user or an IP allowlist).

What "phpinfophpold" Actually Means

The phpinfo.php File

phpinfo() is a PHP function that prints a massive table of configuration details. Developers ship it as phpinfo.php for quick checks during setup, then forget to delete it. Years later, the file is still live, still serving data, and still indexed by search engines and vulnerability scanners alike.

Why "Old" Makes It Worse

• Old PHP versions (< 8.0) carry known CVEs—phpinfo reveals the exact version number.
• Legacy hosting stacks often lack modern WAF rules that auto-block info leaks.
• Abandoned projects leave phpinfo files in document roots with no monitoring.

Immediate Detection Checklist

Run through this list. Check every item off before declaring the server clean.

Step 1 — Scan for the File

• [ ] Search web root: find /var/www -name "phpinfo.php" -o -name "info.php" -o -name "test.php"
• [ ] Search common Laravel/Symfony paths: find /var/www -path "*/public/*" -name "*.php" | xargs grep -l "phpinfo"
• [ ] Check subdomains and virtual hosts: ls /etc/nginx/sites-enabled/ or ls /etc/apache2/sites-enabled/
• [ ] Inspect backup directories: find / -name "phpinfo.php" 2>/dev/null

Step 2 — Verify External Exposure

• [ ] Curl test: curl -s https://yoursite.com/phpinfo.php | head -50
• [ ] Check Google index: site search site:yoursite.com phpinfo.php
• [ ] Scan Shodan/Censys for your IP range to confirm it appears in exploit databases
• [ ] Test via external scanner (e.g., nmap --script http-phpself-xss)

Step 3 — Remove the File

• [ ] Delete: rm /var/www/html/phpinfo.php
• [ ] Remove from all virtual hosts and document roots where found
• [ ] Clear CDN cache (Cloudflare, Fastly, Akamai) — stale copies persist
• [ ] Purge server-side opcode cache: php -r 'opcache_reset();'
• [ ] Re-run curl test to confirm 404 or 403 response

Comparison: Leaving phpinfo.php vs. Securing It

Factor	Leaving It Exposed	Secured or Removed
PHP Version Leak	Visible to anyone	Not accessible
Loaded Extensions	Full list exposed	Hidden
Environment Variables	$_ENV dump visible	Blocked
Database Constants	Host, port, socket shown	Not reachable
Scanning Risk	High — auto-probed daily	Eliminated
Compliance (PCI-DSS, SOC2)	Fails information disclosure controls	Passes
Recovery Effort	Post-breach forensic cleanup	One rm command

Long-Term Prevention Checklist

• [ ] Add a server-level block in Nginx: location ~* \.(phpinfo|info|test)\.php$ { deny all; }
• [ ] Add Apache equivalent: <FilesMatch "(phpinfo|info|test)\.php$"> Require all denied </FilesMatch>
• [ ] Enable a Web Application Firewall (Cloudflare WAF, ModSecurity) with info-leak rules
• [ ] Add automated scanning to CI/CD: grep -r phpinfo --include="*.php" src/ fails the build
• [ ] Document a server hardening SOP that includes phpinfo removal as a mandatory step
• [ ] Schedule quarterly external recon scans to catch regressions early
• [ ] Audit third-party plugins and themes—they sometimes ship diagnostic phpinfo files
• [ ] Restrict php.ini directives: expose_php = Off and display_errors = Off in production

When You Absolutely Must Keep phpinfo.php

Some teams need live PHP diagnostics in staging. If that applies to you, apply these controls:

• IP allowlist only: restrict access to internal CIDR ranges
• HTTP Basic Auth: require credentials before the file loads
• Subdomain isolation: host it on phpinfo.internal.yourdomain.com with no public DNS entry
• Token-based access: require a rotating one-time token in the URL

Frequently Asked Questions

FAQ 1: Is an old phpinfo.php file really that dangerous?

Yes. An exposed phpinfo.php reveals your exact PHP version, all compiled-in extensions, server software, operating system details, and sometimes database connection strings hardcoded in $_SERVER. Attackers use this data to identify CVEs applicable to your stack and craft targeted exploits. Even "old" files from 2019 are actively scanned and exploited today.

FAQ 2: Will deleting phpinfo.php break my application?

No. The file serves zero functional purpose for any production application. It is purely a developer diagnostic tool. Removing it will not affect your app's runtime, API endpoints, or frontend. If a legacy script references it internally, replace that reference with a local CLI command like php -i instead.

FAQ 3: How do I check if a CDN has cached an old phpinfo.php after deletion?

Force a cache purge in your CDN dashboard (Cloudflare: "Purge Everything" or per-URL purge). Then verify with: curl -I https://yours