PHP released 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both are rated 9.2 out of 10 (CVSS v4.0) and let an attacker run code on your server without logging in. The bugs are in PHP itself, the runtime underneath WordPress, so updating WordPress or your plugins won't fix them.
I have WordPress sites on SiteGround, and when this news hit, my only question was whether I was vulnerable. I hadn't heard anything from SiteGround, and working out which PHP version my sites actually run took longer than I wanted it to. This is the quick writeup I was looking for, for developers who know their stack and just want the answer without spending an afternoon on it.
Am I Affected?
Any PHP that serves web requests is affected, however it connects to the web server: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. mod_php (PHP running inside Apache itself) is the worst case, because the demonstrated exploit runs before any WordPress code loads. The leaked video of the exploit tool showed it running code on WordPress 7.1.3, alongside Drupal, Joomla, Magento, and Laravel (Ars Technica), so a fully updated WordPress install is still exposed if its PHP is not patched.
| Branch | Fixed in |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1, 8.0, 7.4 | No release. Source backports, or patched Linux or LTS (long-term support) packages |
| 7.3 and older | No fix |
PHP 7.4 through 8.1 are past end of life, so instead of releases, the PHP security team published minimal source backports: just the fix, which you apply and compile yourself. If you don't build PHP from source, get a patched package from your Linux distribution or an LTS (long-term support) vendor. PHP 7.3 and older get nothing, so moving to a supported version is the only option there.
Checking Your PHP Version
The quickest built-in way is to go to /wp-admin/site-health.php?tab=debug, expand Server, and read PHP version. If you'd like it on the dashboard, the Display PHP Version plugin adds it to the At a Glance widget. I liked this option.
One catch: Linux distributions often add the fix to their existing package without changing the PHP version number. If you install PHP from Debian, Ubuntu, or RHEL packages, check the package changelog for the CVE IDs.
What's the Risk?
CVE-2026-109618: when a request runs out of memory, PHP can abandon it partway through setting up request data, and the cleanup code then treats that half-built data as valid, which leads to code execution. Attackers can trigger it with crafted form uploads, and on mod_php the attack completes before WordPress loads (advisory).
CVE-2026-109619: a fatal error can leave a PHP worker holding a pointer into memory that's already been freed, and the next request on that worker uses it (a use-after-free), leading to code execution or leaked memory contents. Confirmed triggers include session upload progress, which is on by default, and php_value lines in .htaccess on mod_php (advisory).
Details leaked two days before the planned disclosure, and Amazon reported an exploitation attempt as early as October 17 (Tenable's timeline).
What to Do
Update PHP to a fixed version. On managed hosting, confirm your host has patched. On your own server, update through your Linux distribution's packages.
While you're there, move to PHP 8.3 or newer. That's WordPress's recommended minimum, and 8.2 reaches end of life on December 31, 2026.
Hosts handled the news differently. I used to work at WP Engine and still have a test site there, and WP Engine emailed customers to say the patch was applied and that network and server mitigations were in place before PHP's release. SiteGround didn't email me, but its blog post says it added server-level mitigations after PHP's October 20 notice and applied the official fixes on October 21. Site Health on my site now shows PHP 8.2.35, the fixed release for that branch, though since 8.2 is nearing end of life, I'm planning to move to 8.3. If you haven't heard from your host, check its blog or status page, then confirm the version yourself in Site Health.
If You Can't Upgrade Yet
PHP says there are no complete mitigations, but these settings reduce exposure to the confirmed attack paths. They must go in php.ini, the PHP-FPM pool config, or the web server config, because ini_set() and .user.ini apply too late. On shared hosting, that usually means asking your host when they'll patch.
- Set
memory_limit=-1withphp_admin_valueso applications can't override it, and keeppost_max_sizelow (8M, or 32M if you need uploads). - Set
session.upload_progress.enabled=0, and on PHP 8.5,fatal_error_backtraces=0. - Remove obsolete or invalid
php_valuelines from.htaccess. - Restart every PHP worker after any change.
The advisories cover the rest, including why not to cap memory with RLIMIT_AS or RLIMIT_DATA.
