PHP2Shell (CVE-2026-109618/109619): what IT teams must do now

On 21 October 2026 the PHP project shipped emergency releases for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now widely known as “PHP2Shell”. Either one can let an unauthenticated attacker run code on a web server, and the only complete fix is to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your vendor’s patched package). This is the picture as of the evening of 21 October 2026; things are moving quickly and a public exploit is expected soon.

What happened

Both bugs live in the PHP interpreter itself, so any app on an affected version is potentially exposed.

• CVE-2026-109618 (“RCE via OOM corruption”): when PHP runs out of memory while handling a request, execution can be interrupted while internal request data is only partly initialised. Request cleanup may then treat that invalid data as valid, corrupting memory.
• CVE-2026-109619 (“RCE via stale global state”): internal state belonging to one request can outlive the memory that backs it. A later request handled by the same worker may then use that stale state, a classic use-after-free.

The PHP security team rates both as Critical, with a CVSS v4.0 base score of 9.2. Some researchers have put forward higher scores of their own. Whatever number you go by, the practical answer does not change: patch now.

Technical details began circulating on 20 October, ahead of a coordinated disclosure planned for 22 October, and the PHP team brought its release forward by a day in response.

Impact

A successful attacker gains code execution on your server as the account PHP runs under (for example www-data). In practice that can mean:

• reading configuration files, database passwords, API keys and tokens;
• tampering with or stealing application data;
• planting webshells and other persistence;
• using the server as a foothold to move deeper into your network.

Researchers also showed that worker memory can be leaked without authentication, so sensitive data may be exposed even where code execution does not succeed.

Why mod_php is the biggest worry. According to the official advisory, Apache with mod_php is the most exposed setup: a full exploit was validated against it with default PHP limits, and the attack fires before any application code runs. A well-written app or a fully patched CMS offers no protection here. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are affected too, to varying degrees depending on configuration, and none should be assumed safe.

Potentially affected systems

• web servers running PHP via PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed (LSAPI);
• popular PHP applications and CMSs: WordPress, Drupal, Joomla, Magento, Laravel and Symfony apps, Nextcloud, phpMyAdmin;
• hosting and admin control panels built on PHP;
• Docker containers based on the official php images or other images that ship PHP;
• appliances and commercial products with embedded PHP, including Windows software;
• shared hosting, where the fix depends on your provider;
• end-of-life branches (PHP 8.1 and older), which no longer get regular upstream updates.

What to do now

1. Build an inventory. Find every PHP installation in your organisation, internet-facing first: servers, containers, test environments, hosting panels and products that bundle PHP. Note that php -v on the command line may not reflect the runtime actually serving web traffic.
2. Update to a fixed release: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you rely on distribution packages, apply your vendor’s security update; backported fixes may keep an older version number. Restart or redeploy workers afterwards and confirm they are running the patched runtime.
3. On PHP 8.1 or older, get backported fixes from your distribution or LTS vendor, or plan an upgrade to a supported branch. Avoid unofficial “fix” plugins and copy-pasted patches.
4. If you cannot patch straight away:
   • enable dedicated WAF rules (Cloudflare, for example, has shipped initial rules for known vectors) and cap request size and complexity at the proxy;
   • apply the temporary configuration measures in the PHP advisory, bearing in mind they reduce risk but do not remove it;
   • restrict public access, put the service behind a VPN or into maintenance mode, and if none of that is possible, consider taking it offline;
5. Monitor. Watch for unusual child processes spawned by PHP workers, unexpected worker restarts, repeated server errors and abnormal traffic to web servers.
6. Look for signs of compromise. Check web roots for new or modified files and webshells, and review cron jobs, scheduled tasks and new accounts. Preserve web server and PHP logs. Clean logs are not proof of a clean system.
7. Rotate credentials held on affected servers (database passwords, API keys, secrets) if there is any suspicion of compromise, since worker memory may have been exposed.

The NIS2 angle

If your organisation is an essential or important entity under NIS2, a remote code execution compromise on an internet-facing system may well count as a significant incident that must be reported to the national authority (DNSC in Romania): an early warning within 24 hours of becoming aware of it, and an incident notification within 72 hours. Line up your reporting contact and basic facts now, so a late discovery doesn’t also mean a missed deadline.

Timeline

• 20 October 2026: vulnerability details leak ahead of coordinated disclosure; PHP announces an emergency security release.
• 21 October 2026, morning (UTC): Cloudflare reports early attack attempts and deploys WAF rules; some organisations take services offline as a precaution.
• 21 October 2026, ~14:00 UTC: PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, together with advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.
• 21 October 2026: Rapid7 expects a public exploit soon; the UK NCSC urges organisations to inventory PHP systems, starting with internet-facing ones.

Sources

• PHP security announcement and releases: https://www.php.net/
• php-src GitHub advisories: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w and https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• Rapid7: https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/
• Huntress: https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
• Qualys: https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities
• UK NCSC: https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
• Help Net Security: https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
• Patchstack: https://patchstack.com/articles/php-major-vulnerability-alert-10-2026/

---

If you don’t know how many PHP systems you have exposed, a quick inventory of your attack surface is the first step; ClearSecurity can help with that.