The short answer: your server is patched if it runs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a build from your hosting provider or Linux distribution that carries the fix under an older version number. If it runs anything else, it is exposed, and updating the website, its theme or its plugins changes nothing, because the flaws are in PHP itself. Update the server today, restart every PHP worker, and if an update is not possible this week, take the application off the public internet until it is. Attack attempts were seen before the fixes were published, so a server that was unpatched for any time after 21 October 2026 also needs a check for signs of compromise, not only an update.
What Happened, and When
| Date (UTC) | What happened | Source |
|---|---|---|
| 20 October 2026 | The PHP security team announces a critical release for the next day, for two flaws rated 9.2 of 10 on CVSS v4.0, after the existence of the flaws and their identifiers appear on social media ahead of the planned date | PHP, watchTowr |
| 21 October, 03:02 | Cloudflare switches on firewall rules against the known attack methods for every customer, including free plans, about nine hours before the fixes are public, and reports early attack attempts the same morning | Cloudflare |
| 21 October, 13:40 | PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released with the advisory for CVE-2026-109618 and CVE-2026-109619, plus minimal source patches for PHP 7.4, 8.0 and 8.1, which the project no longer supports | PHP, EU joint statement |
| 21 October | The UK’s National Cyber Security Centre tells organisations to update immediately or take affected systems offline; the European Commission, ENISA, CERT-EU and Europol issue a joint statement; Canada’s Cyber Centre publishes an alert | NCSC, ENISA, Cyber Centre |
| 21 October | watchTowr reports exploitation attempts against both flaws on its honeypot network | watchTowr |
| 23 October | PHP publishes an informational advisory for a third, related flaw, CVE-2026-115560, in the session upload progress feature, with a fix promised in the next regular release and a configuration change to apply meanwhile | PHP, Cyber Centre |
The flaws were found by researchers at Calif, Wiz, OpenAI and Quarkslab and reported to PHP for a coordinated release. Both sit in how PHP handles a request that ends abnormally. In the first, a request that pushes PHP out of memory part-way through its setup leaves internal data half-built, and the cleanup code trusts it. In the second, state from one request outlives the memory it points to, and the next request handled by the same worker acts on the leftovers. Either can be turned into code running on the server with the web server’s permissions, with no account and no password. PHP rates the risk highest where Apache runs PHP as a module (mod_php), because a demonstrated attack succeeds before the application’s code runs at all, but PHP-FPM, php-cgi, LiteSpeed and FrankenPHP are all in scope.
Who Is Exposed
PHP is the server-side language of 69.2% of websites whose language is known, according to W3Techs on 25 October 2026. Among those sites, 65.5% run version 8, 26.8% still run version 7 and 7.7% run version 5. The last two groups have no official fix: PHP 7.4, 8.0 and 8.1 received source patches only, for distributions and hosting companies to build into their own packages, and PHP 7.3 and older, including version 5, received nothing. A site on those versions is only safe once its hosting provider has shipped a patched package, or once it moves to a supported branch.
In practice this is a question for whoever administers the server, not the person who edits the website. On shared and managed hosting the provider applies the update; cPanel shipped fixed PHP packages in its EasyApache 4 release and backported the fix to its PHP 7.4, 8.0 and 8.1 packages, and other panels and distributions followed on their own timetables. Many of those packages keep the old version number, so a server that still reports PHP 8.3.35 may already be fixed. The package changelog, or a note from the provider, is the evidence to look for, not the version string alone.
Is It Being Exploited?
The honest answer is that attempts are real and confirmed compromises are not yet documented publicly. Cloudflare reported attack traffic against both flaws on the morning of 21 October and said attackers were changing their payloads to get past its rules. watchTowr reported exploitation attempts on its honeypots from the same day. Canada’s Cyber Centre said on 21 October that a proof of concept exists and that it had not identified active exploitation at that time, and as of its 23 October catalogue the US Cybersecurity and Infrastructure Security Agency had not added either flaw to its list of known exploited vulnerabilities. None of this is a reason to wait: for a flaw that needs no login and works before the application loads, the window between a public proof of concept and automated mass exploitation is normally days.
What to Do Today
- List every system that runs PHP. Websites, intranets, customer portals, ERP and CRM installations such as ERPNext or SuiteCRM, and appliances that bundle PHP without saying so. The Dutch NCSC keeps a public list of products with a PHP dependency. Start with anything reachable from the internet.
- Check the version properly. Ask the hosting provider in writing which package is installed and whether it contains the fix for CVE-2026-109618 and CVE-2026-109619. On a server you control, read the package changelog rather than the version number.
- Update and restart. Install the fixed package, then restart PHP-FPM, Apache or LiteSpeed so every worker runs the new code. A package installed without a restart leaves the old workers serving traffic.
- Apply the 23 October change as well. Set
session.upload_progress.enabled=0and restart the workers. PHP recommends it until the fix for CVE-2026-115560 ships in the next regular release, and it also narrows the second of the original flaws. - If you cannot update this week, reduce exposure. PHP lists partial measures (a low
post_max_size, request limits at the web server or proxy, container memory limits) and states plainly that none of them makes an installation safe. A firewall such as Cloudflare’s blocks the known methods but not traffic that reaches the server directly, and not methods it has not seen. The NCSC’s advice for a system that cannot be patched is to take it offline. - Look for compromise. For any server that was reachable while unpatched, review web server and application logs since 20 October for unusual requests and errors, check for new files in writable directories, new scheduled tasks, new administrator accounts and unexpected outbound connections, and run the host’s malware scanner. Change credentials that lived on the server if anything is found.
- Plan the move off PHP 7. A site on PHP 7 or 5 depends on its host backporting every future fix. The next flaw will come, and the fix for it may not.
| PHP branch | Fixed version | Status |
|---|---|---|
| 8.5 | 8.5.12 | Supported |
| 8.4 | 8.4.27 | Supported |
| 8.3 | 8.3.36 | Supported |
| 8.2 | 8.2.35 | Supported until 31 December 2026 |
| 7.4, 8.0, 8.1 | None from PHP | Source patches only; a vendor package or an upgrade is required |
| 7.3 and older | None | No fix; upgrade |
Where SoftwareBiz fits. Our managed cloud and DevOps service keeps the servers we run for clients on supported versions and applies security releases within an agreed window, with the restart and the log review done as part of the same change. Where a server may have been reachable while unpatched, our cloud security and compliance team runs the compromise check described above and hardens what it finds. If nobody in your company can say today which version of PHP your website runs on, or who is responsible for updating it, that is the finding our architecture and performance audit exists to make, with a written list of every system, its owner and its support status. For a site stuck on PHP 7 because its theme or framework cannot move, our website design and development team plans the upgrade or the rebuild, so the next release lands on a supported platform.
What This Means for a Company That Buys Hosting
Most companies in Pakistan, the Gulf and the UK buy their website hosting as a service and have never had a reason to know what runs underneath it. PHP2Shell is a reason. The provider who patched within hours on 21 October and told customers so is worth keeping; the provider who has not answered the question by now is telling you something too. Ask for the package version in writing, ask when it was applied, and ask what the restart and the log review found. Those three answers tell you whether the service you pay for includes security, or only uptime.