PHP's security team is shipping fixes for two critical flaws at 14:00 UTC on 21 October 2026, and the patch will only be built for PHP 8.2, 8.3, 8.4 and 8.5. If your product, client portal or marketing site runs an outdated PHP version such as 8.1, 7.4 or something from the 5.x era, there will be no official fix to install. That is a business problem before it is a technical one: somebody has to decide what to do, how much to spend and how fast to move. This guide is written for that person, usually a founder, a CTO with a small team, an agency owner or the one developer still looking after an old client app.
Nothing here needs you to read PHP source code. Where a developer has to run something, the exact command is given. The deeper engineering guides are linked near the end.
Step 1: find out in 15 minutes if your outdated PHP version is in scope
You do not need an audit to answer the first question. You need three facts per application: which PHP version it runs, who installed that PHP, and whether the app is reachable from the internet. Send these questions to whoever runs your hosting, your agency, or your developer, today:
- Which PHP version does each live site, API and admin panel run? Ask for the full number (for example 7.4.33), per application, not "we're on PHP 7".
- Where does that PHP come from? The official php.net builds, a Linux distribution package (Ubuntu, Debian, Red Hat), a hosting control panel such as cPanel, a Docker image, or software that bundles its own PHP.
- Which of these are reachable from the public internet, and which sit behind a VPN or login wall?
- Is there anything we forgot? Old staging copies, a microsite from a past campaign, an internal tool on a spare server, a vendor appliance. Huntress specifically calls out appliances, Windows software that ships its own PHP, and cPanel/Plesk servers as places teams miss.
If you have admin access yourself: in cPanel, the MultiPHP Manager page lists the PHP version per domain. On WordPress, go to Tools > Site Health > Info and open the Server section, which shows "PHP version".
For the developer, this one-liner prints the version and whether php.net still supports that branch:
php -r 'echo PHP_VERSION, " ", PHP_SAPI, " -> ", version_compare(PHP_VERSION, "8.2.0", ">=") ? "on a supported branch (8.2+)" : "END OF LIFE: no php.net fix", PHP_EOL;'We ran it on the official Docker images on 21 October 2026: PHP 7.4 printed 7.4.33 cli -> END OF LIFE: no php.net fix, 8.1 printed 8.1.34 cli -> END OF LIFE: no php.net fix, and 8.4 printed 8.4.26 cli -> on a supported branch (8.2+). Two caveats your developer should know: the command-line PHP can be a different install from the one serving the website, and a distribution package may carry security backports even when the version number looks old. Our guide to checking the PHP version on every server, container and panel covers both properly.
When the answers come back, sort each application into one of three buckets: on 8.2-8.5 (patch when the release lands), on an older branch but from a maintained distribution package (ask the distribution or host what they will ship), or on an older branch with nobody maintaining it. The rest of this guide is about the last two buckets.
Outdated PHP version risks, stated honestly
It helps to separate what is actually known from what is circulating. As of 12:19 UTC on 21 October, before PHP's release:
| Statement | Status | Source |
|---|---|---|
| Two critical flaws, both rated CVSS v4.0 9.2, fix due 21 Oct 14:00 UTC | Confirmed by PHP | php.net advance notice |
| Fixes only for 8.2, 8.3, 8.4, 8.5 | Confirmed (PHP only patches supported branches) | php.net supported versions |
| 8.1, 8.0, 7.x and 5.x are end of life | Confirmed | php.net EOL page |
| The flaws allow remote code execution | Reported by researchers | watchTowr, CERT-EU |
| Every version from PHP 5 onwards is affected | Not confirmed by PHP | Leak; CERT-EU citing a social media post |
| CVE-2026-109618 and CVE-2026-109619 | IDs as reported by researchers; PHP's notice names neither | Leak, watchTowr |
| Fixed versions 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Expected, not confirmed | Mallory, trackers |
| Exploitation in the wild | None reported as of 21 Oct | watchTowr FAQ; not in CISA KEV |
PHP has said it will name the affected and fixed version numbers alongside the release, so parts of this table will change within hours. What will not change is the support policy: php.net's own definition of an end-of-life release is one whose users "may be exposed to unpatched security vulnerabilities".
The scale of old PHP on the internet is large. As The Hacker News reported, a Shodan count by the security company Mallory on 20 October found roughly 884,000 public servers advertising PHP 8.1 or older in their HTTP headers. That is 59% of the roughly 1.5 million servers that showed any PHP version. The Hacker News is careful to say that is a count of banners, not of confirmed vulnerable systems. The same report recalls that when a different PHP flaw, CVE-2024-4577, was disclosed in June 2024, Akamai observed attackers trying it within a day. That earlier bug is also a useful precedent for owners: its fixes covered only the branches supported at the time, and 8.0 and older never got one.
For a business, the practical old PHP version security risks are the usual ones for a server-side code execution bug: customer data read or changed, a site defaced or used to host malware, and the server used as a foothold into anything it can reach. How likely that is for your app depends on details PHP has not published yet, such as whether the flaws need a particular configuration or a login. The full timeline is in our post on what is confirmed about php2shell so far.
Five options for legacy PHP applications
There is no single right answer. The table compares the realistic choices. Effort is relative to each other, because it depends far more on your codebase than on PHP.
| Option | What it gets you | Relative effort | Main trade-off | Suits |
|---|---|---|---|---|
| A. Upgrade to a supported branch (8.4 or 8.5) | Official fixes now and for years | Low to high, depending on how old and how custom the code is | Code changes and testing; old plugins or libraries may block it | Any app you plan to keep |
| B. Distribution or host backports | Security patches on the old version number, if the vendor ships them | Low (it is an update), if available | Only applies to distro-maintained PHP; coverage of these flaws is not confirmed | Apps on Ubuntu, Debian or Red Hat packaged PHP |
| C. Paid extended support | Patches for an end-of-life branch from a commercial vendor | Low to medium to set up | Ongoing cost; a bridge, not a destination; coverage of these flaws not yet stated | Apps that cannot move this quarter |
| D. Isolate or take offline | Removes or shrinks internet exposure immediately | Low | Users lose access, or must use a VPN or login | Internal tools, old microsites, apps with few users |
| E. Rebuild or replatform | A clean, supported stack | Highest | Time; does not protect the old app in the meantime | Apps due for replacement anyway |
A. Upgrade the branch
This is the only option that ends the problem. Aim for 8.4 (security support to 31 December 2028) or 8.5 (to 31 December 2029). Moving to 8.2 gets you this week's fix, but 8.2's own security support ends on 31 December 2026, so you would repeat the exercise in about ten weeks. PHP 8.6 is still a release candidate and not for production. How hard the jump is depends on the starting point: going from 5.6 means rewriting anything that used the removed mysql extension; 7.4 to 8.0 changed how strings and numbers compare; 8.2 deprecated dynamic properties. On WordPress, current core supports PHP up to 8.5, so the usual blockers are old plugins and themes rather than WordPress itself.
B. Backports from your distribution or host
A version number does not always tell the whole story. Ubuntu 22.04, for example, still ships and patches its own php8.1 package (it published 8.1.2-1ubuntu2.27 to its security pocket on 19 October 2026), and Red Hat keeps a PHP 7.4 stream alive for the life of RHEL 8. If your PHP came from one of these, ask the vendor or your host whether they will ship a fix for these flaws, and when. Debian 11's PHP 7.4 is a warning case: its free long-term support ended on 31 August 2026.
C. Paid extended support
Several vendors sell patches for end-of-life PHP, including Ubuntu Pro, Freexian (for old Debian releases), TuxCare and Zend. According to Zend, its PHP 7.4 long-term support runs through December 2026 and its 8.1 support through December 2027. None of these vendors publishes prices on those pages, and at the time of writing none had said whether these two flaws will be covered for older branches, so ask that first. The PHP end of life survival guide compares them in detail.
D. Isolate it
If an app cannot be patched soon, reduce who can reach it. CERT-EU's advisory on these flaws recommends the same thing for systems that cannot be patched right away: cut them off from the public internet until a patch exists. In practice that means a VPN, an IP allow-list, or a login in front of the whole site, or switching off apps nobody really uses. For a forgotten microsite, taking it offline is often the cheapest decision you will make this year.
E. Rebuild
If the app was already due for replacement, this may be the moment, but a rebuild takes months and protects nothing in the meantime. Pair it with D or C for the old system until the switch-over.
Red flags in a plan
Be cautious if the plan you are offered looks like any of these:
- "We'll put a WAF in front, that's it." A web application firewall is a useful layer, but PHP has not published how these flaws work, so no rule written specifically for them can exist yet. A WAF can buy time; it is not the fix.
- "We hid the PHP version." Setting
expose_phpoff removes the version from the HTTP header, which php.net describes as exposing "that PHP is installed on the server". The server is exactly as vulnerable as before. - "We'll upgrade to 8.2." Fine for this week, but its security support ends 31 December 2026. Ask why not 8.4 or 8.5.
- "We'll do it next quarter" with nothing in between. A date for the upgrade needs a stopgap (B, C or D) until then.
- No backup or rollback step. Any upgrade plan without a tested way back is a plan to have an outage.
- Nobody owns it. If the host thinks the agency handles PHP and the agency thinks the host does, nothing happens.
A this-week, this-month, this-quarter plan
This week
- Get the inventory from Step 1 for every application, including forgotten ones.
- Apps on 8.2-8.5: install the fixed release once PHP publishes it, internet-facing first.
- Apps on older PHP: ask your distribution, host or a support vendor whether a fix is coming. Anything with no answer and no maintainer goes behind a VPN, allow-list or login, or offline.
- Confirm you have a recent backup of code and database, stored somewhere the web server cannot write to.
- Ask whoever runs the servers to keep logs and watch for PHP processes starting shells or downloads; the web shell detection and hardening guide shows what that looks like.
This month
- Pick a target branch for each kept app (8.4 or 8.5) and get an estimate after a compatibility scan, not before.
- Start upgrades on a staging copy, beginning with the most exposed app.
- If an app cannot move this month, put a bridge in place (backports or paid support) with an end date.
- Decide which apps to retire rather than upgrade.
This quarter
- Finish the upgrades and remove the temporary isolation.
- Move anything you parked on 8.2 before 31 December 2026.
- Write down who owns PHP updates for each app, and put the next end-of-support dates in a calendar: 8.3 on 31 December 2027, 8.4 on 31 December 2028.
How to brief a developer or agency to upgrade legacy PHP applications
A clear brief gets you a realistic quote and avoids surprises. Ask for:
- Inventory: every app, its PHP version and where that PHP comes from, plus frameworks, CMS, plugins and Composer libraries with their versions.
- A staging copy: the upgrade is done and tested on a copy, never first on the live site.
- A compatibility scan before the estimate: automated tools such as PHPCompatibility, Rector and PHPStan each catch different problems; when we tested them for our end-of-life guide, none caught everything alone. A quick first pass is a syntax check under the new PHP. This command (our test, 21 October 2026) found a removed syntax that PHP 7.4 accepted and PHP 8.4 rejects:
On our sample it printeddocker run --rm -v "$PWD":/app -w /app php:8.4-cli sh -c 'find . -name "*.php" -exec php -l {} \; 2>&1 | grep -v "^No syntax errors"'Parse error: syntax error, unexpected token "{", expecting "," or ";" in ./old.php on line 3. It only finds syntax errors; behaviour changes need the scanners and real testing. - A test list: the five or ten things that must work after the upgrade (log in, checkout, contact form, admin reports, scheduled jobs).
- A rollback plan: how they switch back, how long it takes, and that it has been tried on staging.
- A blocker list: plugins or libraries with no version for the new PHP, and the options for each (update, replace, patch, drop).
- Acceptance criteria: the target branch (8.4 or 8.5), no errors in the logs during the test list, and a named person responsible for future PHP updates.
Where the technical detail lives
This page is the decision layer. The four companion posts go deeper for the people doing the work: the news and timeline, version checks on every kind of server, the end-of-life options and migration workflow, and detection plus hardening while you wait. Hand them to your developer along with the brief above.
If you are facing this with an older PHP app and would like a second pair of hands with the upgrade or plugin compatibility, our studio, Pravinya Studio, is happy to talk it through.
FAQ
Is PHP 7.4 still safe?
PHP 7.4 reached end of life on 28 November 2022, and its last official release was 7.4.33. Any PHP 7.4 vulnerability found since then, including these two if they reach 7.4, gets no fix from php.net. It can only be patched through a distribution that still maintains it (such as Red Hat's PHP 7.4 stream for RHEL 8) or paid extended support.
Is PHP 8.1 still safe to use?
Not on an official build. PHP 8.1 reached end of life on 31 December 2025 (last release 8.1.34) and will not get today's fix from php.net. Ubuntu 22.04's own php8.1 package is still maintained by Ubuntu, so ask Ubuntu or your host what they will ship.
Is upgrading to PHP 8.2 enough?
It gets the fix, but 8.2's security support ends on 31 December 2026. If you are doing the work anyway, target 8.4 or 8.5.
My WordPress site shows an outdated PHP version. What now?
Start with the outdated PHP version WordPress reports under Tools > Site Health > Info > Server, then ask your host which newer PHP versions they offer. WordPress 6.9 and later support PHP up to 8.5, and WordPress itself recommends 8.3 or greater. Test plugins and your theme on a staging copy first, since they are the most likely thing to break.
Does hiding the PHP version protect the site?
No. It hides a header; the outdated PHP version vulnerability is still there for anyone who tries.
Last updated / tested on: 21 October 2026, 12:19 UTC (php.net last checked 12:19 UTC and the php-src security advisories 12:12 UTC; the security release was not yet published). This post will be updated when PHP publishes the affected and fixed versions. Commands tested with the official Docker images php:7.4-cli (7.4.33), php:8.1-cli (8.1.34), php:8.4-cli (8.4.26) and php:8.5-cli (8.5.11).