On 21 October 2026, the PHP project released an emergency security update for two critical flaws in the language itself. Both can let an attacker run code on a web server without logging in, and WordPress runs on PHP. If you own a WordPress or WooCommerce site, this is worth ten minutes of your time today.
Last updated: 24 October 2026. This story is still developing, so I will keep this post current as PHP publishes more details.
Key takeaways
- The flaws are in PHP, not in WordPress, plugins or themes. Updating those will not protect you from this.
- Fixed PHP versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches get no official fix.
- Exploit code is circulating and attack attempts have been reported, so treat this as urgent.
- Most site owners only need to confirm that their hosting company has patched PHP.
What happened
PHP warned on 20 October that an emergency release was coming, after details of the bugs reportedly leaked before the planned disclosure date. Security researchers at watchTowr confirmed the flaws were real, and PHP shipped the fixes the next day. Both vulnerabilities carry a severity score of 9.2 out of 10 on the CVSS v4.0 scale.
Public technical discussion and early proof-of-concept code followed quickly, and CERT-EU warned that this raises the chance of real attacks. Several hosting companies and security vendors reported exploit attempts against customers within hours.
The vulnerabilities in plain English
CVE-2026-109618: memory corruption when PHP runs out of memory
When a request goes over PHP’s memory limit, PHP stops it abruptly. If that happens while PHP is still reading a file upload form, the cleanup step can try to free memory that was never properly set up. An attacker may be able to turn that mistake into code execution. PHP says it validated full remote code execution over HTTP on Apache with mod_php, where the problem can be triggered before any WordPress code even runs. PHP-FPM looks susceptible too, although no complete FPM exploit has been shown so far.
CVE-2026-109619: stale data left behind by an earlier request
After some fatal errors, internal data from one request can survive after its memory has been released. A later request handled by the same worker may then pick up that stale data before PHP resets it, which can also lead to code execution.
A third issue: CVE-2026-115560
On 23 October, PHP disclosed a third remote code execution bug. According to CERT-EU, it affects only applications configured in an unusual way, and PHP considers the risk unlikely, so there is no emergency release for it. The full advisory will come with the next regular release. Until then, the advice is to turn off PHP’s session upload progress feature, which is a simple setting that I cover below.
Does this affect my WordPress site?
Yes, if the PHP running your site has not been patched. The flaws sit below WordPress, so every way of running PHP is exposed, including PHP-FPM, Apache with mod_php, CGI and LiteSpeed. WordPress.org has said that no WordPress release is needed for this, because the fix is the PHP update alone. You can read their note in the official WordPress announcement.
Which PHP versions are fixed?
- PHP 8.5: update to 8.5.12 or newer
- PHP 8.4: update to 8.4.27 or newer
- PHP 8.3: update to 8.3.36 or newer
- PHP 8.2: update to 8.2.35 or newer. PHP 8.2 reaches end of life on 31 December 2026, so plan a move to 8.3 or newer.
- PHP 8.1 and older: the PHP project no longer supports these. Some Linux distributions and long-term support vendors add their own fixes, and PHP published minimal source patches for 7.4, 8.0 and 8.1, but the safest route is to upgrade.
How to check your PHP version
In your WordPress dashboard, go to Tools, then Site Health, then the Info tab, and open the Server section. Your PHP version is listed there. Most hosting control panels show it as well.
One caution: many hosts and Linux distributions apply the security fix without changing the version number. A version that looks old does not always mean your site is unpatched, and a number that looks right does not always mean it is safe. If you are unsure, ask your host to confirm in writing that they have applied the 21 October PHP security release.
What to do, based on your hosting
- Managed WordPress hosting: the host updates PHP for you. Check their status page or email for confirmation.
- Shared hosting: the host runs PHP for everyone on the server and will roll out the fix. Confirm that it is done, and use your control panel to pick a supported PHP version if you are on an old one.
- VPS or your own server: nobody will patch it for you. Install the updated PHP packages and restart PHP so every worker runs the fixed version. Some package repositories lag behind, so check where your server gets PHP from.
- Behind Cloudflare: its firewall rules can block known attack patterns, but treat that as an extra layer. Attackers can sometimes reach a server directly, so you still need the PHP update.
If you cannot update right away
PHP is clear that only an update fully fixes these flaws. Some settings narrow specific attack paths while you wait, but they do not make a server safe, and they belong to whoever runs the server. If that is you, the main steps are:
- Turn off session upload progress and restart PHP. This also covers the unusual-configuration issue (CVE-2026-115560). Set it in the server configuration rather than inside your site code.
- Set a low
post_max_size(PHP suggests 8M if you do not need uploads, 32M if you do), and enforce request size limits at the web server or proxy. - For CVE-2026-109618, PHP suggests setting the memory limit in a way applications cannot override and keeping request limits tight. Ask your server administrator to apply this carefully.
session.upload_progress.enabled = 0If you are on shared or managed hosting, do not edit server settings yourself. Ask your host instead.
If your site runs PHP 8.1 or older
Plan an upgrade to a supported version. Older themes and plugins can break on newer PHP, and on a live store a broken checkout costs money. The safe way is to take a full backup, test the upgrade on a staging copy, fix whatever breaks, and then switch the live site.
After you update: a short checklist
- Take a fresh backup.
- Confirm the new PHP version, or get your host’s written confirmation.
- Test your login, contact forms and checkout.
- Update WordPress, plugins and themes as usual.
- Look for unfamiliar admin users, recently changed files and unknown plugins or scheduled tasks.
- If anything looks wrong, restore a known clean backup and change your passwords and security keys.
How I can help
If you would like a second pair of eyes, my Website Security service covers a security audit, malware scan and cleanup, and clear next steps. If you run your own server, my VPS Server Setup service covers hardening and update guidance. You can also send me a message with your site details and I will tell you what I would check first.
Frequently asked questions
Do I need to update WordPress, plugins or themes for this?
No. These flaws live in PHP, so only a PHP update fixes them. Keep WordPress, plugins and themes updated anyway, for other reasons.
Does this mean my site has been hacked?
Not necessarily. A vulnerability means exposure, not compromise. Still, if your PHP was unpatched while exploit code was circulating, it is sensible to run the checks in the list above.
Which PHP version should I use?
Use a version that still gets security updates and that your plugins support. Given that PHP 8.2 ends on 31 December 2026, aim for 8.3 or newer, tested on a staging copy first.
Will updating PHP break my site?
For well-maintained sites it usually goes smoothly. Old plugins and themes are the main risk, which is why a backup and a staging test matter.