Two critical RCEs in PHP core

What it is

"php2shell" is a pair of unauthenticated remote code execution flaws in PHP core, CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2. A plain HTTP request triggers them, and they are exploitable before any application code runs. Cisco Talos says AI-related tooling played a key role in their discovery. As of 14:00 UTC on 21 October 2026, Talos had not seen exploitation in the wild.

How it works

• CVE-2026-109618: out-of-memory handling interrupts PHP while internal request data is only partly initialized. Request cleanup then treats invalid data as valid.
• CVE-2026-109619: a stale internal state is reused after its backing memory was freed, before normal initialization resets it.

The page gives no further exploit detail. It names fatal errors, execution timeouts, session upload progress, and (on PHP 8.5) fatal error backtraces as paths that reach the bug.

Preconditions / Affected

Every PHP build since 5.4 is affected. PHP 8.1 and older are end of life and get no patch. PHP 8.2 security support ends 31 December 2026, so Talos advises moving to 8.2 or later now. Talos estimates about 50% of PHP systems will not receive a patch. Frameworks and hosting stacks named as potentially exposed: WordPress, Drupal, Magento, Shopware, WooCommerce, Laravel, and PHP sites on cPanel or Plesk. The page does not list fixed version numbers.

What to do

Upgrading is the only complete fix. Talos says no temporary control gives comprehensive protection. Snort SIDs 67359 and 67360 cover both flaws, and they are in the free Community Ruleset. PHP advises these measures to reduce exposure on specific paths:

• Set memory_limit=-1, ideally non-overridable (php_admin_value in the FPM pool or Apache config). Check that no pool, directory or app setting restores a finite limit.
• Set a low post_max_size: 8M without file uploads, 32M with them. Keep upload_max_filesize below it. Also limit decoded request size, field count, multipart part count, header count and nesting depth at the web server or proxy, including requests with no usable Content-Length.
• Use a container or cgroup limit as an availability boundary, preferably one that kills only the affected worker.
• Set session.upload_progress.enabled=0 and restart every worker. Apply it in php.ini, an FPM pool or server config, not via ini_set() or .user.ini.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
• Remove invalid or deprecated per-request settings that emit diagnostics before initialization.
• Fix attacker-reachable fatal errors and execution timeouts, including those in callbacks, upload or import handling, and cleanup.

Caveats

• memory_limit=-1 removes only the controllable PHP memory-limit failure. An underlying allocation failure can still reach the vulnerable path.
• Do not use RLIMIT_AS or RLIMIT_DATA as a substitute for the cgroup limit, because they can cause the vulnerable allocation failure.
• Disabling session upload progress blocks the confirmed session paths but not other variants. The fatal_error_backtraces=0 setting blocks only the confirmed backtrace path.
• Hiding diagnostics with error_reporting, display_errors or @ does not help.
• Talos expects the impact to cascade into downstream platforms and compares it to the waves of exploitation after Log4J. It says the full impact will take time to assess.