Request Demo
Home › Blog
Security

PHP2Shell: critical remote code execution flaws in PHP (CVE-2026-109618, CVE-2026-109619)

Two critical flaws in the PHP runtime allow unauthenticated code execution. Affected and fixed versions, plus a step-by-step checklist for your servers.

Boran Yazılım·25 October 2026
PHP2Shell security alert: CVE-2026-109618 and CVE-2026-109619, CVSS 9.2; terminal showing an update from PHP 8.4.26 to 8.4.27

PHP2Shell is the shared name for two critical remote code execution (RCE) flaws in the PHP runtime itself, patched on 21 October 2026: CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on CVSS v4.0 and let an unauthenticated attacker run code on the server. Because the flaws are in PHP rather than in application code, every PHP installation that serves web requests is in scope, however carefully the application is written.

What do the two flaws do?

CVE-2026-109618 is a memory corruption bug triggered when PHP hits its memory limit while setting up a request (parsing form data, i.e. $_POST). An attacker sends an unauthenticated POST sized to exceed the memory limit. The request is processed before any application code runs, so application-level login checks cannot stop it.

CVE-2026-109619 is a use-after-free in state a PHP worker carries between requests: freed memory owned by one request can be reused by the next. According to Datadog, the session upload progress feature, enabled by default, makes this path exploitable on mod_php and PHP-FPM.

Which versions are affected?

  • PHP 8.5: before 8.5.12 (fixed in 8.5.12)
  • PHP 8.4: before 8.4.27 (fixed in 8.4.27)
  • PHP 8.3: before 8.3.36 (fixed in 8.3.36)
  • PHP 8.2: before 8.2.35 (fixed in 8.2.35)
  • PHP 7.4, 8.0 and 8.1: no official release; PHP published source backports, otherwise use a distribution/LTS package or upgrade
  • PHP 7.3 and older: no fix; upgrade to a supported branch

Affected runtimes include Apache mod_php, PHP-FPM, php-cgi, LiteSpeed and FrankenPHP. Risk is highest on mod_php, where a single unauthenticated request can trigger the attack before application code runs.

Timeline

Details leaked on 20 October 2026, ahead of the disclosure planned for 22 October. PHP brought its release forward and shipped fixed versions on 21 October. watchTowr reported exploitation attempts in its honeypot network the same day. Datadog reports that AWS observed exploitation attempts on 17 October, four days before disclosure. On 23 October PHP published an advisory for a related flaw, CVE-2026-115560, in the session upload progress feature; according to Cloudflare it affects fully patched releases including 8.5.12 and will be fixed in PHP's next regular release.

What should you do?

1. Take inventory: list every server and application running PHP, starting with internet-facing systems. Include PHP interpreters bundled in container images and applications.
2. Update: move each installation to the fixed release for its branch, or install your Linux distribution's patched package. Distributions may backport the fix without changing the version number; check the package changelog for the CVE numbers.
3. Restart: restart every PHP worker and PHP-FPM pool after updating and rebuild container images. A worker still running the old runtime stays exposed.
4. Restrict internet access to systems you cannot update immediately and put a WAF or reverse proxy in front of them.
5. Monitor: watch for multipart requests with PHPSESSID or PHP_SESSION_UPLOAD_PROGRESS fields you do not use, "Allowed memory size ... exhausted" errors with "Unknown on line 0", worker segmentation faults and web servers spawning shells.

Why workarounds are not enough

Settings circulating in the community, such as memory_limit=-1 or session.upload_progress.enabled=0, reduce exposure but do not close the flaws. PHP states that no configuration change fully mitigates them. The only complete fix is the patched release plus a restart of every worker.

Summary

PHP2Shell is an unauthenticated pair of flaws affecting every PHP web application, with exploitation attempts already observed. Check the PHP version on your servers today; if it is below 8.5.12, 8.4.27, 8.3.36 or 8.2.35, update and restart all workers. If you need help updating PHP-based systems, contact the Boran Yazılım team through our contact page.

Sources

← BlogRequest Demo