PHP2Shell: Critical PHP vulnerabilities, affected versions and fixes

PHP2Shell is the name for two critical remote code execution (RCE) vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619. Both score 9.2 on the Common Vulnerability Scoring System (CVSS) v4.0, and either one can let an unauthenticated attacker run code on a server that handles PHP requests. Cloudflare says exploitation has started.

PHP released fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run PHP anywhere in your stack, update now. If you deploy PHP in containers, Aikido publishes free patched PHP images that keep you on your current PHP version and backport the fixes.

How to fix PHP2Shell

Update PHP to a fixed version

Updating is the only complete fix. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every PHP process and rebuild any container images. Patching only a running container leaves the image exposed. After you update, keep session.upload_progress.enabled=0. It’s a rarely used legacy feature, and it’s one confirmed way in to CVE-2026-109619, so leaving it off removes that path even on a patched system. Set it in php.ini, a PHP-FPM pool or server configuration that applies before request parsing, then restart every worker.

Use patched Aikido Images

Patched Aikido Images are free on the Aikido public Amazon Elastic Container Registry (ECR). Pick your branch in the table below, then pull the latest patch in the variant you use, for example public.ecr.aws/aikido-dev/php:8.5.12-fpm. The base variant is the plain tag, such as php:8.2.35.

Where upstream has no fix, Aikido Images backport the fixes into the version you already run, so the tag keeps its version number.

Further images are being prepared. Until yours is available, update to the fixed PHP version directly.

Update through your operating system or vendor

Linux distributions and long-term support (LTS) vendors received the patches in advance, so check your vendor for updated packages. Vendors often backport fixes without changing the version number, so look for the CVE IDs in the package changelog (commands below).

PHP’s advisory said the volunteer-maintained Remi repository (rpms.remirepo.net) would not have updates on release day. Check its current status, or switch to distribution packages or build from source.

If you run PHP 8.1 or older

The PHP project no longer provides updates for these versions. Upgrade to a supported version or ask your vendor for a backported fix. PHP’s security team has also published minimal source backports for 7.4, 8.0 and 8.1 for teams that build from source. Aikido Images cover the 7.x series and PHP 5.5 and 5.6 (see the table above).

PHP 8.2 reaches end of life on December 31, 2026, so plan your move to a supported branch.

How to verify your PHP installation is patched

Confirm that the runtime serving web requests is the patched one.

1. Check your public URL. Aikido’s free PHP2Shell checker reports whether the site is vulnerable, mitigated or patched.
2. Find every PHP installation. Include parallel PHP branches, containers, continuous integration and continuous delivery (CI/CD) images, hosting panels such as cPanel and Plesk, and PHP bundled inside vendor software or Windows php.exe and php-cgi.exe binaries.
3. Don’t trust php -v alone. It reports the command-line binary, which can differ from the PHP-FPM pool or Apache module serving your site.
4. Check the vendor changelog for the CVE IDs. Replace the package name with yours.
   Debian or Ubuntu:

   apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619"

RHEL, Rocky Linux or AlmaLinux:

   rpm -q php-cli --changelog | grep -E "CVE-2026-109618|CVE-2026-109619"

5. Restart or replace every worker. Restart PHP-FPM, Apache and any application workers, or redeploy containers, then confirm no worker is still running the old build.
6. Aikido Images: Use the latest patch listed in the table for your branch.
7. Restore emergency settings, but keep upload progress off. If you applied temporary mitigations, restore a finite memory_limit and review any upload limits once the patched runtime is confirmed. Leave session.upload_progress.enabled=0 in place.

If you can’t update immediately

These measures reduce exposure to specific attack paths. They do not make an installation safe, and each one covers a single vulnerability. PHP’s advisory has the full list.

For CVE-2026-109618:

• Set memory_limit=-1 in a way applications can’t override, such as php_admin_value in the PHP-FPM pool or Apache configuration, then confirm no pool, directory or application setting restores a finite limit. This removes the memory-limit failure an attacker can control, but an underlying allocation failure can still reach the vulnerable code, and with no cap a runaway request can exhaust the server.
• Set a low post_max_size: 8M if your application doesn’t need file uploads, 32M if it does. Keep upload_max_filesize below it. Also enforce request size, field count, multipart part count, header count and nesting limits at the web server or proxy, including for requests without a usable Content-Length.
• Use a container or cgroup memory limit as an availability boundary, ideally one that kills only the affected worker. Don’t use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation failure.

For CVE-2026-109619:

• Set session.upload_progress.enabled=0 in php.ini, a PHP-FPM pool or server configuration that applies before request parsing, then restart every worker. Don’t rely on ini_set() or .user.ini. This blocks the confirmed session paths but not other variants.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks only the confirmed fatal-error backtrace path.
• Remove invalid or deprecated per-request settings that emit diagnostics before initialization. Hiding messages with error_reporting, display_errors or @ doesn’t help.
• Fix fatal errors and execution timeouts that an attacker can trigger, including failures in callbacks, upload or import processing and cleanup.

If your application doesn’t use multipart uploads, block multipart/form-data POST requests before they reach PHP.

After you patch: check for compromise

Look for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, and for oversized or malformed PHPSESSID cookies in responses. Then check for web shells, unexpected files, new admin users, modified PHP files, unexpected child processes spawned by PHP or your web server, and odd outbound connections.

Code execution gives an attacker everything the PHP process can read, including database credentials and API keys. If you suspect a compromise, rotate those on the affected systems.

What is PHP2Shell

PHP2Shell covers two memory-safety vulnerabilities in how PHP handles failures while processing a request, in particular running out of memory. The flaws sit in PHP’s runtime, so your application code can be sound and the server still vulnerable. PHP reports a demonstrated exploit against Apache with mod_php where an unauthenticated request triggers the attack before any application code runs.

Which PHP versions are affected by PHP2Shell?

Treat every unpatched PHP version as affected. PHP identifies any installation that serves web requests as at risk, including PHP-FPM (FastCGI Process Manager), Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, so patch those first, followed by any other internet-facing PHP.

CVE-2026-109618: PHP out-of-memory corruption

When an out-of-memory error interrupts PHP while it is setting up request data, that data is left partially initialized. PHP’s request cleanup then treats the invalid data as valid, which creates a path to remote code execution without authentication. PHP tracks this one as GitHub Security Advisory (GHSA) GHSA-w8hw-w9fx-j79w.

The temporary measures that reduce exposure are limits on memory and request size, listed above.

CVE-2026-109619: PHP stale global state

PHP keeps request-owned internal state alive after the memory behind it has been freed. A later request handled by the same worker can use that stale state before PHP’s normal initialization resets it. PHP tracks this one as GHSA-6wmf-4rv5-p3rp.

PHP’s session upload progress feature, which is enabled by default, is one confirmed path to this flaw. On PHP 8.5, fatal-error backtraces are another. Disabling those two features blocks only the confirmed paths.

How to check for PHP2Shell exposure

Aikido’s free PHP2Shell checker tests a public URL and reports whether it is vulnerable, mitigated or patched.

PHP2Shell disclosure and update timeline

• October 20, 2026: The PHP security team publishes an advance notice after details of the vulnerabilities leak ahead of the planned disclosure date.
• October 21, 2026: Independent researchers confirm the flaws are real, and PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ahead of its original schedule.
• October 21, 2026: Cloudflare reports that exploitation has started.

‍