On 21 October 2026 the PHP project released emergency security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, together nicknamed PHP2Shell. The PHP2Shell vulnerabilities allow someone with no account to run their own code on a web server, which is as serious as a web vulnerability gets. The Canadian Centre for Cyber Security, the Government of Canada’s cyber security agency, issued an alert the same day, and some federal websites were taken offline as a precaution while they were patched.
If your website is hosted with WebCrafters, there is nothing you need to do. Every WebCrafters server running PHP 8.x or PHP 7.4 was patched on 21 October 2026, and an audit of every server afterwards found no sign that any of them had been attacked. This article explains what the vulnerabilities are, where they came from, what the Cyber Centre recommends, and what to do if you look after a server yourself.
The short version
- Two flaws in the core of PHP, the language that runs WordPress, WooCommerce, Laravel and most of the web, let an attacker run code on the server without logging in.
- They are rated 9.2 out of 10 on the CVSS v4.0 scale, which is the critical band.
- Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches only get patches from hosting vendors.
- A proof of concept exists. As of 23 October the Cyber Centre and CISA had not confirmed active exploitation, but both say that can change fast.
- All WebCrafters servers running PHP 8.x and 7.4 are patched, and an audit afterwards found none of them had been attacked. Customers on WebCrafters Cloud need to take no action.
- A lower-risk third issue, CVE-2026-115560, was published on 23 October. It does not affect a standard WordPress setup and has a one-line interim fix.
What the PHP2Shell vulnerabilities actually are
Both flaws live in the part of PHP that handles memory for each request, code that nearly every page load touches. They are a type of bug called use-after-free, where the program keeps using a piece of memory after it has been released. In the wrong hands, that lets an attacker steer what the server does next.
- CVE-2026-109618 is triggered when a request pushes PHP past its memory limit at the wrong moment. PHP is interrupted while its internal data for that request is only half built, and the clean-up step then treats the half-built data as real. On Apache with mod_php, a single unauthenticated request can set this off before the website’s own code has run, and the researchers demonstrated full remote code execution with default settings.
- CVE-2026-109619 is triggered by a fatal error at the wrong point. Internal state from one request survives after its memory has been freed, and the next request handled by the same worker process can use that stale state. A reporter demonstrated code execution against a real application.
Every way of serving PHP on the web is affected, including PHP-FPM, which WebCrafters Cloud uses, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP security team rates mod_php as the highest risk because the attack can land before any application code runs.
How serious is a 9.2
The Common Vulnerability Scoring System is the industry’s standard way to rate how bad a flaw is. A score of 9.2 means the attack needs no account, no user interaction and no special conditions beyond a reachable PHP server, and the result is complete control of that server. For comparison, a leaked report before the release claimed a 10.0, which the PHP team corrected to the official 9.2.
What makes this one unusual is its reach. The underlying bug has been in PHP since 2004, so every version in use anywhere was vulnerable until patched, and PHP runs roughly three quarters of the websites whose server language is known.
Where the vulnerabilities came from
The PHP Foundation published a detailed account of the discovery on the day of the release, and it is the primary source for this section. The root cause was first noticed during a 2024 security audit by Quarkslab, organized by OSTIF and funded by Germany’s Sovereign Tech Agency, although at that time it was not thought to be exploitable.
In August 2026 the security firm Calif, during its own audit of PHP, reported an unconditional remote code execution bug built on that memory behaviour. Wiz reported the same root cause on 24 August, and OpenAI’s security team reported it independently on 18 September, later adding further attack paths. From 11 August fixing it became the PHP security team’s top priority.
The release was planned for 22 October. On the afternoon of 20 October the two CVE numbers started circulating on forums and social media with incorrect details, so PHP brought the release forward by a day. That evening Calif mistakenly published a video showing its proof of concept, copies spread, and a container vendor broke the embargo by publishing patched images six hours early. By the official release at 14:00 UTC on 21 October no working exploit was public, but the race was on.
The Foundation has been open about what went wrong internally, calling the delay in fixing the memory issue a structural failure, and it has set out changes, including an ecosystem security team created in May 2026, new staff dedicated to security, majority decision-making on fixes and earlier involvement of Foundation leadership in hard cases.
Which PHP versions fix the PHP2Shell vulnerabilities
| PHP branch | Fixed version | Status |
|---|---|---|
| 8.5 | 8.5.12 | Supported, new release |
| 8.4 | 8.4.27 | Supported, new release |
| 8.3 | 8.3.36 | Supported, new release |
| 8.2 | 8.2.35 | Supported, new release |
| 8.1 | Vendor backport | End of life, patched by hosting vendors |
| 8.0 | Vendor backport | End of life, patched by hosting vendors |
| 7.4 | Vendor backport | End of life, patched by hosting vendors |
PHP 8.1 and older reached end of life before this release, so the PHP project did not publish new versions for them. Instead the package maintainers for Ubuntu and Debian, and vendors such as CloudLinux and cPanel, backported the fix into their existing packages. On those branches the version number does not change, which is why a host has to confirm the package revision rather than the version.
What this means for WebCrafters customers
Every WebCrafters server running PHP 8.x or PHP 7.4 was patched on 21 October 2026, and no action is needed from customers. After the patches went on, we audited every server for signs of an attack, including the process, file and log checks the Cyber Centre and CISA recommend, and found none. Websites on WebCrafters Cloud run on PHP-FPM behind a web application firewall with Imunify360 scanning, which reduced exposure while the patches went on, and the patches themselves close the flaws.
- You do not need to update WordPress, your theme or your plugins for this. The fix is in PHP on the server.
- Sites on PHP 7.4 received the vendor backport. We still recommend moving to PHP 8.2 or newer, because 7.4 no longer receives regular security updates, and we handle that move as part of a care plan or on request.
- The third issue, CVE-2026-115560, only applies to applications that change the session serialize handler at runtime, which a standard WordPress or WooCommerce site does not do.
- If your site is hosted elsewhere, ask your host which PHP version and package revision it runs, and whether PHP-FPM or Apache was restarted after the update. A patch that is installed but not restarted is not active.
If you look after a server yourself
| Step | What to do | Why it matters |
|---|---|---|
| 1 | Find every place PHP runs | Web servers are the obvious ones, but appliances, containers and products that bundle their own PHP are easy to miss, and CISA calls them out specifically. |
| 2 | Update to a fixed version | 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On Ubuntu or Debian with the usual PHP packages, refresh the package list and upgrade every installed PHP package. On 8.1 or older, confirm the package revision carries the backport, then plan a move to a supported branch. |
| 3 | Restart every worker | The package upgrade restarts PHP-FPM, but queue workers, cron scripts and anything long-running keeps the old code in memory until it is restarted. |
| 4 | Apply the interim setting | Add the line shown below this table to php.ini or the FPM pool configuration and restart. It also covers the second PHP2Shell flaw on systems you cannot patch straight away. |
| 5 | Check the logs | Look for PHP worker processes starting shells, unexpected files or accounts, and outbound connections from the web server. CISA published a detection rule on 23 October. |
| 6 | Keep a firewall in front | It lowers exposure while you patch, and it keeps stopping the scanners afterwards. |
session.upload_progress.enabled=0The PHP team also lists mitigations for systems that cannot be patched immediately, such as removing the memory limit and lowering the maximum request size, but it is clear that these reduce risk rather than remove it. Patching is the fix.
What the Canadian Centre for Cyber Security recommends
The Cyber Centre published alert AL26-026 on 21 October and updated it on 23 October to cover the third issue, alongside the shorter advisory AV26-1070. Its recommended actions are worth reading in full, and they come down to this.
- Update affected PHP installations immediately to a fixed, supported release.
- Prioritize internet-facing systems and applications that process untrusted input.
- Identify third-party products, appliances and containers that include vulnerable PHP components.
- Where a fix cannot be applied right away, consider isolating internet-facing applications from public networks until it can.
- Monitor for compromise by reviewing web server, application, authentication and endpoint logs, and investigate unexpected processes, files, accounts and outbound connections.
- Keep watching vendors for security updates, including for appliances and services that bundle PHP.
- Report related activity through My Cyber Portal or by email to [email protected].
CISA in the United States issued a matching alert and goes one step further, advising that a PHP system which cannot be patched, or that runs PHP 8.1 or older without a vendor patch, be taken offline until it can be.
The third issue, CVE-2026-115560
On 23 October PHP published a separate advisory for a lower-risk flaw in the session upload progress feature. It can only be exploited when an application sets the session serialize handler to one value in its configuration, switches it to another at runtime before starting the session, and still has upload progress enabled. That is an uncommon combination, and a standard WordPress site does not do it. PHP will fix it in the next regular release. Until then, the interim setting shown above turns the feature off, and anyone who already applied it for PHP2Shell is covered.
How to check which PHP version your website runs
- WordPress. Open Tools, then Site Health, then the Info tab, and look under Server for the PHP version.
- Plesk. Open the website in Plesk and the PHP version is shown on the overview, where it can also be changed.
- Command line. Run php -v on the server. On 8.1 or older, check the package revision instead, since the version number stays the same after a backport.
A safe reading is 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer. Anything older on a supported branch means the server has not been patched yet, and the host should be asked why.
Frequently asked questions
The flaw was in PHP itself, which WordPress runs on, so every PHP server in the world needed the patch and it is the host who has to apply it. The good news for WebCrafters customers is that we audited every server after the release, found no sign that any of them had been attacked, and patched all of them on 21 October 2026, covering PHP 8.x and 7.4. Sites hosted with us need nothing done.
No. PHP2Shell is a flaw in PHP itself, which sits underneath WordPress. Updating WordPress, themes or plugins does not fix it and is not needed for it. Keeping them updated is still good practice for other reasons.
A web application firewall reduces exposure by dropping known attack patterns before they reach PHP, and both CISA and the Cyber Centre recommend one as a temporary layer. It does not replace the update. The only full fix is a patched PHP version.
Those versions are out of support, so the PHP project did not release new versions for them. Vendors such as CloudLinux, cPanel and the Ubuntu and Debian package maintainers shipped backported patches, and WebCrafters applied them on every server running 7.4. If you host elsewhere, ask your host to confirm the package revision is patched, and plan a move to PHP 8.2 or newer.
In WordPress, open Tools, then Site Health, then the Info tab, and look under Server. In Plesk, open the website and look at the PHP version shown on the overview. A fixed version is 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer. On older branches the number does not change, so the host has to confirm the patch.
A proof of concept exists and a video showing one leaked before the release. As of 23 October 2026 the Canadian Centre for Cyber Security had not identified active exploitation, and CISA had not observed it in the wild, while one security vendor reported seeing attempts against its honeypots. Both agencies say that can change quickly, which is why patching came first.
Not sure which PHP version you run?
Let us check your website and update PHP safely
We can check your PHP version, test your site on a newer one and move it over without breaking anything. Our WordPress hosting keeps PHP up to date for you.
Sources
- The PHP Foundation, Today’s PHP security release and how we are strengthening PHP security, 21 October 2026
- php.net, security release announcement and the 23 October advisory for CVE-2026-115560
- Canadian Centre for Cyber Security, alert AL26-026, critical vulnerabilities impacting PHP
- Canadian Centre for Cyber Security, PHP security advisory AV26-1070
- CISA, Critical vulnerabilities in PHP require immediate patching
