Verifiedapp Blog
Exposed Files

phpinfo() and server-status: the debug pages attackers grep for

· 3 min read
#exposed-files#phpinfo#recon#server-status

Reconnaissance, served for free

Before anyone attacks a site, they map it: what software it runs, which versions, what is installed, where things live. Two classic endpoints do that mapping for them if left exposed — a phpinfo() page and a server-status page. Both are legitimate diagnostic tools. Both are catastrophic to leave open, not because either is an exploit on its own, but because they hand an attacker the blueprint to find one.

These are not obscure. Scanners request them by name on every host they touch, because the URLs are predictable.

What phpinfo() exposes

Calling phpinfo() renders a full report of the PHP environment. Drop it in a file — info.php, phpinfo.php, test.php — to debug a server, forget to delete it, and a visitor can read:

  • The exact PHP version and every loaded extension and its version.
  • Server software and OS details.
  • Absolute filesystem paths, which reveal your directory structure.
  • Environment variables and configuration values — sometimes including things that should never be public.

With the precise version stack in hand, an attacker can look up known vulnerabilities for exactly what you run, instead of guessing.

What server-status exposes

Apache's mod_status exposes /server-status, a live dashboard of the web server. When it is reachable publicly it can show:

  • Server version and uptime.
  • Active and recent requests — including the URLs being requested right now.
  • Client information and traffic statistics.

That live request feed is the dangerous part: it can leak the paths of other users' requests, including ones with sensitive data in the URL. The Nginx equivalent, stub_status, is less detailed but still better kept private.

Why these get left behind

Nobody ships these on purpose. They appear during troubleshooting — someone needs to check a PHP module, or enable status to diagnose load — and then the temporary page never gets removed because the immediate problem was solved and everyone moved on. The file outlives the reason it existed.

How to lock them down

  • Delete debug files. No phpinfo.php, info.php, test.php or similar should exist on a production server. If you need PHP info, check it from the command line.
  • Restrict status endpoints. Limit server-status / stub_status to localhost or specific trusted IPs, or disable the module in production entirely.
  • Turn off verbose errors. Set production to log errors rather than display them, so stack traces and paths are not rendered to visitors.
  • Make checks routine. A quick scan for these well-known paths belongs in your launch checklist, because they reappear every time someone debugs in production.

Check for the obvious doors

The whole reason bots find these is that the URLs are predictable — which means you can check for them just as easily. An automated scan requests the well-known debug and status paths exactly the way a bot would and tells you if any respond. Scan your site and make sure you are not publishing a map of your stack.

Related reading

FAQ

Is a phpinfo page actually dangerous if it has no passwords?
Yes, even without secrets. It reveals your exact software versions, loaded modules and filesystem paths, which lets an attacker look up known vulnerabilities for precisely what you run and target them directly. It removes all the guesswork from an attack.
How do attackers find these pages?
They do not search — they request the well-known URLs by name on every host, like info.php, phpinfo.php and /server-status. Because the paths are predictable, automated scanners catalogue exposed ones within minutes of a site going live.
Do I need to remove server-status entirely?
Not necessarily — it is a useful tool. Just restrict it so only localhost or specific trusted IPs can reach it, rather than the public internet. If you never use it in production, disabling the module is the simplest safe choice.

Keep reading