phpinfo() on a public URL: the full picture of your server

What the page actually contains

• The exact PHP build — PHP Version 8.2.29. Unlike a header, it cannot be absent or approximate.
• Loaded extensions and their versions — which tells an attacker which known bugs apply.
• ini paths and values — where configuration lives, how large uploads may be, whether errors are displayed.
• Environment variables — often DB_HOST, DB_USER, sometimes DB_PASSWORD, cloud keys and SMTP credentials.
• Absolute paths, server software, the document root — the map for every later step.

With the build and the environment together, an attacker has both the vulnerability to try and, frequently, the credentials to skip it.

Where the leftovers come from

1. Hosting “check” pages. Providers ship info.php or phpinfo.php to verify the stack and never remove them.
2. Migrations. A test file created to prove the new server works, then forgotten in the deploy.
3. Monitoring and panels. Old monitoring agents, /server-status and /server-info from Apache's mod_status and mod_info.
4. Debug toolbars and framework pages left on in production — they can print the same values without the word phpinfo appearing anywhere.

Find them

# снаружи: обычные имена, что опрашивают боты
for p in phpinfo.php info.php test.php php_info.php server-info server-status; do
  printf '%-16s %s\n' "$p" "$(curl -s -o /dev/null -w '%{http_code}' "https://example.com/$p")"
done

# на сервере: ищем вызов по содержимому, а не по имени
grep -rl --include='*.php' 'phpinfo()' /var/www 2>/dev/null
find /var/www -name 'phpinfo*.php' -o -name 'info.php' -o -name 'test.php' 2>/dev/null

Check the result against the real page: a 200 can be the site's catch-all page rather than a phpinfo. The body must contain PHP Version and phpinfo() in the title. Our checker reports this as a critical finding, separately from the version header, because a hidden X-Powered-By next to an open info.php is a false sense of safety.

Close it, then assume it was read

1. Delete the file. Not rename, not restrict — delete. A test page has no runtime purpose.
2. Rotate what the page printed. Any credential that appeared in the environment section: database, SMTP, cloud keys. This is the step people skip and regret.
3. Turn off expose_php so the build is not advertised in headers either, and set display_errors = Off in production.
4. Block the patterns so the next leftover fails closed: deny phpinfo.php, info.php, /server-info, /server-status at the web server, and disable mod_info if it is not needed.
5. Read the log. Requests for /phpinfo.php from addresses that are not yours, with a 200 in the same line, mean the page was harvested.

After the cleanup

Re-run the check: the finding should disappear and the build row should move to “not disclosed”. Then keep the release pipeline honest — a request to /phpinfo.php that returns 200 should fail the deploy, the same way an exposed .env should. A checksum baseline catches the next file that appears without a deploy.

Related