PHP Website Security: What to Check Before PHP 8.2 Loses Support

PHP is still the default language of the web. W3Techs, in data dated October 2026, finds PHP on 69.2% of websites whose server-side language it can identify. That reach includes WordPress, most shared hosting, and a large share of older custom business systems. The language itself is actively maintained: each release branch gets two years of active support and then two years of security fixes.

So the useful question is not whether PHP is secure, but whether your particular site is running supported versions, maintained plugins and safe code. The same W3Techs data shows 26.8% of PHP sites on version 7 and 7.7% on version 5, none of which receive security fixes. That is where most of the risk sits.

The PHP project publishes its support schedule on php.net. Once a branch reaches end of life, the project says users should upgrade as soon as possible because they may be exposed to unpatched security vulnerabilities. As of October 2026, four branches are supported.

The date that matters most right now is 31 December 2026. If your site or hosting plan is on PHP 8.2, you have about two months to test and move to 8.3 or newer. Moving straight to 8.4 or 8.5 buys more time before the next upgrade.

Patchstack's State of WordPress Security in 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024. Of those, 91% were in plugins and 9% in themes; WordPress core had only 6, all low priority. Patchstack judged 4,124 of them, or 36%, to be a real threat.

Two figures from the same report change how updates should be handled. For heavily targeted vulnerabilities, the weighted median time to first exploit was 5 hours, and 46% of vulnerabilities had no fix from the developer by the time they were disclosed. A monthly update routine is too slow for the first problem and does nothing for the second. The same logic applies to Composer packages in a custom PHP application: every dependency is code you are responsible for.

CVE-2024-4577 shows how configuration and locale can matter as much as the PHP version. The official PHP advisory describes an argument injection in PHP-CGI on Windows that lets a remote attacker run arbitrary code. It works through Windows "Best-Fit" character mapping on code pages 932, 936 and 950, the system locales used in Japan, China, Hong Kong, Macao, Singapore and Taiwan. The advisory notes that a default XAMPP installation on Windows was vulnerable out of the box. The fixes shipped in PHP 8.3.8, 8.2.20 and 8.1.29.

Cisco Talos reported in March 2025 that an attacker had been exploiting this flaw since as early as January 2025 against organizations predominantly in Japan, in technology, telecommunications, entertainment, education and e-commerce. For a Japanese company, or a Canadian company with a server set up by a Japanese team, the practical checks are simple: do not run PHP as CGI on Windows, do not use XAMPP or similar development bundles in production, and confirm the exact patch version rather than only the minor version.

The OWASP Top 10:2025 lists Broken Access Control first, followed by Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures and Injection. Most of these map to a small number of habits in PHP code. When we review a PHP codebase, these are the first things we check.

Security Misconfiguration is second in the OWASP Top 10:2025, and on PHP sites it usually means settings left as they were during development. These checks take an afternoon and do not require code changes.

If you own a PHP site but do not maintain it yourself, you do not need to read code to find the biggest risks. Ask your developer or hosting provider these questions, in this order. The order follows the evidence above: unsupported versions and third-party components are where compromises most often start, so they come before code review.

Write the answers down with a date. A review only helps if someone repeats it, and the written answers become the baseline for the next one.

For a site on PHP 8.2 or 8.3 with maintained plugins, upgrading is usually a matter of testing on a staging copy and switching the version in the hosting panel. Plan for a few days of work, most of it testing forms, checkout and admin screens.

For a site on PHP 7 or 5, the version change is rarely the hard part. The real cost is plugins or libraries that have no compatible release, and custom code that relies on removed functions. If more than a few key components are abandoned, compare the cost of patching with a rebuild on a maintained stack. Either way, put the end-of-life date for your current PHP branch in the same calendar as your domain and certificate renewals, so the next deadline is not a surprise.