PHP2Shell: Critical PHP Remote Code Execution (CVE-2026-109618 & 109619) — What It Is and How to Patch Now

On 21 October 2026, the PHP project released an emergency security update that fixes two critical remote code execution (RCE) vulnerabilities. Under the right conditions, an unauthenticated attacker can run code on a server simply by sending a web request — no login, no application bug required. The PHP Foundation rated both issues CVSS v4.0 9.2 (critical) and the official advisory carries a blunt headline: "update now." If you run PHP anywhere in your stack, this one is not optional.

The Two Vulnerabilities

Both flaws live deep in PHP's core memory management and error handling, which is why they affect PHP itself rather than any single framework or CMS. The nickname circulating in the security community is "PHP2Shell." Here is what each one does, with the official identifiers:

• CVE-2026-109618 — RCE via out-of-memory (OOM) corruption. Out-of-memory handling can interrupt PHP while internal request data is only partially initialized, and request cleanup then treats that invalid data as valid. On Apache with mod_php, an unauthenticated request can trigger this before any of your application code even runs.
• CVE-2026-109619 — RCE via stale global state. Request-owned internal state can survive after its backing memory has already been freed. A later request handled by the same worker may then use that stale state before normal initialization resets it.

Who Is Affected

According to php.net, the vulnerabilities affect all PHP installations serving web requests. The risk is considered highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before application code runs. Affected server configurations include:

• Apache with mod_php (highest risk — unauthenticated, pre-application trigger)
• PHP-FPM
• php-cgi
• FrankenPHP
• LiteSpeed

How to Fix It: Update Immediately

The only complete fix is to upgrade to a patched PHP version. The PHP project released fixes across all supported branches — update to whichever matches your current major/minor line:

• PHP 8.5.x → upgrade to 8.5.12
• PHP 8.4.x → upgrade to 8.4.27
• PHP 8.3.x → upgrade to 8.3.36
• PHP 8.2.x → upgrade to 8.2.35
• Linux distributions and LTS vendors received the patches in advance — check your vendor (apt, dnf, etc.) for updated packages, as they may backport the fix without changing the version number.
• PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes — contact your vendor, or upgrade to a supported version. (Note: PHP 8.2 itself reaches end of life on 31 December 2026, so plan a move to 8.3+ soon.)

Can't Patch This Minute? Official Temporary Mitigations

php.net is explicit that these mitigations are NOT a substitute for updating — they only reduce exposure until you can deploy a patched build. Apply them via server-level configuration (php_admin_value in your FPM pool or Apache config), not via ini_set() or a .user.ini file, which attackers may be able to work around:

• For CVE-2026-109618: set memory_limit = -1, and set post_max_size = 8M for apps without file uploads (or 32M if uploads are required). Do not substitute RLIMIT_AS or RLIMIT_DATA for this.
• For CVE-2026-109619: set session.upload_progress.enabled = 0 and restart every worker. On PHP 8.5, also set fatal_error_backtraces = 0.
• Then upgrade as soon as a patched package is available — the mitigations buy time, nothing more.

How to Check What You're Running

Before and after patching, confirm the exact version on every host (web servers, containers, and CLI workers can differ). From a shell run `php -v`, and for the version your web requests actually use, create a temporary file containing `<?php phpversion();` or check a locked-down phpinfo() page — then delete it. In Docker, rebuild from an updated base image rather than patching a running container. Don't forget background/queue workers and cron jobs, which often run a separate PHP binary.

What Blinknbuild Systems Recommends

Treat this as a same-day action item. If we manage your hosting or application, we are auditing PHP versions across your environments and rolling out the patched builds. If you self-host, prioritise internet-facing mod_php servers first, apply the vendor update, and verify the new version is live on every worker. If you're unsure what you're exposed to, get in touch and we'll review it with you.

Official Sources (php.net & GitHub)

All facts in this article come directly from the official PHP announcement and advisories. Always verify against these primary sources:

• php.net — Security advisory: Critical remote code execution vulnerabilities, update now (21 Oct 2026)
• The PHP Foundation — Today's PHP Security Release, and How We're Strengthening PHP Security
• GitHub advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618, RCE via OOM corruption)
• GitHub advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619, RCE via stale global state)
• php.net — PHP 8 ChangeLog
• php.net — Downloads (source)
• php.net — Downloads (Windows)