--- title: "The Critical PHP Security Release (PHP2Shell): What WordPress Site Owners Need To Do Now" url: https://nexterwp.com/blog/php-security-release/ date: 2026-10-23 modified: 2026-10-23 lang: en author: "Aditya Sharma" description: "PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026 to fix two critical remote code execution bugs. Here is how WordPress site owners check, patch and review their sites." image: https://nexterwp.com/wp-content/uploads/2026/10/php-security-release-php-net-advisory.webp word_count: 2214 --- # The Critical PHP Security Release (PHP2Shell): What WordPress Site Owners Need To Do Now ## Key Takeaways - PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix CVE-2026-109618 and CVE-2026-109619, two vulnerabilities that can let an attacker run code on a server without logging in. - WordPress.org says no WordPress update is required or planned, because the vulnerabilities affect any server that hosts a PHP application and WordPress runs on top of the server’s PHP build. - WordPress Site Health shows the full PHP version under Tools > Site Health > Info > Server, and PHP 8.3.35 is vulnerable while 8.3.36 is fixed. - PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are named as at risk, and the advisory says the risk is highest for mod_php because the exploit can run before any application code starts. - Nexter Extension includes Limit Login Attempts, CAPTCHA for the login form and a custom login URL, while Nexter Extension Pro adds Login Email Notification alerts and two-factor authentication. Table of Contents On 21 October 2026 the PHP project shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two vulnerabilities that can let an attacker run code on a server without logging in. WordPress.org published a post the same day asking site owners to update PHP right away, and within hours r/Wordpress and r/ProWordPress filled up with people asking what to do about their own sites. I read the PHP advisory, the two GitHub security advisories behind it, the WordPress.org post and the UK National Cyber Security Centre notice, and turned them into a checklist you can run today. I also explain where a WordPress plugin fits in, because that question comes up in almost every thread. ![PHP.net security advisory for the October 2026 critical PHP release](https://nexterwp.com/wp-content/uploads/2026/10/php-security-release-php-net-advisory.webp)The PHP security advisory published on 21 October 2026. ## What The PHP Project Announced On 21 October 2026 The PHP security team published an advisory titled "Critical remote code execution vulnerabilities, update now". It covers two separate bugs in PHP itself: - **CVE-2026-109618, RCE via OOM corruption.** When PHP runs out of memory at the wrong moment, it can be interrupted while internal request data is only partly set up. The cleanup step that runs afterwards can then treat that broken data as valid. - **CVE-2026-109619, RCE via stale global state.** Some internal state that belongs to one request can survive after its memory has been freed. The next request handled by the same worker can use that stale state before PHP resets it. The advisory says every PHP installation that serves web requests is at risk, and names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The team rates the risk highest for mod_php, where it has a demonstrated exploit in which a request from someone who is not logged in triggers the attack before any application code runs. You will see these bugs called "PHP2Shell". The Dutch National Cyber Security Centre (NCSC-NL) uses that name in a public GitHub repository it published on 21 October, the UK NCSC links to that repository, and most forum threads have picked it up. The PHP project's own advisory uses the CVE numbers only. ## Why WordPress Sites Are Exposed Even Without A WordPress Update WordPress.org was direct about the scope. Its post says the vulnerabilities affect any server that hosts a PHP application, and that no WordPress update is required or planned. WordPress is a PHP application, though. Your core files, your theme and every plugin run on top of whatever PHP build your server provides, so a vulnerable PHP build exposes the whole stack above it. The timing in the advisory matters most. On the confirmed mod_php path, the exploit fires before any application code runs. WordPress has not loaded at that point, so a security plugin, a firewall plugin or login protection inside WordPress never sees the request. The fix belongs one layer down, in PHP. Also Read: [How To Check And Update Your WordPress PHP Version](https://nexterwp.com/blog/how-to-check-and-update-wordpress-php-version/) ## Step 1: Find Out Exactly Which PHP Version You Run You need the full version number, including the last digit. PHP 8.3.35 is vulnerable and 8.3.36 is fixed, so "PHP 8.3" tells you nothing useful. - Log in to your WordPress dashboard as an administrator. - Go to **Tools > Site Health**. - Open the **Info** tab. - Expand the **Server** section. - Read the **PHP version** row and write the full number down. WordPress.org points to this same screen in its post. Many hosts also show the PHP version in their control panel, which helps if your dashboard is unreachable. ![WordPress Site Health Info tab showing the PHP version row in the Server section](https://nexterwp.com/wp-content/uploads/2026/10/php-security-release-site-health-php-version.webp)Tools > Site Health > Info > Server shows the full PHP version. Compare it against this table, built from the php.net advisory and release notes: | Your branch | Fix from the PHP project | Notes | | ----------- | ------------------------ | ----- | | PHP 8.5 | 8.5.12 | Supported | | PHP 8.4 | 8.4.27 | Supported | | PHP 8.3 | 8.3.36 | Supported | | PHP 8.2 | 8.2.35 | php.net lists end of life for 8.2 on 31 December 2026 | | PHP 8.1, 8.0, 7.4 | No official release | The security team published minimal source backports for people who build PHP themselves | If your number matches or beats the fixed release for your branch, these two bugs are patched. If it is lower, read the next section before you assume the worst. ## Why A Lower Version Number Can Still Be Patched This point is my own explanation, and it trips up a lot of people. Linux distributions and LTS vendors received the patches before the public release, according to the advisory. Distributions often ship security fixes by patching the PHP version they already package, and their package keeps the original upstream version number. So a server running a distribution's PHP 8.2 package can be fully patched and still report a number below 8.2.35 in Site Health. The reverse happens too: a custom build can report a recent number and still predate 21 October. Treat the version number as the first check and confirm it one of these ways: - On hosting, ask the host to confirm in writing that the PHP build on your server includes the fixes for CVE-2026-109618 and CVE-2026-109619. Quoting both CVE numbers gets you a precise answer. - On your own server with distribution packages, look for both CVE numbers in the package changelog or your distribution's security tracker. - If you build PHP yourself, confirm the build comes from 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or from the backport branches for older versions, and that it was compiled after 21 October. Write the confirmation date next to each site in your notes. Clients ask for it later. ## Step 2: Get The Patched Build From Your Host ### On Managed Or Shared Hosting You probably cannot install a PHP build yourself, and you should not need to. WordPress.org says your host may already be updating PHP and adding web application firewall rules. Ask them to confirm it: - Check your host's status page or changelog for a note about the 21 October PHP release. - If you find nothing, open a support ticket with two questions: which PHP build is my site running now, and when will it include the fixes for CVE-2026-109618 and CVE-2026-109619? - When they reply, re-check Site Health and keep the reply with the date. Several Reddit threads ask whether a particular host has patched yet. Only your host can answer that for your server, and a dated reply in your ticket settles it. ### On A Server You Manage Yourself - Update PHP through your distribution's package manager or your LTS vendor. Source and Windows downloads are on php.net if you build your own. - Restart every PHP worker, including every PHP-FPM pool and Apache if you use mod_php, so the new binary is the one serving requests. - Confirm the result with `php -v` on the command line and with Site Health in WordPress. A stale FPM pool can keep serving the old build after the package updates. ## Step 3: If You Are Still On PHP 8.1 Or Older The PHP project no longer ships releases for PHP 8.1 and older. Because these bugs are so serious, the security team published minimal source backports for PHP 7.4, 8.0 and 8.1, aimed at people who build PHP from source or have no LTS vendor. Some distributions and LTS vendors provide their own backported fixes, so ask yours first. WordPress.org's post says PHP versions before 8.2 no longer receive security updates, and that if you manage your own hosting on one of them you should consider taking the server offline while you prepare to upgrade. The UK NCSC's current guidance puts it this way: > "If you are unable to apply the temporary mitigations, or applying them would take too long, you should consider taking the system offline until it can be fully mitigated." In my experience the real blocker on old PHP is almost always one plugin or a custom theme that breaks on newer versions. Fixing that one dependency this week costs far less than cleaning up an incident next month. Also Read: [How To Vet A WordPress Plugin Before You Install It](https://nexterwp.com/blog/how-to-vet-a-wordpress-plugin/) ## Step 4: Temporary Mitigations For Server Admins The advisory lists measures that reduce exposure to specific attack paths. It states clearly that only an update is a complete solution. Use these as a bridge for a day or two, and only if you control the server configuration. On shared hosting you usually cannot apply them, so go back to Step 2. For CVE-2026-109618 (OOM corruption), the advisory suggests: - Put a container or cgroup memory limit in place first, as the availability boundary, preferably with a policy that kills only the affected worker. The advisory warns against using `RLIMIT_AS` or `RLIMIT_DATA` instead, because those can cause the vulnerable allocation failure. - Only with that boundary in place, set `memory_limit=-1` in a way applications cannot override, such as `php_admin_value` in the FPM pool or Apache configuration, and check nothing sets a finite limit back. Without the container limit, an unlimited PHP memory limit lets one bad request exhaust the whole server. - Lower `post_max_size`: 8M for sites that do not take uploads, 32M if uploads are needed, with `upload_max_filesize` below it. The advisory also suggests request limits at the web server or proxy level. For CVE-2026-109619 (stale global state), it suggests: - Set `session.upload_progress.enabled=0` in `php.ini`, the FPM pool or server configuration, then restart every worker. The advisory says `ini_set()` and FPM `.user.ini` do not work for this. - On PHP 8.5, set `fatal_error_backtraces=0` and restart every worker. - Remove invalid or deprecated per-request settings that print diagnostics before initialization. Hiding errors with `error_reporting`, `display_errors` or `@` does not help. One WordPress-specific detail: WordPress tries to raise its own memory limit in the admin through `WP_MAX_MEMORY_LIMIT`. A value set with `php_admin_value` cannot be changed from inside WordPress, which is why the advisory recommends that method. Load your heaviest admin screens afterwards to check nothing breaks. ![PHP advisory list of temporary mitigations for CVE-2026-109618 and CVE-2026-109619](https://nexterwp.com/wp-content/uploads/2026/10/php-security-release-php-net-temporary-mitigations.webp)The temporary mitigations listed in the PHP advisory. ## Step 5: Check Whether The Site Was Touched Before You Patched An update stops new attacks on these two bugs. Any site that ran a vulnerable build after 21 October deserves a short review as well: - Look for files with a `.php` extension inside `wp-content/uploads`. That folder is meant for media. - Run `wp core verify-checksums` with WP-CLI to compare your core files against the official WordPress.org checksums. - Open **Users**, filter by Administrator and look for accounts you do not recognise. - Review recently modified files in your theme and plugin folders. - If your host gives you server access logs, read them for unusual POST requests from 21 October onwards. If you find something, WordPress.org links its "FAQ My site was hacked" guide from the same post. Restoring from a clean backup taken before the compromise is safer than deleting suspicious files one by one. ![WordPress Users screen filtered to administrators for an access review](https://nexterwp.com/wp-content/uploads/2026/10/php-security-release-users-administrators.webp)Filter Users by the Administrator role and check every account. ## Where A WordPress Security Plugin Fits A plugin runs inside WordPress, and WordPress runs inside PHP. On the confirmed mod_php path the attack happens before any application code runs, and a plugin cannot replace the PHP binary on your server. Patching PHP is the only fix for these two CVEs. Plugins earn their place in the cleanup review above. File change detection, admin account alerts and login monitoring make it faster to notice that something on the site changed. That applies to our own products too. The free Nexter Extension plugin has Limit Login Attempts, CAPTCHA for the login form and a custom login URL, and Nexter Extension Pro adds Login Email Notification alerts and two-factor authentication. I like these for everyday hardening and walk through them in a separate post. None of them has any effect on CVE-2026-109618 or CVE-2026-109619. Update PHP first, then review the rest of your security setup. ![Nexter Extension Security screen with Limit Login Attempts, CAPTCHA and Login Email Notification](https://nexterwp.com/wp-content/uploads/2026/10/php-security-release-nexter-extension-security.webp)The Nexter Extension Security screen. ## A Checklist For Agencies Managing Many Sites If you look after dozens of sites, a spreadsheet beats memory: - List every site with its host and the full PHP version from Site Health. - Mark each one as confirmed patched, waiting on host, or on PHP 8.1 or older. - Send one ticket per host that covers all your sites with them. - Put the PHP 8.1 and older sites first, since the PHP project offers them source patches only. - Record each host's reply and the date you re-checked the version. That sheet doubles as the record you show clients when they ask what you did this week. ## What This Doesn't Cover - **Exploit details.** I have not described how to reproduce either bug. The GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp have the technical write-up for people who need it. - **Whether attacks are happening in the wild.** Some forum posts say the bugs are being exploited. php.net, the GitHub advisories, WordPress.org and the UK NCSC did not say that when I checked on 23 October, so I have left it out. - **Your host's timeline.** I cannot tell you when a specific host will patch. Ask them and keep the reply. - **PHP 8.6.** PHP 8.6.0 RC4, released the same day, includes the fixes. It is a test release and does not belong in production. - **Other apps on the same server.** Anything else on that server that runs PHP has the same exposure, so patching the server protects all of it at once. ## Suggested Reading - [How To Check And Update Your WordPress PHP Version](https://nexterwp.com/blog/how-to-check-and-update-wordpress-php-version/) - [WordPress 7.1.1 And 7.1.2 Security Releases: What Was Patched](https://nexterwp.com/blog/wordpress-7-1-2-security-update/) - [WordPress.org Now Reviews Every Plugin Release: What The Automated Security Check Catches](https://nexterwp.com/blog/wordpress-plugin-security-review/) - [Best WordPress Security Plugins](https://nexterwp.com/blog/best-wordpress-security-plugins/) - [How To Vet A WordPress Plugin](https://nexterwp.com/blog/how-to-vet-a-wordpress-plugin/) - [Nexter Extension Login Security: Limit Login Attempts And Login Alerts](https://nexterwp.com/blog/nexter-extension-login-attempt-monitoring/) #### Stay updated with Helpful WordPress Tips, Insider Insights, and Exclusive Updates – Subscribe now to keep up with Everything Happening on WordPress! Subscribe ## Frequently Asked Questions **Q: Why does a WordPress site need a PHP update for this security release if WordPress itself was not updated?** A: WordPress runs on top of PHP, so a vulnerable PHP build exposes the whole stack above it, including core files, themes, and plugins. The key detail is that the confirmed mod_php exploit can fire before any WordPress code loads, which means a WordPress security plugin never even sees the request. That is why the fix belongs in PHP first, not inside WordPress. **Q: How do I check the exact PHP version my WordPress site is running?** A: The full version number matters because 8.3.35 is vulnerable while 8.3.36 is fixed. In WordPress, go to Tools > Site Health, open the Info tab, expand Server, and read the PHP version row. Many hosts also show it in their control panel, which helps if the dashboard is unreachable. Compare that exact number against the fixed release for your branch before assuming you are safe. **Q: Can my server still be patched even if WordPress shows an older PHP version number?** A: That can happen. Linux distributions and LTS vendors often backport security fixes into the package they already ship, so the package can be patched while still reporting an older upstream version number in Site Health. The practical check is to ask your host to confirm both CVE-2026-109618 and CVE-2026-109619 in writing, or verify the package changelog or security tracker on your own server. **Q: What should I ask my host after this PHP security release?** A: Ask two direct questions: which PHP build your site is running now, and when it will include the fixes for CVE-2026-109618 and CVE-2026-109619. That matters because only your host can confirm what is actually deployed on your server. If they reply with a date, re-check Site Health and keep that ticket response with your notes so you have proof for clients later. **Q: What should agencies do when they manage many WordPress sites during a PHP security release?** A: A spreadsheet beats memory here. List every site with its host and full PHP version from Site Health, then mark each one as confirmed patched, waiting on host, or on PHP 8.1 or older. Send one ticket per host that covers all sites on that host, and put the older sites first because PHP only offers source patches there. Record each reply and the date you re-checked. **Q: Does a WordPress security plugin protect against these PHP vulnerabilities?** A: Not on the confirmed mod_php path. The attack happens before any application code runs, so a plugin cannot replace the PHP binary or block that request inside WordPress. Plugins still help with cleanup and monitoring though: file change detection, admin account alerts, login monitoring, Limit Login Attempts, CAPTCHA for the login form, custom login URL, Login Email Notification alerts, and two-factor authentication all help spot or reduce other problems after patching.