Two critical flaws in PHP itself have sent site owners and governments scrambling this week, and every WordPress site running on an unpatched PHP version is exposed. Updating WordPress or its plugins will not fix it. The fix has to happen at the server level, and a security plugin adds a useful layer of detection on top.
On 20 October 2026, the PHP project announced an upcoming security release covering two critical vulnerabilities. Public reports soon indicated that the flaws could lead to remote code execution.[1] Details leaked ahead of the planned disclosure, and the PHP team released the fixes on 21 October 2026.[1][8]
Technical details have since been discussed publicly, and early proofs of concept have begun to circulate. According to CERT-EU, that raises the likelihood that attackers are already trying to exploit the flaws.[1]
PHP is used by nearly 70% of websites with a known server-side programming language, and it sits behind platforms such as WordPress.[9] That is why the impact has been so wide.
Several governments took public sites offline as a precaution while they applied patches. Reports named Germany, Finland and Belgium, and the Netherlands took several public health institute sites down.[6] In France, multiple prefecture websites were taken offline, and the Interior Ministry said security measures were being put in place.[7]
CERT-EU also advised that organizations that cannot patch immediately should consider isolating internet-facing applications from public networks until a fix is applied and verified.[1] If you have seen a site in maintenance mode this week, this is likely the reason.[5]
| CVE | What it is | Severity |
|---|---|---|
| CVE-2026-109618 | Memory corruption during out-of-memory handling, which can lead to remote code execution | CVSS 9.2 |
| CVE-2026-109619 | Stale global state that survives after its memory is freed, which can lead to remote code execution | CVSS 9.2 |
Every PHP setup that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest-risk setup.[1] Because the flaws sit in the PHP interpreter and not in any single application, even a site with secure code is exposed if the PHP version underneath is vulnerable.[2]
WordPress powers roughly 40% of all websites, and every WordPress site runs on a PHP server.[8] The flaw is not in WordPress, but a vulnerable PHP version beneath it can still put the site at risk.
The most important point for site owners is this: updating WordPress core, themes or plugins does not update PHP. PHP runs on your hosting server, so the update happens in your hosting account or through your hosting provider.[4] Wordfence has made the same point, noting that site owners need to find out who manages PHP for them.[8]
In your WordPress dashboard, go to Tools, then Site Health, open the Info tab and expand the Server section. This shows the PHP version your site is running.[4]
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.[1] Many managed hosts apply these fixes themselves, but it is worth confirming that the patch is installed and not just scheduled. Ask your hosting or IT provider to verify this across all your websites and applications.[5] If your host lets you switch PHP versions in cPanel, confirm the version you pick includes the patch.[3]
PHP 8.1 and older no longer receive regular updates from the PHP project. Some distributions and long-term support vendors provide backported fixes, so check with your vendor or upgrade to a supported version.[1] Before upgrading, test your theme and plugins on a staging site to avoid compatibility issues.
Only an update fully fixes these flaws, and temporary mitigations do not make an installation safe.[1] One confirmed mitigation step is to disable session.upload_progress.enabled and restart PHP workers, which blocks a known exploitation path for CVE-2026-109619.[10] Some Cloudflare plans, including the free one, also include initial WAF rules for the known exploit vectors.[2] Treat these as stopgaps while you work with your host. If neither is possible, discuss taking the site offline until it is updated.[3]
A security plugin such as Wordfence is a sensible extra layer. It will not patch PHP, but it can scan your files for malware, suspicious code changes and backdoors, and alert you if something looks wrong. This matters because a patch does not remove an existing compromise.[3] If a site was exposed before the fix landed, a scan helps you find out whether anything was left behind.
Once PHP is updated, check for unknown admin users, recently modified files, unfamiliar scheduled tasks and unexpected outbound traffic. Keep monitoring for a few weeks, since attackers often move quickly once proof-of-concept code is public.
| Layer | What it does | Does it fix the PHP flaw? |
|---|---|---|
| PHP update (host or server) | Replaces the vulnerable PHP code | Yes |
| WordPress core and plugin updates | Fixes WordPress-level vulnerabilities | No |
| Security plugin (for example Wordfence) | Scans for malware and backdoors, and alerts on suspicious changes | No |
| Edge firewall or WAF | Filters known exploit traffic before it reaches the site | Partly, as a stopgap |
| Backups | Lets you restore a clean copy if a site is compromised | No |
Computan team can review your PHP version, coordinate with your host and check your site for signs of compromise. If you manage your own hosting or work with several vendors, we can run a quick audit of PHP versions, plugins and security settings across your sites. This also applies to agencies that rely on our white-label WordPress support for their own clients. Get in touch and we will help you close the gaps.
This is a server-level problem with a server-level fix. Check your PHP version, confirm your host has applied the patch, move off unsupported versions, and use a security plugin to scan for threats that may already be present.[1][3][4] Acting early is the best way to protect your site, your data and your visitors.
No. WordPress core, theme and plugin updates do not change your PHP version. PHP is updated on your hosting server, either by you or by your hosting provider.
The patched versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive regular security updates, so those sites should move to a supported version or use a vendor that provides backported fixes.
In your WordPress dashboard, go to Tools, then Site Health, open the Info tab and expand the Server section. Your PHP version is listed there. You can also ask your hosting provider.
Many managed hosts apply PHP fixes themselves, but practices vary. Ask your host to confirm that the patch is installed and not just scheduled, and ask which PHP version your site is currently running.
No. A security plugin helps you scan for malware and backdoors and spot suspicious changes, but it does not repair a vulnerability in the PHP interpreter. The PHP update is still required. Think of the plugin as a detection layer that works alongside the patch.
It is possible. A patch does not remove an existing compromise, and exploit code began circulating before fixes were released. After patching, run a full malware scan, review admin users and recently changed files, and restore from a clean backup if you find anything suspicious.
Only an update fully fixes the flaws. In the meantime, you can apply temporary mitigations such as disabling session.upload_progress.enabled, use edge firewall rules where available, and ask your host about isolating the site from public traffic until the fix is verified.
No. They affect PHP itself, so any PHP application serving web requests can be exposed, including Drupal, Joomla, Magento and Laravel sites, if the PHP version underneath is vulnerable.