Our PHP2Shell study found that 31% of websites disclosing a clear PHP version to our checker reported a branch past upstream end of life. Another 15% reported PHP 8.2, whose security support ends on 31 December 2026.
PHP2Shell is the name used for CVE-2026-109618 and CVE-2026-109619, the critical vulnerabilities addressed in PHP’s 21 October security release. Interest in our free PHP Version Checker surged around the announcement, giving us an unusually large view of the versions checked websites publicly reported.
Our research snapshot covers 100,893 distinct sites, of which 17,228 disclosed an eligible PHP version. The sample follows websites people chose to check with Web Aloha; version percentages below use those 17,228 disclosures unless another denominator is stated.
The main findings:
- 31% reported an unsupported branch: 5,329 sites on PHP 8.1 or older.
- New release reports rose from 32% to 70% across the 21–24 October daily cohorts, among eligible supported-branch reports with a full version number.
- 78% of below-threshold reports in those cohorts were one release behind. This describes the version numbers, not the host’s update habits.
- 65% of completed results with a PHP-related signal returned no version. An outside check often needs confirmation from the hosting account.
Web Aloha works with WordPress and Elementor websites and publishes guidance on WordPress and PHP compatibility, Elementor and PHP and the recommended PHP version for WordPress in 2026. Elementor’s official system requirements link to our Elementor/PHP guide within their PHP recommendation.
Nearly one in three disclosed versions was past end of life
PHP 8.3 was the most common disclosed branch, at 27%. PHP 7.4 was the largest unsupported branch, with 2,038 reports.
| Reported branch | Sites | Share of eligible versions |
|---|---|---|
| PHP 8.5 | 2,179 | 12.6% |
| PHP 8.4 | 2,457 | 14.3% |
| PHP 8.3 | 4,652 | 27.0% |
| PHP 8.2 | 2,605 | 15.1% |
| PHP 8.1 | 1,217 | 7.1% |
| PHP 8.0 | 487 | 2.8% |
| PHP 7.4 | 2,038 | 11.8% |
| PHP 7.3 and older | 1,587 | 9.2% |
Six additional PHP 8.6 claims (less than 0.1%) remain unclassified: PHP 8.6 was still a release candidate on the snapshot date. All shares use 17,228 as the denominator; rounding may affect totals.
The older versions were not evenly distributed. The final ordinary releases dominated their branches: PHP 7.4.33 accounted for 1,740 of 2,038 PHP 7.4 reports (85%), PHP 8.0.30 for 408 of 487 PHP 8.0 reports (84%), and PHP 8.1.34 for 1,025 of 1,217 PHP 8.1 reports (84%). Even PHP 5.6 clustered at its final release: 330 of 411 reports named 5.6.40. Eight reports still named PHP 4.4.9. These clusters show which version strings remain visible. They cannot tell us whether a site stopped receiving maintenance, uses vendor backports or reports an outdated header.
“End of life” means ordinary support from the PHP project has ended. PHP 8.1 reached that point in December 2025; PHP 7.4 in November 2022. PHP’s unsupported-branches list records the dates and final releases. The exceptional source patches supplied for PHP 7.4, 8.0 and 8.1 after PHP2Shell did not restart those branches’ normal support.
For context, Mallory’s 21 October Shodan analysis reported about 74% of version-disclosing internet-facing PHP services on 8.1 or older. Its unit is a network service; ours is a site submitted to a checker. Different selection and counting methods make the figures unsuitable as competing estimates of global PHP market share.
Later observations more often reported the new releases
PHP’s first supported releases addressing the October 21 vulnerabilities were 8.2.35, 8.3.36, 8.4.27 and 8.5.12. We compared full reported versions with the threshold for their own branch.
Among 11,533 reports with their first eligible observation on 21–24 October and a full PHP 8.2–8.5 version number, 5,387 (47%) met or exceeded the relevant threshold. Of the 6,146 below it, 4,811 (78%) reported the immediately preceding release: 8.2.34, 8.3.35, 8.4.26 or 8.5.11.
| First eligible observation (UTC) | Full versions on PHP 8.2–8.5 | At or above the release threshold | Share |
|---|---|---|---|
| 21 October | 4,116 | 1,322 | 32% |
| 22 October | 5,322 | 2,768 | 52% |
| 23 October | 1,726 | 1,037 | 60% |
| 24 October | 369 | 260 | 70% |
Each row contains different sites, grouped by the date of their first eligible version observation. The pattern shows newer release numbers appearing more often in later cohorts. We did not repeatedly follow the same sites through an upgrade, so it cannot measure how quickly individual owners patched. The release-day row includes observations both before and after the announcement. The partial 25 October cohort is excluded from this comparison.
A host can apply a security fix without changing the public version number, and a header cannot confirm the package or configuration actually serving every request. These figures therefore measure reported release numbers, not verified patch status or vulnerability. Mallory also published fixed-version observations over time, with its own Shodan coverage and rescan limitations.
PHP’s 23 October session-upload-progress notice concerns a separate issue, CVE-2026-115560, and recommends a temporary configuration precaution until the next regular release. Ask your host to review it even if the reported version meets the October 21 threshold. Our October PHP security guide explains the immediate patching questions.
Why many checks did not reveal a PHP version
Only 17% of all 100,893 checked sites supplied eligible version evidence. Another 72,119 completed without it; 11,546 had incomplete or unavailable results.
We can ask a more specific question within completed results that showed some PHP signal: 32,218 of 49,637, or 65%, returned no version. This is the group behind the disclosure finding above, rather than all websites or all PHP installations.
| Completed result with a PHP-related signal | Sites |
|---|---|
| WordPress-related signal, no version | 25,626 |
| Other PHP-related signal, no version | 6,592 |
| Version signal | 17,419 |
The version-signal group includes weaker evidence, including five body-only mentions. Only the 17,228 reports that passed every eligibility rule enter the branch distribution.
An online checker reads public responses, including headers such as X-Powered-By. It cannot inspect the hosting account. PHP’s expose_php setting can disable version disclosure, while conflicting or weak signals can also prevent a reliable answer. Across the wider sample, some sites may not use PHP at all, and some requests fail or are blocked.
If the checker cannot identify your version, use the hosting panel or WordPress’s Tools → Site Health → Info → Server screen. Hiding a version can reduce disclosure; it does not install a security update.
PHP 8.2 owners have a second deadline
The 2,605 PHP 8.2 reports belong outside the end-of-life total: the branch still receives security fixes as of 25 October. But its support ends on 31 December 2026, leaving a short planning window. Applying an 8.2 patch does not move that date.
| Stable branch | Support on 25 October 2026 | Security support ends |
|---|---|---|
| PHP 8.2 | Security fixes only | 31 December 2026 |
| PHP 8.3 | Security fixes only | 31 December 2027 |
| PHP 8.4 | Active support | 31 December 2028 |
| PHP 8.5 | Active support | 31 December 2029 |
Source: PHP’s supported-version schedule, reviewed 25 October 2026.
Choose a newer supported branch that works with the full site, then test the theme, plugins, custom code and extensions together. Our PHP 8.2 end-of-life checklist covers preparation, and the WordPress PHP Upgrade Readiness Checker helps organize the checks.
If your WordPress site is on PHP 8.2 or an older branch, our WordPress PHP update service can help assess compatibility and plan the move to a maintained branch.
Get help updating WordPress PHP
Why we looked at this sample
The alert coincided with a sharp increase in checker use. GA4 recorded 108,474 run events, 105,626 result events and 52,665 measured users over the four complete UTC days from 21 to 24 October. Repeated checks and unsuccessful attempts contribute to those events; they are separate from the deduplicated research sample.
Web Aloha visualization of GA4 aggregates, captured on 25 October 2026.
For “php version checker”, Google Search Console recorded average positions around first place in the UK, US, Germany and the Netherlands in the available final data for 18–22 October. Below is our 24 October browser capture for that query.
From a version check to an upgrade plan
Start by asking the host to confirm the PHP package serving your site, its current security fixes and its maintenance deadline. Then back up the files and database, test the target branch on staging, and check the functions that matter: editing, forms, email, logins and, for shops, checkout and order processing. Repeat those checks after the live change and review errors with the developer. WordPress’s PHP update instructions provide a useful starting point.
Deal with an available security fix promptly while planning any larger branch migration. A working front page alone cannot tell you whether the runtime is maintained or the full application is compatible.
Method and downloadable findings
The research snapshot was frozen on 25 October 2026 at 05:35:55 UTC, covering collection from 18 October through that moment. The first and last collection days are partial. It uses PHP Version Checker detector 2026-10-18.2; three older-detector records are excluded.
We count one site per monthly tool, source, mode and detector cohort, with a domain-based definition that separates tenants on supported shared-hosting domains. An ineligible result can be replaced by its first later eligible measurement; 729 records were upgraded this way. Once eligible, a record is not continually refreshed. Version statistics require successful, complete responses and strong, unambiguous public evidence. A single read-only database query froze the aggregate counts.
Research records hold limited technical facts and pseudonymous site and page identifiers, without raw target URLs, response contents, visitor IP addresses or analytics IDs. Separate daily IP-derived buckets cap collection at 20 distinct sites when trusted IP information is available; this limits some abuse but does not identify humans or establish a bot-free sample. Records are excluded after 90 days and removed through scheduled daily cleanup, while aggregate snapshots may remain longer; see our research privacy notice.
Download the findings and detailed method, use the aggregate JSON, or download the charts as PNGs. For a methodology question or correction, contact Web Aloha.
