Research collected from outside sources and what this site derives from them; every fact links to a saved copy of its source Research or story?
Risks / R01 Remote code execution on internet-facing PHP servers / R01-3
R01-3: Versions the PHP project no longer fixes stay vulnerable
Because PHP 8.1 and older receive no upstream fix and the flaws may reach back to PHP 5, installations on retired versions depend on a distribution backport, paid support or an upgrade, resulting in a long tail that stays exposed for months.
Rating 20 critical · Likelihood 4 Likely · Impact 5 Severe · Kind Security · Acceptance not recorded
Basis. Retired versions are common on shared hosting and appliances; upstream will not fix them; CISA singles out 8.1 and older.
The path
Who carries it
One risk, assigned to every stakeholder that carries part of it, with the part each plays.
| Stakeholder | Part | Why | Its register |
|---|---|---|---|
| Organisations running PHP | owner | Chose or inherited the version. | 26 risks |
| Hosting panels and paid long-term support | treater | Paid long-term support and panel vendors are the only fix route for many. | 1 risk |
| Linux distributions and image builders | treater | Backport to the versions their releases ship. | 1 risk |
| CTO | owner | Owns the upgrade budget and the decision to retire. | 3 risks |
| CFO | bearer | Pays for extended support or the upgrade. | 1 risk |
What it arises from
- PHP versions the project no longer fixes. 8.1 and older get no upstream fix; reaching them needs a distribution backport, paid support or an upgrade.
The evidence
| Claim | Status | Fact-check | Sources |
|---|---|---|---|
| All PHP versions from 5 onwards are affected by at least one of the flaws | disputed | A3 Echoed●●●○○○ | NCSC-NL Wiz on X CERT-FR oss-security |
| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | confirmed | A6 Established●●●●●● | CISA |
Treatments
| Treatment | Status | Where |
|---|---|---|
| Distribution backports and paid support for retired versions | partial | Patching: which versions get a fix, and from whom |
| Upgrade to a supported branch | in place | Patching: which versions get a fix, and from whom |
The standards that govern it
| Framework | Control | What it asks | Family |
|---|---|---|---|
| NIST SP 800-53 | SA-22 | Unsupported system components | Frameworks and control catalogues |
| CIS Controls | 2.2 | Ensure authorised software is currently supported | Frameworks and control catalogues |
| NIST CSF 2.0 | PR.PS-02 | Software is maintained, replaced and removed commensurate with risk | Frameworks and control catalogues |
| Cyber Essentials | SUM | Security update management: high and critical updates within 14 days of release; unsupported software removed | Frameworks and control catalogues |
| PCI DSS | 6.3.3 | Critical security patches are installed within one month of release | Management-system standards |
The stories that tell it
- Why can't every version of PHP just be patched?
- Where php2shell stands: many sites dark, millions of attempts, no confirmed breach (through Remote code execution on internet-facing PHP servers)
- Patch at the speed of Metasploit: where php2shell sits on the weaponisation ladder, and the attacks that come second and third (through Remote code execution on internet-facing PHP servers)
On this site: Patching: which versions get a fix, and from whom · The inventory, hour by hour: fixed, vulnerable, still under investigation