300px.png){kind=small}
php2shell WordPress vulnerability — CVE-2026-109618 & CVE-2026-109619
What happened, who found it, why updating WordPress does not fix it, and how to verify your PHP runtime.
Incident timeline
| When | What |
|---|---|
| Early Oct 2026 | Coordinated research and mitigations underway (Cloudflare reports WAF work ahead of public disclosure with PHP Foundation, OpenAI, and Wiz). |
| 20 Oct 2026 | CVE IDs begin circulating early; PHP project brings pre-announcement forward and moves the release from 22 Oct 14:00 UTC to 21 Oct 14:00 UTC (PHP Foundation). |
| 21 Oct 2026 | Emergency releases: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. CISA urges immediate patching. Wordfence briefly took services offline while applying mitigations. |
| After disclosure | Agencies and vendors publish advisories; PoC and scanning activity reported by multiple national CERTs. Treat unpatched internet-facing PHP as urgent. |
Primary sources: PHP Foundation, CISA, Cloudflare.
CVE-2026-109618 vs CVE-2026-109619
| CVE | Failure mode | Why WordPress updates fail |
|---|---|---|
| CVE-2026-109618 | Out-of-memory (OOM) corruption in PHP memory management / error handling — unauthenticated RCE demonstrated, including paths that can run before application code on mod_php. | The bug is in the PHP binary. Application firewalls and plugin updates cannot replace a patched runtime. Confirm the PHP that serves HTTP — not only CLI — and restart workers after upgrade. |
| CVE-2026-109619 | Stale global / worker state across requests (use-after-free class) — later requests on the same worker can misuse freed memory for disclosure or RCE. |
PHP powers a majority of websites worldwide; WordPress and WooCommerce sit entirely on PHP. A large share of internet-facing PHP still runs unsupported branches (8.1 and older) that need vendor backports or an upgrade path — which is why this incident hits WordPress operators especially hard.
Verification checklist for WordPress owners
- Check the PHP version WordPress sees. In wp-admin open Tools → Site Health → Info → Server and note the PHP version. Compare it to CLI php -v on the same host if you have SSH—they can differ when multiple PHP builds are installed.
- Ask your host the exact patch question. Send: “Is the PHP service serving my site patched for CVE-2026-109618 and CVE-2026-109619 (PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or a vendor backport), and have PHP-FPM/Apache workers been restarted or containers rebuilt?”
- If you are on End-of-Life PHP 7.4, 8.0, or 8.1. The PHP project does not ship full security releases for those branches. Ask for a distribution backport, plan an upgrade to a patched 8.2+ branch, or triage a migration off self-hosted PHP. Expect legacy themes and plugins to break on a hard jump to 8.3/8.4.
- After patching, verify workers and logs. Confirm the live web PHP build again in Site Health. Restart workers if the host has not. Review recent web-server error logs for unexpected memory-limit fatals or anomalous PHP worker behavior while you harden.
What to do next
Need the site stabilized on patched PHP now? WordPress PHP emergency response. Ready to leave self-hosted PHP permanently? WordPress to Shopify or WooCommerce to Shopify.
FAQ