php2shell: what to do if your website runs on PHP

What happened

The PHP security team published fixes for CVE-2026-109618 and CVE-2026-109619 on 21 October 2026 and rates both CVSS v4.0 9.2, critical. Both can allow unauthenticated remote code execution: an attacker who can send requests to your site may run their own code on the server with the web server's permissions (PHP security release).

• CVE-2026-109618 (memory corruption when PHP runs out of memory): in PHP's words, “out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.”
• CVE-2026-109619 (stale state between requests): “request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.” PHP also lists memory disclosure as a confirmed impact, which can expose passwords, tokens and API keys held by the server (Tenable FAQ).

The CVE numbers leaked on 20 October, so PHP moved the release forward by a day. Cloudflare reported early attacks on 21 October, and watchTowr reported exploitation attempts against both flaws (Tenable FAQ). Treat this as urgent.

Is your site affected?

Very likely, if it runs on PHP and the PHP version has not been updated since 21 October. PHP says all installations serving web requests are at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers mod_php the highest risk, with a demonstrated exploit that runs before any application code (PHP security release).

• Which applications: any PHP application, including WordPress, Drupal, Joomla, Magento and Laravel. The flaw is in PHP itself, not in your theme or plugins (Patchstack).
• Which versions: Wiz, which reported the bugs, says every PHP version back to 5.4 is affected by at least one of the two (Patchstack).
• Not affected: sites that do not run PHP, such as static sites and most sites on Vercel, Netlify, Cloudflare Pages or GitHub Pages. The websites we build and host in our website package do not run PHP.

Which PHP versions are fixed

• PHP 8.5: fixed in 8.5.12
• PHP 8.4: fixed in 8.4.27
• PHP 8.3: fixed in 8.3.36
• PHP 8.2: fixed in 8.2.35 (PHP 8.2 reaches end of life on 31 December 2026)
• PHP 8.1 and older: no official release. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1; some Linux distributions and long-term-support vendors ship their own fixed packages. Versions 5.4 to 7.3 get no fix from the PHP project at all.

Linux distributions often keep their own version numbers and backport fixes. On a server that uses distribution packages, check your distribution's security advisory rather than comparing version numbers alone.

How to check your PHP version

• WordPress: in the admin, open Tools → Site Health → Info → Server. The PHP version is listed there.
• Shared hosting: your hosting control panel (cPanel, Plesk, DirectAdmin or your host's own panel) shows the PHP version per site, usually under “PHP version” or “PHP settings”.
• Your own server: the web server can use a different PHP than the command line. Check the version your site actually runs, for example with your host's panel or the X-Powered-By header if it is shown, not only php -v.

What to do today

On shared or managed hosting

Your host updates PHP, not you. Ask them today, in writing, whether the PHP version your site uses already includes the fixes for CVE-2026-109618 and CVE-2026-109619. If the panel lets you choose the PHP version, switch to the newest fixed version your site supports.

On your own server or VPS

1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's fixed package.
2. Restart every PHP process: PHP-FPM pools, Apache with mod_php, LiteSpeed. A running worker keeps the old code until it restarts.
3. Rebuild and redeploy containers. A Docker image built before 21 October still contains the old PHP.
4. Check everything that bundles PHP: staging sites, old projects, control panels and webmail.

On PHP 8.1 or older

Plan the upgrade to a supported version now. Until then, ask your host or vendor for a backported fix, or take the site offline if it holds anything sensitive. Patchstack also warns against unofficial “fix” plugins and copied code snippets (Patchstack).

If you cannot update right away

PHP published interim settings that reduce exposure. In PHP's own words, “only an update is a complete solution”: these measures “do not make an installation safe” (PHP security release).

; CVE-2026-109619
session.upload_progress.enabled = 0
; PHP 8.5 only
fatal_error_backtraces = 0

; CVE-2026-109618: no memory limit applications can override, and small request bodies
php_admin_value[memory_limit] = -1   ; FPM pool syntax
post_max_size = 8M                   ; 32M if the site needs uploads

• Keep upload_max_filesize below post_max_size, and limit request size, field count and multipart parts at the web server or proxy.
• With memory_limit = -1, set a container or cgroup memory limit instead. PHP says not to use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable failure.
• Cloudflare deployed WAF rules for known attack patterns, also on free plans. They are a stopgap and only help if your server accepts traffic exclusively through Cloudflare (Patchstack).

Signs your site may have been targeted

Wiz lists these signs. They are not proof either way (Patchstack):

• unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses;
• unexpectedly large or malformed PHPSESSID cookies;
• PHP workers restarting without explanation.

If you see them, or if your site ran an old PHP version that was exposed to the internet after 20 October, update first and then treat the server as possibly compromised. Change the passwords and keys it holds (database, WordPress admin accounts, the salts in wp-config.php, API keys and payment credentials), look for administrator accounts and files you did not create, and restore from a clean backup if in doubt.