PHP has various global state that temporarily points into request memory
PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE).
Why It’s Urgent to Update PHP on Your WordPress Site: Two Critical PHP Vulnerabilities and What Our Testing Found
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.
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.
Wordfence includes an endpoint firewall, malware scanner, robust login security features, live traffic views, and more. Discover why over 5 million WordPress sites put their trust in Wordfence.
Our business hours are 9am-8pm ET, 6am-5pm PT and 2pm-1am UTC/GMT excluding weekends and holidays.
Response customers receive 24-hour support, 365 days a year, with a 1-hour response time.
This website uses cookies, pixels, and similar technologies (collectively “Cookies”) to improve your browsing experience. By clicking “Accept All”, you agree to the storing of Cookies on your device and that we may share, track, store, and analyze your interactions with the website to enhance site navigation, analyze site usage, and assist in our marketing efforts. For more information on our use of cookies please review our Cookie Policy.
Cookie Settings Accept All Reject All
Cookie Options
For additional information on how this site uses cookies, please review our Privacy Policy. The cookies used by this site are classified into the following categories and can be configured below.
Strictly Necessary
Always active
The “Strictly Necessary” cookies are necessary for the Sites and Services to work properly, and cannot be disabled. They include any essential authentication and authorization cookies for the Services. If you select the “Reject All” button, or choose to do nothing, only the strictly necessary cookies are active by default.
Functional
Disabled via "Do Not Sell or Share My Information" request. This category cannot be enabled.
Your browser is sending a Global Privacy Control signal which automatically disables this category. You may change your browser settings to enable it.
These cookies allow us to remember choices you make, such as your username, language, or region. This helps provide a more personalized and consistent experience by tailoring the Services to your preferences. For example, we can remember your preferred settings or login details, so you don't have to re-enter them each time you visit.
Performance/Analytical
Disabled via "Do Not Sell or Share My Information" request. This category cannot be enabled.
Your browser is sending a Global Privacy Control signal which automatically disables this category. You may change your browser settings to enable it.
These Cookies allow us to collect certain information about how you navigate the Sites or utilize the Services running on your device. They help us understand which areas you use and what we can do to improve them.
Targeting
Disabled via "Do Not Sell or Share My Information" request. This category cannot be enabled.
Your browser is sending a Global Privacy Control signal which automatically disables this category. You may change your browser settings to enable it.
These Cookies are used to deliver relevant information related to the Services to an identified machine or other device (not a named or otherwise identifiable person) which has previously been used to visit our Sites. Some of these types of Cookies on our Sites are operated by third parties with our permission and are used to identify advertising sources that are effectively driving customers to our Sites.
Cancel Save
Do Not Sell or Share My Personal Information
This form enables you to request that we stop selling or sharing your personal information with third parties. "Selling" includes exchanging your information for money or other benefits, while "sharing" refers to providing your data to third parties for targeted advertising purposes. For more information on how we process personal information, please review our Privacy Notice.
When you submit this form, we will:
Immediately disable retargeting and remarketing cookies on your current browser/device
Browser/Device Specific: This opt-out applies to the specific browser from which you submit the request. To opt out on additional devices or browsers, you will need to submit separate requests.
Cookie Management: You may also manage cookies directly through your browser settings, or on our Cookie Control form.
Do Not Sell or Share My Personal Information
Stop selling personal information about me to third parties for monetary or other valuable consideration.
Stop sharing personal information about me with third parties for cross-context behavioral advertising.
Your request has been received. We will no longer share or sell your personal information on this browser.
Cancel Submit
An error occurred while attempting to submit your request. Please try again or contact support.
Alex Thomas
