On October 21, 2026, the PHP project released emergency updates for two critical vulnerabilities that can allow an unauthenticated attacker to run code through the PHP service handling website traffic. We first alerted WordPress site owners to these updates in our initial public service announcement. The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, and each has a CVSS v4.0 score of 9.2 out of 10.
These are not vulnerabilities in WordPress Core, a plugin, or a theme. They are vulnerabilities in PHP, the programming language WordPress uses. Updating WordPress will not install the fixes. On most shared and managed hosting, the hosting provider controls PHP. Agencies and site owners who manage their own servers or containers must update the PHP package or image themselves.
PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 contain the fixes. Linux distributions and long-term-support vendors may add the same fixes to packages with older version numbers, so the full package revision and the vendor’s security notice matter. After updating, restart PHP so every running process uses the new code. Containers should be rebuilt and redeployed from an updated image.
The Wordfence Threat Intelligence team reviewed PHP’s patches and tested the vulnerable behavior in PHP and WordPress lab environments. This article documents what has been confirmed, shares our preliminary results, and explains what the vulnerabilities mean for WordPress sites.
Key Takeaways
- Update the PHP service that serves your website. Updating WordPress, a plugin, or a theme does not update PHP.
- Both vulnerabilities can allow remote code execution without authentication. A successful attacker could access the same files, credentials, and data as the website.
- Our testing confirmed that the risk is real, although attacks may need to be adapted to a specific server. For CVE-2026-109619, we ran a confirmed code execution proof-of-concept test in a specially configured PHP lab, while the same proof-of-concept test only crashed a normal optimized build of the same PHP version.
- Use defense in depth. The Wordfence Firewall protects the WordPress application layer. PHP, the web server, the operating system, and the network edge also need their own updates and security controls.
Wait, what is PHP, and what does it have to do with WordPress?
PHP is the programming language WordPress is primarily written in. It runs on the web server and is usually installed and managed by the hosting provider. Updating WordPress does not update PHP.
The Wordfence Firewall protects the WordPress application layer using Wordfence Threat Intelligence. PHP, the web server, and the operating system run outside WordPress and need their own updates and protection. Keeping a WordPress site secure requires all of these layers to work together.
What has been confirmed about the risk
If an affected PHP package serves your site, treat the update as urgent.
Successful exploitation lets an attacker act with the same access as the website itself. That can be enough to read database credentials, alter site files, steal data, or install a persistent backdoor.
PHP confirmed remote code execution for both vulnerabilities. PHP confirmed one CVE-2026-109618 attack path that runs before WordPress starts. CrowdStrike also reports that its private exploit worked reliably across Intel/AMD and Arm systems and against newly restarted PHP workers. We have not independently tested that unpublished exploit. An attack may need to be adapted to a particular server, but that does not make an unpatched server safe.
A large amount of proof-of-concept code and commentary is already circulating. Some is useful, but some is incomplete, misleading, or incorrect. Site owners should rely on PHP’s official advisories and patch rather than waiting to decide whether a particular public exploit applies to their server.
What the two vulnerabilities do
| CVE | What happens | Impact |
|---|---|---|
| CVE-2026-109618 | PHP can mishandle data when a request causes it to run out of memory. | An unauthenticated attacker can corrupt memory and run code. |
| CVE-2026-109619 | A PHP process can keep using data from a completed request after it should have been discarded. | A later request handled by the same PHP process can use that data to run code. |
PHP 8.1 and older no longer receive releases from the PHP project. Some operating-system and long-term-support vendors may still add the fixes. If you use an older branch, obtain an explicit answer from the vendor or move to a supported PHP branch.
What our preliminary testing found
We began testing within hours of the fixes being released and are continuing to study additional attack paths and how reliably they work across common WordPress hosting setups. Our goal is to understand the practical risk to customers still using affected PHP versions.
In a specially configured PHP 8.5.11 Apache lab, CVE-2026-109619 ran a proof-of-concept exploit test against PHP, sent over HTTP and created a temporary text file. This proved code execution in that environment. The same test crashed a normal optimized build of PHP 8.5.11 instead of running code, while fixed PHP 8.5.12 remained healthy.
For CVE-2026-109618, vulnerable PHP 8.5.11 failed while fixed PHP 8.5.12 handled the same proof-of-concept request normally. In separate WordPress 7.1.3 tests with an affected Ubuntu PHP 8.5.4 package, specially prepared requests caused PHP failures or restarts in some setups. We did not independently achieve code execution for this CVE.
What is already clear is that attacks may behave differently on different servers, but an unpatched server should not be considered safe. Install a fixed PHP package and restart PHP.
How to check and update your site
If the PHP service serving your website is older than a fixed release and your vendor has not confirmed that it added the fixes, assume it is affected.
In WordPress, go to Tools > Site Health > Info > Server to see the PHP version used by the website. Do not rely only on php -v at a command prompt; a server can use a different PHP version for websites. Linux and hosting vendors may also add security fixes without changing the main version number, so ask your host or server administrator:
Is the PHP service serving my site patched for CVE-2026-109618 and CVE-2026-109619, and has PHP been restarted?
The first fixed PHP releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Then take the steps that apply to you:
- Managed hosting customers: Ask the host to confirm that both fixes are installed and PHP was restarted.
- Self-managed operators: Update PHP, restart Apache, PHP-FPM, or other PHP services, and rebuild containers from an updated image.
- Agencies and hosting providers: Check every site and environment, including staging sites, origin addresses, and older containers—not only the main public site.
- After updating: Verify the website’s PHP version in Site Health and confirm the complete package revision with the host, operating-system package tools, or image provider.
- Preserve backups and logs: As a precaution, retain backups and preserve web-server, PHP, firewall, and system logs covering at least the 48 hours before the October 21 release through the time PHP was patched and restarted.
- Review delayed updates: If PHP was not patched promptly, review those logs for activity that is unusual for the site and investigate anything suspicious. A lack of obvious entries does not prove that exploitation did not occur.
If you cannot patch immediately, review PHP’s temporary recommendations. They may reduce exposure to particular attack paths, but they are incomplete, may disrupt normal site functions, and do not replace the update.
Where Wordfence fits
The Wordfence Firewall protects the WordPress application layer using Wordfence Threat Intelligence. It can block WordPress-specific attacks that general-purpose security tools may not recognize.
These vulnerabilities affect PHP at the server level, and some attacks can begin before WordPress starts. This is why Wordfence recommends defense in depth: use the Wordfence Firewall together with prompt updates and security controls for PHP, the web server, the operating system, and the network edge. For these vulnerabilities, updating and restarting PHP is essential.
Conclusion
CVE-2026-109618 and CVE-2026-109619 are flaws in PHP, but WordPress runs on PHP. A fully updated WordPress installation can therefore remain exposed if the PHP service behind it has not been patched.
Install a fixed PHP package or a vendor package confirmed to contain both fixes. Restart PHP so all running processes use the new code, and verify the package serving the website.
Wordfence Care and Wordfence Response customers can contact our incident response team if they believe a site may have been compromised. Wordfence Response provides 24/7/365 availability with a one-hour response time.
If you know someone who manages WordPress sites, please share this article and ask them to verify the PHP service behind each site.
Sources
- PHP security release announcement
- PHP advisory: CVE-2026-109618, remote code execution through out-of-memory corruption
- PHP advisory: CVE-2026-109619, remote code execution through stale worker state
- PHP complete security patch
- Wordfence’s initial PHP security update PSA
- CrowdStrike’s PHP2Shell research and portability report
The post Why It’s Urgent to Update PHP on Your WordPress Site: Two Critical PHP Vulnerabilities and What Our Testing Found appeared first on Wordfence.