CVE-2026-109618 and CVE-2026-109619: how to fix the PHP2Shell flaws

On October 21, 2026, the PHP project released emergency fixes for two critical flaws in PHP itself, nicknamed "PHP2Shell." Both can let an attacker who isn't logged in run code on a web server. PHP rates both CVSS v4.0 9.2. Because PHP runs WordPress, WooCommerce, Drupal, Joomla, Laravel, Magento and many portals and appliances, most businesses with a website are exposed somewhere.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), RCE via out-of-memory corruption: when a request runs out of memory at the wrong moment, PHP can treat half-built internal data as valid during cleanup.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), RCE via stale global state: internal state can outlive its memory, so a later request on the same worker uses freed memory.

Yes, if any server you own or pay for runs PHP and answers web requests. PHP says that includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for Apache with mod_php, where a demonstrated exploit works before any application code runs.

Don't forget sites managed by your web agency or host, and appliances or vendor software that bundle PHP.

Serious. Both flaws are unauthenticated remote code execution on internet-facing servers. CISA issued an alert on Oct 21 urging immediate patching and said it had not observed exploitation as of publication. PHP2Shell was not in CISA's Known Exploited Vulnerabilities catalog (version 2026.10.21, checked 6:07 PM CT). Treat it as urgent anyway: PHP's own advisory says there are no complete mitigations, and older PHP flaws (CVE-2024-4577, CVE-2019-11043) ended up in KEV.

1. Inventory. List every website, client portal, intake form and appliance running PHP, including ones a vendor manages. Internet-facing systems first, mod_php first among those.
2. Update. Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's patched package. PHP says Linux distributions and LTS vendors got the patches in advance. If you use rpms.remirepo.net, PHP says it won't have updates today, so switch to distribution packages or build from source.
3. Restart every PHP worker (PHP-FPM pools, Apache) and rebuild container images.
4. Get it in writing from managed hosts and agencies: which version they're on and when they patched.
5. Plan an upgrade for anything on PHP 8.1 or older.

Patch today. CISA says organizations that can't update right away, or that run PHP 8.1 or older, should take PHP-based systems offline until they're patched or upgraded.

• Run php -v (and check phpinfo() or your host's panel for the web SAPI, not just the CLI) on every server and confirm a fixed version or your vendor's patched package release.
• Confirm workers restarted after the update.
• Then hunt, because a patch won't remove a backdoor that's already there. Look for new or modified .php files in web roots and upload folders, unknown admin users in your CMS, PHP or web-server processes launching shells or downloading tools (CISA calls this out), and unusual outbound connections. Keep the logs.

PHP lists stopgaps that reduce exposure to specific attack paths but do not make a server safe:

• For CVE-2026-109618: set memory_limit=-1 in a way apps can't override (e.g. php_admin_value), set a low post_max_size (8M with no uploads, 32M with uploads) and keep upload_max_filesize below it, and enforce request-size limits at the web server or proxy. Don't use RLIMIT_AS/RLIMIT_DATA.
• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or pool config (not ini_set() or .user.ini) and restart every worker; on PHP 8.5 also set fatal_error_backtraces=0.
• Put sites behind a web application firewall. CISA says a WAF may give some protection until you update.
• If none of that is possible, take the system offline (CISA).

Is my WordPress site affected? If it runs on PHP 8.2–8.5 below the fixed builds, or on 8.1 or older, yes. This is a PHP flaw, not a plugin flaw, so updating WordPress alone doesn't fix it. Your server's PHP must be updated.

Is it being exploited? CISA had not observed exploitation at publication on Oct 21, and it's not in the KEV catalog yet. That can change quickly.

Does a php.ini change fix it? No. PHP says only updating is a complete fix.

We use a hosting company. Are we covered? Only if they've patched. Ask them for the version and patch time.

Need help checking your websites today? Contact LayerLogix at 713.571.2390 or layerlogix.com.

• PHP security advisory and releases, Oct 21, 2026: https://www.php.net/archive/2026.php
• PHP Foundation, "Today's PHP Security Release": https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
• CISA alert, Oct 21, 2026: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
• CISA KEV catalog (v2026.10.21, PHP2Shell not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Canadian Centre for Cyber Security AL26-026: https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-109618 and https://nvd.nist.gov/vuln/detail/CVE-2026-109619 (page timed out when checked; CVSS above is PHP's own rating)