PHP Security Hardening Checklist: php.ini, PHP-FPM and Server Settings That Stop Real Attacks

1. Patch first, harden second

No configuration makes an unpatched PHP engine safe. Run PHP 8.4 or 8.5 with the latest patch release (8.4.27 or 8.5.12 or newer as of October 2026), install updates from your distribution or vendor promptly, and restart PHP-FPM after every update, because running workers keep the old code in memory. Track end-of-life dates: PHP 8.2 stops receiving fixes on 31 December 2026.

2. Lock down php.ini

Set the directives in the table in the main php.ini or, better, per pool with php_admin_value and php_admin_flag, which applications cannot override with ini_set() or .user.ini files. PHP’s own PHP2Shell advisory makes this point: mitigations set where the application can change them are not reliable.

Be deliberate with disable_functions. Many applications never need to run shell commands, and removing exec, system and their relatives means an attacker who uploads a web shell gets far less from it. Test in staging, because some libraries (image processing, PDF generation, deployment tools) call them.

3. Isolate sites with PHP-FPM pools

Give each website or application its own PHP-FPM pool running as its own Unix user, with open_basedir limited to that site’s directory. On shared servers this is the difference between one hacked plugin compromising one site and compromising all of them. Set pm.max_children and request_terminate_timeout so a flood of requests cannot exhaust the server.

Where you can, run PHP in containers with a memory limit at the container or cgroup level. PHP’s advisory notes this as an availability boundary for CVE-2026-109618, while warning not to substitute RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation failure.

4. Never execute code from upload folders

Most real-world PHP compromises end the same way: a .php file lands in an upload directory and the attacker requests it. Block that at the web server. In Nginx, return 403 for any .php request under uploads paths; in Apache, disable the PHP handler in those directories. Validate uploads by content, not just extension, store them outside the web root when possible, and rename them on upload.

Make application code read-only to the user PHP runs as. Deploy new code through Git or a CI/CD pipeline rather than editing files on the server, so an attacker who gets code execution still cannot quietly modify your application.

5. Protect sessions, secrets and the database

Use secure, HttpOnly cookies with SameSite set, regenerate the session ID after login, and store sessions in Redis or the database on multi-server setups. Keep secrets in environment variables or a secrets manager, never in a file inside the web root, and never in Git. Give the database user only the privileges the application needs, and use prepared statements everywhere to rule out SQL injection.

6. Add a firewall, headers and monitoring

A web application firewall such as Cloudflare or ModSecurity with the OWASP Core Rule Set blocks known exploit patterns, and vendors shipped PHP2Shell rules within a day of disclosure. Add HTTPS with HSTS, a Content Security Policy and other security headers. Ship PHP-FPM and web server logs somewhere central, alert on spikes in 500 errors and on new .php files appearing, and keep tested off-site backups.

WebsNexus hardens and maintains PHP servers, and can run this checklist on yours as part of a security review from $100. If your application cannot run on a supported PHP version, we can also plan its upgrade or migration.