News Vulnerabilities & Zero-Days

PHP2Shell confirmed: PHP patches two critical unauthenticated RCE flaws as first attacks are spotted

PHP has released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619, two critical flaws that can allow unauthenticated remote code execution on servers handling web requests. Cloudflare and watchTowr report early attack activity.

Published Updated
Illustration of a web server rack struck by lightning, with a large patch shield labeled PHP being slotted into place.

Key takeaways

  • PHP confirmed CVE-2026-109618 and CVE-2026-109619 can allow unauthenticated remote code execution.
  • Fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; PHP 8.1 and older get no official release.
  • PHP rates the risk highest for Apache mod_php, where an exploit has been demonstrated.
  • Cloudflare reported early attacks, and watchTowr lists the flaws as exploited in the wild.
  • PHP says interim mitigations are partial and updating is the only safe choice.

PHP has confirmed the worst: the two critical vulnerabilities it pre-announced on 20 October can allow unauthenticated remote code execution. The PHP project released fixed versions on 21 October 2026 and says all PHP users should update immediately.

Which versions fix the flaws? #

Branch Fixed version Status
8.5 8.5.12 Supported
8.4 8.4.27 Supported
8.3 8.3.36 Supported
8.2 8.2.35 Supported until 31 December 2026
8.1 and older No official release End of life

According to PHP's GitHub advisories, all versions before these releases are affected. For PHP 7.4, 8.0 and 8.1, PHP has published minimal source backports but no official releases, and says some Linux distributions and long-term support vendors provide backported fixes.

What are the two vulnerabilities? #

CVE Name What goes wrong
CVE-2026-109618 RCE via OOM corruption Out-of-memory handling can interrupt PHP while request data is only partly set up, and cleanup then treats the broken data as valid. Attackers can trigger it with multipart parsing and other memory-exhausting input.
CVE-2026-109619 RCE via stale global state Request-owned state can survive after its memory is freed, so a later request on the same worker may use it before it is reset (a use-after-free).

Both are rated 9.2 (critical) on CVSS v4.0. BleepingComputer reports that researchers from Calif, Wiz and OpenAI were credited with finding the flaws.

Who is at risk? #

PHP says all installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

PHP is used by 69.3% of websites whose server-side language is known, according to W3Techs.

Are attackers exploiting it? #

Early signs say yes. BleepingComputer reported that Cloudflare's CTO said the company was already seeing early attacks against both flaws before the patches came out. watchTowr's FAQ, updated on 22 October, lists the flaws as exploited "in the wild", based on activity seen by its honeypot network on 21 October. The flaws were not in CISA's Known Exploited Vulnerabilities catalog at the time of watchTowr's update.

BleepingComputer also reported that the UK's National Cyber Security Centre urged organizations to update or take systems offline until patched.

Can I mitigate without patching? #

Only partly. PHP says "there are no complete mitigations, updating is the only safe choice." Its interim steps reduce exposure to specific attack paths:

  • CVE-2026-109618: set memory_limit=-1 (preferably with php_admin_value), set post_max_size to 8M (no uploads) or 32M (uploads needed) with upload_max_filesize below it, enforce request limits at the web server or proxy, and use container or cgroup memory limits.
  • CVE-2026-109619: set session.upload_progress.enabled=0 and restart every worker; on PHP 8.5 also set fatal_error_backtraces=0. Do not rely on ini_set() or FPM .user.ini for this.

What should PHP users do now? #

  1. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's patched package.
  2. Patch internet-facing servers first, starting with Apache mod_php setups.
  3. If you use the volunteer-run rpms.remirepo.net repository, PHP advises switching to distribution packages or building from source, as that repository did not have updates on release day.
  4. For PHP 8.1 and older, get backported fixes from your vendor or upgrade to a supported branch. Apply PHP's interim mitigations until then.
  5. Check web servers for signs of compromise, such as unexpected processes started by PHP workers or new files in web directories.

This is a developing story.

Sources

  1. PHP security advisory: critical RCE vulnerabilities, update now, PHP
  2. GitHub advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618), PHP (GitHub)
  3. GitHub advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), PHP (GitHub)
  4. PHP ships emergency patches for PHP2Shell flaws, BleepingComputer
  5. watchTowr FAQ on the PHP vulnerabilities, watchTowr
  6. PHP usage statistics, W3Techs

Questions this raises

Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026.
Is PHP 7 or 8.1 fixed?
Not with official releases. PHP published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors provide fixes. Otherwise upgrade.
Is it being exploited?
Cloudflare's CTO said the company saw early attacks, according to BleepingComputer, and watchTowr lists the flaws as exploited in the wild.
Which setups are most at risk?
PHP says the risk is highest for Apache with mod_php, but all installations serving web requests are at risk.

VulnerabilityZero-DaySecurity UpdatePatch ManagementApplication SecurityOpen Source SecurityEnd of SupportPHPRemote Code Execution