PHP2Shell: Two Critical Flaws in PHP Itself (CVE-2026-109618 and CVE-2026-109619), Update Now

On October 21, 2026, the PHP project shipped security releases for two critical flaws in the PHP engine itself, grouped by their discoverers under the name PHP2Shell. This isn't a plugin, a framework or a CMS: it's the interpreter that runs WordPress, Drupal, Magento, Laravel and most of the web.

PHP's advisory leaves no room for doubt: every PHP installation serving web requests is in scope, and the only complete answer is to update.

The score is the one published by the PHP security team; NVD hasn't published its own yet.

The Two Flaws

CVE-2026-109618 — corruption after running out of memory. When PHP hits its memory limit, it aborts the current request by jumping straight out of the execution context. Some contexts then leave request memory uninitialized, and the cleanup that follows can read that invalid data as if it were valid. According to NVD, several ways of triggering the out-of-memory condition reliably lead to code execution.

CVE-2026-109619 — stale global state. PHP keeps global pointers that temporarily point into a request's memory. In some cases they aren't reset, or are repopulated after being reset. The next request handled by the same worker can then read that state, which points to memory already freed.

Why this is serious

• No application code is needed. Wiz says a plain "Hello World" page on an affected version can be vulnerable: the flaws sit below the application.
• No authentication. Both are remotely exploitable without an account.
• mod_php is the most exposed setup. PHP's advisory cites a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.
• The footprint is huge. Wiz writes that every version released in the last decade is affected by at least one of the two flaws, going back to the 5.4 branch.

The vector shows high attack complexity (AC:H) and attack prerequisites (AT:P): exploitation depends on memory and worker state. That's no barrier to an attacker holding a working exploit.

Exploitation

Neither PHP's advisory, nor Wiz, nor CISA reports active exploitation at the time of writing: the CVEs aren't in the CISA KEV catalog, and CISA's SSVC assessment read "exploitation: none" on October 21 at 14:34 UTC. Several security outlets (Help Net Security, Patchstack) do report details circulating before the release and early attack attempts. We can't confirm that, but with a demonstrated exploit and this footprint, plan as if exploitation were imminent.

Fixed Versions

End-of-life branches. The PHP project no longer ships releases for 8.1 and older. It provided minimal source fixes as branches for 7.4, 8.0 and 8.1, and some distributions and extended-support vendors ship their own patched packages. Otherwise, the answer is a migration to a maintained branch.

Distribution packages. Linux distributions and extended-support vendors received the fixes in advance: check your package manager for updates. If you use the community repository rpms.remirepo.net, PHP's advisory says it won't have updates on release day and recommends switching to distribution packages or building from source.

Check the version your web server actually runs, not just the command-line one — they often differ:

php -v
php-fpm -v            # or php-fpm8.3 -v, depending on the distribution
apachectl -M | grep -i php   # is mod_php loaded?

A temporary phpinfo() page, deleted right after, shows the version the server actually loads.

Interim Measures If the Update Has to Wait

PHP's advisory is explicit: these measures reduce exposure to specific attack paths but do not make an installation safe. They belong in php.ini, the FPM pool or the web server configuration — not ini_set() or .user.ini — and every PHP worker must be restarted.

Against CVE-2026-109619:

session.upload_progress.enabled = 0
; PHP 8.5 only:
fatal_error_backtraces = 0

The first one blocks the confirmed session-based paths, not other variants.

Against CVE-2026-109618:

; No file uploads needed:
post_max_size = 8M
; File uploads needed:
post_max_size = 32M
; keep upload_max_filesize below post_max_size

The advisory also recommends memory_limit=-1 enforced so applications can't override it (for example php_admin_value in the FPM pool), a container or cgroup memory limit as an availability boundary, and limits at the web server or proxy on request size, field count and multipart part count. It warns against RLIMIT_AS and RLIMIT_DATA, which can cause the very allocation failure the attack relies on.

Detection

Wiz notes that application logs carry little context, since everything happens below the application. Signals to watch:

• Unusual multipart requests followed by memory-limit errors (Allowed memory size … exhausted) or bursts of HTTP 500 errors;
• Unusually long or malformed PHPSESSID cookies in responses;
• Unexplained PHP-FPM worker or Apache child restarts.

Mitigation, in Order

1. Inventory every server running PHP for the web, including the forgotten ones: intranet, old WordPress sites, internal tools.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's patched package, then restart PHP-FPM or Apache.
3. Start with mod_php and internet-facing servers.
4. Apply the interim measures where the update can't happen right away, keeping in mind they aren't enough.
5. Plan the move off 8.1 and older branches.

Why Continuous Monitoring of Your PHP Versions Matters

PHP is often the dependency nobody inventories: installed with the OS, updated "when someone remembers", and its version differs from one server to the next. A flaw in the engine then hits everything running on it, all at once.

With cveo.tech, add your servers and their PHP versions to your inventory, and get an alert as soon as a critical CVE affects them — including while it's still awaiting NVD analysis.