What you need to know about PHP2shell. Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619)

Update, 15:00 CEST: Patches are now available. Update PHP now.

‍Two critical remote code execution vulnerabilities have been found in PHP itself. Every unpatched PHP version is affected.

The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both have a CVSS v4.0 score of 9.2. PHP has released fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Exploitation has been reported in the wild.

If you run PHP anywhere in your stack, update as soon as you can. Patched Aikido Images are also available to apply the fixes without extensive updates.

We are working with the PHP Foundation and the security community to continue to bring you more information.

How to fix this

• Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart PHP processes and rebuild any container images.‍
• Use patched Aikido Images where available. Patched Aikido Images are free on the Aikido public ECR for PHP 8.2, 8.3, 8.4 and 8.5. Switch to the patched tag and redeploy.
  ‍
  • PHP 8.2: php:8.2.34, php:8.2.34-apache, php:8.2.34-cli, php:8.2.34-fpm, php:8.2-fpm-bookworm
  • PHP 8.3: php:8.3.35-cli, php:8.3.35-fpm-trixie, php:8.3-apache-bookworm
  • PHP 8.4: php:8.4.26, php:8.4.26-apache, php:8.4.26-cli, php:8.4.26-trixie, php:8.4.26-fpm-trixie, php:8.4-fpm-bookworm
  • PHP 8.5: php:8.5.11, php:8.5.11-cli, php:8.5.11-fpm, php:8.5.11-trixie, php:8.5.11-fpm-trixie
    
    Further patches are being prepared.‍
    
• If you install PHP through your OS, check your vendor for updated packages. Vendors often backport fixes without changing the version number, so look for the CVE IDs in the changelog.

• On PHP 8.1 or older, the PHP project no longer provides updates. 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.
• If you use the Remi repository (rpms.remirepo.net), it won’t have updates today. Switch to distribution packages or build from source.
• Prioritise anything running mod_php, which PHP’s security team rates as highest risk.
• Check your exposure. Use our free PHP2Shell checker to test a public URL. Only test sites you own or have permission to test. A clean result doesn’t confirm you’re patched, so verify the patch on the server itself. The definitive check sends a larger payload that can crash a PHP worker and interrupt requests, so run it outside peak hours.

If you can't update immediately

These measures reduce exposure but do not make an installation safe. Apply both temporary mitigations together in the effective web PHP configuration: session.upload_progress.enabled = 0 and memory_limit = -1, set in a way applications can’t override, then restart every PHP worker. Each setting covers a different vulnerability, so don’t apply either alone. If multipart uploads are unnecessary, block multipart/form-data POST requests before they reach PHP. Setting a low post_max_size also helps. Full list of PHP’s mitigations.

After you patch

Check for signs of compromise: unusual multipart requests followed by memory-limit errors or repeated HTTP 500s, oversized or malformed PHPSESSID cookies, unexplained PHP worker restarts, web shells, unexpected files, new admin users, modified PHP files and odd outbound connections. The flaws can expose worker memory, so consider rotating passwords, API keys and tokens on internet-facing PHP systems.

What happened

The PHP security team published an advance notice on October 20 after information about the vulnerabilities leaked ahead of the planned disclosure date. Independent researchers confirmed the flaws were real, and the PHP team moved the release up to October 21. Patched versions were released on October 21. Open sources identified the exploitable behaviour outside of the embargo, and Cloudflare says exploitation has started.

How the vulnerabilities work

Both flaws are memory-safety issues in how PHP handles out-of-memory errors while processing requests. CVE-2026-109618 can corrupt internal request data that PHP then treats as valid. CVE-2026-109619 lets stale request state survive after its memory is freed, so a later request on the same worker can use it. PHP’s advisory has the full technical details, including the GHSA entries. Corelight has written more on the vulnerability.

‍

See the PHP site for more information.