The short answer: PHP 8.2 stops receiving security fixes on December 31, 2026. If your website runs on 8.2 or older, find out which version it really uses, plan the upgrade, and in the meantime tighten the configuration settings and exposed files that attackers look for first.
A website does not stop working when its PHP version reaches end of life. It keeps serving pages exactly as before. What changes is that newly discovered vulnerabilities in that version no longer get fixed upstream, so the gap between “known” and “patched” only grows. This guide covers how to check where you stand and what to fix.
Why PHP versions age out
Every PHP release follows the same lifecycle. It starts with active support, where bugs and security issues are fixed. It then moves to security-only support, where only security issues are fixed. Finally it reaches end of life, and the PHP project stops releasing fixes for it at all.
The dates that matter right now, from php.net:
- PHP 8.1 reached end of life on December 31, 2025.
- PHP 8.2 security support ends on December 31, 2026.
- PHP 8.5 is the current release.
Some Linux distributions and hosting providers backport security fixes to older PHP packages on their own schedules. If you rely on that, confirm it in writing with your provider rather than assuming it.
How to find your PHP version
1. Check the response headers
Many servers announce the PHP version in an X-Powered-By header. Run curl -I https://your-site.example and look for a line such as X-Powered-By: PHP/8.2.x. If you see it, so can everyone else, which is one reason to turn expose_php off (see below). If the header is missing, that does not mean you are on a current version; it may simply be hidden.
2. Use phpinfo() only as a last resort
A page that calls phpinfo() prints the version and every loaded setting, but also file paths, loaded modules and environment variables, which often include database passwords and API keys. Anyone who requests it while it exists can read all of that, so deleting it afterwards does not undo the exposure. Prefer your hosting panel or php -v (below). If you must use phpinfo(), restrict the file at the server first (for example allow only your own IP address, or put it behind HTTP authentication), give it an unguessable name, read it, and remove it immediately.
3. Look in your hosting panel
Most managed hosting control panels show the PHP version per site and let you switch it. This is often the quickest route for WordPress and other CMS sites on shared hosting.
4. Run php -v on the server
With shell access, php -v prints the command-line version. Be aware that the command-line PHP and the version serving your website (for example through php-fpm) can be different installations. Confirm the one the web server actually uses.
The php.ini settings that matter
Upgrading fixes the runtime. Configuration decides how much an attacker learns and what they can do. These are the settings worth checking first:
| Setting | Recommended value |
|---|---|
expose_php | Off |
display_errors | Off (with log_errors = On) |
allow_url_include | Off |
session.cookie_httponly | 1 |
session.cookie_secure | 1 (on HTTPS sites) |
session.cookie_samesite | Lax or Strict |
session.use_strict_mode | 1 |
disable_functions | Functions your app does not use |
- expose_php controls the
X-Powered-Byheader. Turning it off does not fix anything by itself, but it stops advertising your exact version. - display_errors should be off in production. Error messages shown to visitors can reveal file paths, queries and library versions. Log errors instead.
- allow_url_include lets
includeandrequireload code from a URL. Keep it off; very few applications need it. - Session cookie flags (
httponly,secure,samesite) make session cookies harder to steal through scripts, plain HTTP or cross-site requests.use_strict_moderejects session IDs the server did not create. - disable_functions can block functions such as
exec,shell_exec,system,passthru,proc_openandpopen. Test first: some plugins and tools rely on them.
Exposed files: the easy wins for attackers
Some of the most damaging PHP exposures are not vulnerabilities in PHP at all. They are files that should never have been reachable from the web:
- .env files often hold database passwords, API keys and mail credentials. If
/.envreturns content, treat every secret in it as compromised and rotate them. - phpinfo pages left behind after debugging, as described above.
- .git directories can let anyone download your source code and its history, including secrets that were committed and later removed. A 403 on
/.git/is not enough: with directory listing off, files such as/.git/HEADand/.git/configcan still download. Block the whole.gitdirectory tree at the web server, or keep it out of the web root entirely. - Backups such as
.zip,.sqlor.bakcopies left in the web root.
The fix is the same in each case: keep these files outside the web root, or block them in your web server configuration, and check that the block actually works by requesting the path yourself.
Do not forget Composer dependencies
Modern PHP applications, including Laravel and Symfony projects, pull in many packages through Composer. Your composer.lock file records the exact versions deployed, and those packages have security advisories of their own, independent of the PHP runtime. Running composer audit checks the installed packages against known advisories. Make it part of every deploy, not a one-off.
Planning the upgrade
The upgrade itself is usually less work than people fear, as long as it is tested before it reaches production:
- Make a staging copy of the site and switch it to the new PHP version first.
- Check the compatibility notes for your CMS, theme and plugins, or for your framework version.
- Read the deprecation warnings in your current error log. They point at the code most likely to break.
- For Composer projects, update the PHP version constraint and run the dependency update in staging, not on the live server.
- Know how to switch back. Most hosting panels let you return to the previous version if something unexpected breaks.
A short checklist
- Confirm the PHP version your web server actually runs.
- If it is 8.2 or older, schedule the upgrade and test your CMS, theme and plugins against the new version.
- Set
expose_php,display_errorsandallow_url_includeto off. - Set the session cookie flags and strict mode.
- Request
/.env,/.git/HEAD,/.git/configand anyphpinfopage on your own site and make sure none of them return content. Then confirm the web server blocks the entire.gittree, not just the directory listing. - Run
composer auditand update packages with known advisories. - Check your CMS core version is still supported.
Want a Written Answer for One Site?
The Scan Ninja PHP Exposure Assessment inventories your PHP version and configuration, checks for commonly exposed files, reviews the PHP runtime, CMS core and Composer packages against published security advisories, and returns prioritized findings in a written report. $499 one-time for one website or PHP environment.
Or talk to us
Whichever route you take, the goal is the same: know your version, know your settings and know what is reachable from the internet before December 31 arrives. For a managed path from findings to verified fixes, see Managed Vulnerability Remediation.