PHP Site AuditPHP operations
Remove public PHP debug pages before they expose server details
A publicly reachable phpinfo() page can disclose PHP version, configuration, environment variables, paths, loaded modules, and request data. Use authenticated administrative tools for diagnostics, then remove temporary debug pages and confirm they are no longer publicly accessible.
What a debug page can reveal
PHP's manual describes phpinfo() as outputting detailed information about the current PHP state. Depending on options and environment, this can include build and server details, configuration values, modules, environment data, paths, headers, and request variables. Even where the page does not reveal a password, infrastructure detail can help an attacker map a target.
Public debug output is separate from the PHP2Shell vulnerabilities. Removing it reduces unnecessary information exposure; it does not patch a PHP runtime or establish whether an attacker previously accessed the page.
Use a safer diagnostic path
Check PHP through a host control panel, restricted management network, authenticated admin interface, or server-side inventory. If a temporary file was used, delete it after collecting only the needed evidence, check deployment artifacts and backups so it is not restored later, and request a normal public GET to confirm the route no longer returns diagnostic content.
For patch confirmation, ask the provider for the runtime package/build and security advisory. A public PHP version header or diagnostic page should not be used as permanent monitoring because it reveals detail and can still show a different SAPI than the one serving other domains.
Search the web root, deployment artifacts and routing rules for temporary diagnostic endpoints, then remove the file or restrict it through the platform's supported access controls. Review access logs for requests to the endpoint while preserving them according to the incident and retention policy.
Handle a discovered exposure carefully
Restrict or remove the page promptly and preserve access logs if there is concern that it was reached. Ask the host or incident team to review evidence and decide whether credentials or additional steps are needed. The existence of the page alone does not prove that it was viewed or exploited.
Coordinate removal with the application owner and preserve relevant access records if misuse is suspected. Do not include diagnostic output, file paths or secrets in a public issue or unprotected support message.
Common questions
Is hiding PHP errors enough to fix PHP2Shell?
No. Error display settings do not install the runtime patches; follow the PHP advisory and update the package.
Can a temporary diagnostic page stay online?
Avoid public exposure. Share configuration through authenticated support and remove restricted diagnostics after use.
Where should production errors go?
Use the platform's protected logging and access controls, and confirm that logs do not expose secrets publicly.