On this page
- Is WordPress vulnerable to the new PHP exploit?
- Am I safe because I am on WordPress, Shopify or Cloudflare?
- Is "we are on 8.3" an answer?
- How do I fix it?
- Am I affected? Where you stand right now
- Was anything exploited, and what should I look for?
- What is the follow-up PHP notice from 23 October?
- What is the bug, without the exploit?
If your site runs WordPress, PHP2Shell can affect it, because the two bugs (CVE-2026-109618 and CVE-2026-109619) are in PHP itself, not in WordPress (PHP notice). Updating WordPress, themes or plugins does not fix them (Cloudflare). The fixed PHP releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the notice tells readers to check their vendor for updated packages (PHP notice).
| Fact | Detail | Source |
|---|---|---|
| CVE ids | CVE-2026-109618 (RCE via out-of-memory corruption), CVE-2026-109619 (RCE via stale global state) | PHP notice, GHSA-w8hw, GHSA-6wmf |
| Severity | CVSS v4.0 9.2 for both, per the 20 October pre-announcement | PHP archive |
| Disclosed | 21 October 2026, 14:00 UTC | PHP archive |
| Fixed releases | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | PHP notice |
| Older PHP | 8.1 and older get no updates from the project. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1 | PHP notice |
| In scope | All PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed | PHP notice |
| WordPress or plugin updates | Do not fix it, per Cloudflare | Cloudflare |
| Exploitation status | We found no confirmed, named compromise in the primary sources we read, at our check on 24 October 2026. Evidence label: absence from the sources read, not a finding about any site | PHP notice, Cloudflare, UK NCSC |
| Checked | 24 October 2026 | this page |
Is WordPress vulnerable to the new PHP exploit?
WordPress is a PHP application. Every WordPress and WooCommerce site runs on a PHP runtime, and the PHP project's notice says all PHP installations serving web requests are in scope. The same notice calls mod_php the highest-risk setup, because in the demonstrated case an unauthenticated request can trigger the attack before any application code runs.
That last point matters for WordPress owners. A hardened WordPress, a firewall plugin or a fully updated plugin set sits above the layer where the bug lives. The Cloudflare post says it plainly: these flaws are in the PHP runtime, so updating website code or a plugin alone does not fix them.
Am I safe because I am on WordPress, Shopify or Cloudflare?
None of the three answers the question by itself. The question is which PHP runtime serves your domain, and whether it carries the fix.
| You are on | What it settles | What it does not settle |
|---|---|---|
| WordPress or WooCommerce | Your site runs PHP, so it is in scope | Whether the PHP under it is patched. Only the server or host can tell you |
| Cloudflare | Cloudflare says free and paid WAF customers were protected by default from 21 October 03:02 UTC. On a Professional, Business or Enterprise plan, Cloudflare says to review your Managed Ruleset deployment and confirm it has deployed block mode (Cloudflare) | Cloudflare says to patch PHP anyway. Its post calls the WAF defense-in-depth |
| Shopify | We found no Shopify statement on PHP2Shell, so we do not say what its storefronts run | Apps, scripts and any separate site you run, such as a WordPress blog on a subdomain, are their own question |
Cloudflare also states a limit in its 23 October update: customers who changed session.upload_progress.name are not covered by its rule for a related issue, CVE-2026-115560 (Cloudflare). We cover that issue below.
Is "we are on 8.3" an answer?
WordPress's own Site Health screen is a good first look, and it lives under Tools, Site Health, Info, Server (WordPress documentation). The documentation says changing many of those settings may need your hosting provider, because they are often managed at server level. That is also true of the fix.
A version string cannot prove a patch on its own. The PHP notice says some distributions and LTS vendors provide backported fixes and tells readers to check their vendor for updated packages. A panel that shows "8.3" does not say whether the package behind it has the fix.
How do I fix it?
If a host manages PHP for you
On shared and managed WordPress plans the host usually owns the PHP runtime, and which WordPress hosts patch for you differs a lot. Send support this question and keep the reply:
For [your domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package, build or backport identifier, confirm that all PHP workers serving my site have been restarted or replaced, and tell me whether I need to change a setting or redeploy.
- Send the question and save the reply with its date.
- Ask which PHP version your site is set to, and whether that selectable version is the one that was fixed.
- After the host confirms, load your checkout, login and a form, and watch for errors.
Host-by-host status pages are collected in our October incident roundup. "Nothing published" means ask support. It does not mean patched or unpatched.
If you manage the server yourself
- Update PHP from your distribution or vendor, or move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (PHP notice). See the PHP fix guide.
- If you run PHP 8.1 or older, ask your vendor for a backport, or plan a move to a supported branch. The PHP notice says the project no longer ships updates for those branches.
PHP lists interim measures for sites that cannot patch today, such as session.upload_progress.enabled=0 set before request parsing, followed by a restart of every worker. The PHP notice says only an update is a complete solution. The UK NCSC advises patching internet-facing systems first, and considering taking a system offline if neither the update nor the mitigations are possible. For the wider picture, see /learn/php2shell.
Am I affected? Where you stand right now
Am I affected? Where you stand right now
A check from outside can read public hints about the technologies a site serves. It cannot see the PHP build, a vendor backport, which runtime serves your domain, or whether workers restarted.
- Detected Your site serves PHP and the exposed version is below the fixed release for its branch. Ask your host the question above, or update and restart yourself.
- Unknown Your site runs WordPress but hides the PHP version, or shows one that could be a backport. This is the common case. Get the package or build identifier and the restart time from whoever runs the server.
- Confirmed by owner evidence You have the fixed package or build identifier naming both CVEs, and a restart or redeploy time after it. The remaining question is whether anything happened before your patch.
No scan, ours included, moves you from "unknown" to "confirmed".
Was anything exploited, and what should I look for?
We did not find a confirmed, named compromise in the primary sources we read for this page, at our check on 24 October 2026. That is a statement about what is published. It says nothing about your site. Cloudflare says its WAF rules were live from 21 October 03:02 UTC, before the 14:00 UTC disclosure (Cloudflare).
If your PHP was unpatched and reachable, look at your own site. WordPress's documentation lists new users you did not create among the signs of a compromise, and advises taking a snapshot of the environment before you start cleaning (WordPress documentation, checked 24 October 2026). An update changes the PHP runtime. It does not review your site's files for you. If you find an account you do not recognise, tracking down a hidden admin user has its own steps.
What is the follow-up PHP notice from 23 October?
PHP published an informational advisory on 23 October about session upload progress, tied to CVE-2026-115560. It suggests setting session.upload_progress.enabled=0 until the next regular release, and says a full advisory will follow with that release (PHP archive). Cloudflare says the issue also affects fully patched releases such as 8.5.12 (Cloudflare). It is a separate CVE from the two PHP2Shell ones. If you applied PHP's 21 October mitigation, the PHP notice says no further action is needed.
What is the bug, without the exploit?
Per the PHP notice, CVE-2026-109618 comes from out-of-memory handling that can interrupt PHP while internal request data is only partly set up. CVE-2026-109619 comes from request state that survives after the memory behind it was freed. Both are in the engine, so no WordPress setting changes them. We do not reproduce attack steps, and you do not need them to fix a site.
Once PHP is patched, hardening WordPress after a PHP incident and the other WordPress guides are the next step. For related reading, see who is responsible for patching your site.
Questions people ask
Is WordPress vulnerable to the new PHP exploit?
WordPress runs on PHP, so a WordPress site on an unpatched PHP runtime is in scope. The flaws are in PHP itself, not in WordPress core, themes or plugins. The fix is a patched PHP on the server and a restart of the PHP workers.
Will updating WordPress, WooCommerce or my plugins fix PHP2Shell?
No. Cloudflare's own post says updating website code or a plugin alone does not fix these vulnerabilities. Keep updating them for other reasons, but the PHP package on the server is what needs to change.
My site is behind Cloudflare. Do I still need to patch PHP?
Yes. Cloudflare says customers should patch their PHP even with its WAF protections, which it calls an additional layer of defense-in-depth. A WAF sits in front of the server and does not change the PHP running on it.
Does my host have to patch PHP or do I?
On shared and managed WordPress hosting the host usually owns the PHP runtime, so ask them. On a VPS or dedicated server you manage yourself, the update is yours. If you are not sure which you have, ask support in writing.
How do I check the PHP version my WordPress site runs?
In the dashboard, open Tools, then Site Health, then Info, then Server. Treat what you see as a clue. It cannot tell you whether the build includes the fix or whether the workers restarted, so ask your host to confirm both.
Sources
- PHP security notice, 21 October 2026 (php.net)Names both CVEs, the fixed releases and the scope. Also carries the 23 October informational advisory on session upload progress.
- GHSA-w8hw-w9fx-j79w: CVE-2026-109618 (php/php-src advisory)
- GHSA-6wmf-4rv5-p3rp: CVE-2026-109619 (php/php-src advisory)
- Cloudflare: PHP vulnerabilities and WAF protection (blog, 21 October 2026, updated 23 October)Vendor statement about its own WAF rules. Says PHP still needs patching.
- UK NCSC: critical security issue affecting PHP (21 October 2026)
- WordPress documentation: Site Health screenWhere the Server section lives in the dashboard.
- WordPress documentation: FAQ My site was hackedLists new users you did not create as a sign of compromise, and advises a snapshot before cleaning.
Facts on this page are dated and point at the primary source next to them. If a vendor status changes after the date shown, the vendor's page wins; tell us at support@run.cloud and we will update it.