Skip to content
eastbaycyber

Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.

PHP2Shell (CVE-2026-109618, CVE-2026-109619) Exploited in the Wild: Upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35

Breaking news 13 min read
EC
East Bay Cyber Editorial Team Updated
Built from the vendor or authority notice plus independent reporting; unconfirmed claims are labeled as reported. Human-reviewed after publishing.

CVE explainers: CVE-2026-109618

TL;DR - Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (released October 21, 2026). These fix CVE-2026-109618 and CVE-2026-109619, two critical flaws that can allow unauthenticated remote code execution. - Both are rated CVSS v4.0 9.2 by the PHP project. - PHP says all installations serving web requests are at risk (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed), with mod_php at highest risk. - PHP 8.1 and older get no upstream release. Use a distribution or LTS vendor backport, PHP’s minimal source backports for 7.4, 8.0 and 8.1, or upgrade to a supported branch. - Exploited in the wild. Amazon Threat Intelligence saw a first exploitation attempt on October 17, four days before the patch, and says the flaws are now “broadly exploited.” watchTowr and Cloudflare also report attacks. Investigate from October 17, not the disclosure date. - Neither CVE is in the CISA KEV catalog yet (checked against catalog version 2026.10.21).

Updated October 22: now exploited in the wild. Added the exploitation timeline, published indicators, how to check for compromise, NVD’s new CVSS v3.1 score, and the “PHP2Shell” name. Fixed versions are unchanged.

This week’s triage: all of this week’s critical issues, ranked by what to patch first: Critical vulnerabilities, October 17 to 24, 2026

What happened#

On October 20, 2026, the PHP project pre-announced a security release for October 21 at 14:00 UTC, fixing two critical vulnerabilities rated CVSS v4.0 9.2. Researchers at watchTowr said details had leaked before the planned disclosure.

On October 21, PHP published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 together with a security advisory titled “Critical remote code execution vulnerabilities, update now.” The CVE records were published by the PHP Group (as CNA) the same day. Security researchers and vendors now refer to the pair as PHP2Shell (also written php2shell); the name is not from the PHP project.

CVE Name (PHP advisory) CVSS v4.0 What goes wrong
CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) RCE via OOM corruption 9.2 Critical PHP uses longjmp() to abort a request on out-of-memory errors. Some code paths leave request memory uninitialized before an allocation, and request cleanup can then read or branch on that memory. Multiple OOM strategies can trigger it and lead to RCE.
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) RCE via stale global state 9.2 Critical Request-owned global state (error, session, object and extension state) can survive after its memory is freed. A later request handled by the same persistent worker can use it before normal initialization, causing a use-after-free (CWE-416).

Both CVE records carry the vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N: network-reachable, no privileges and no user interaction, with high attack complexity and attack requirements present. NVD has since added its own assessment: CVSS v3.1 9.8 (Critical) for both, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The two scores use different CVSS versions and are not directly comparable; PHP’s v4.0 9.2 reflects the attack complexity and preconditions it identified.

For CVE-2026-109619, the GitHub advisory says an attacker needs a “producer” (for example a fatal error, a require failure, a maximum-execution-time abort or an out-of-memory condition) and a “consumer” (for example a warning raised during early INI processing, or session upload progress handling) to run in different requests on the same worker. It describes a confirmed RCE against mod_php via PHP 8.5 fatal error backtraces, and session upload progress RCE validated against mod_php and PHP-FPM.

Exploitation timeline

When (UTC) What was reported Source
October 17 First exploitation attempt against Amazon’s MadPot honeypots, from anonymization infrastructure, four days before disclosure Amazon Threat Intelligence
October 21, from about 02:00 Proof-of-concept exploits appear and more attempts follow, before the embargo lifted Amazon Threat Intelligence
October 21, 14:00 PHP releases fixes; more PoCs appear within hours and are used almost immediately Amazon Threat Intelligence
October 21 onward watchTowr observes exploitation through its honeypot network; Cloudflare reports “early attacks emerging” watchTowr, Tenable

These are researcher and vendor observations, not an official exploitation designation: CISA’s enrichment of the CVE records was last set on October 21 at 14:34 UTC (“Exploitation: none”) and neither CVE is in the KEV catalog as of version 2026.10.21. The PHP Foundation said its team “did not identify any functional exploits at the time of release,” and Tenable notes that exploit code circulating publicly is unverified and may itself contain malware.

How widespread is PHP?

W3Techs data cited by Tenable puts PHP on 69.3% of websites whose server-side language is known. That is a measure of how common PHP is, not of how many sites are vulnerable: patched, non-web and well-configured installs are not exposed in the same way. Researcher estimates cited by Tenable put internet-exposed, potentially vulnerable hosts at over 1.3 million, and hosts running PHP at over 1.9 million.

Who is affected#

Branch Fixed version Notes
PHP 8.5 8.5.12 Supported
PHP 8.4 8.4.27 Supported
PHP 8.3 8.3.36 Supported
PHP 8.2 8.2.35 Reaches end of life on December 31, 2026
PHP 8.1 and older No upstream release Vendor backports, or PHP’s minimal source backports for 7.4, 8.0 and 8.1

By server API, per the PHP advisories:

  • Apache mod_php: highest risk. PHP says a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs.
  • PHP-FPM: at risk; session upload progress RCE for CVE-2026-109619 was validated against FPM.
  • php-cgi, FrankenPHP, LiteSpeed: listed as at risk in PHP’s advisory.

Remember the less obvious places PHP runs: container base images, CMS and e-commerce hosting, shared and managed hosting where the provider owns the build, and appliances that bundle PHP for a web interface.

What changed from early reports

Before the release, BleepingComputer relayed claims from watchTowr. Checked against the official advisory and CVE records:

Early report Official status
Both flaws are remote code execution Confirmed: PHP says both can allow unauthenticated RCE
CVE IDs CVE-2026-109618 and CVE-2026-109619 Confirmed and published by the PHP Group
Severity CVSS 10.0 Not what PHP published: the official score is CVSS v4.0 9.2 for both
Affected versions span PHP 5 through PHP 8 PHP shipped fixes for 8.2 to 8.5 only. It says 8.1 and older no longer receive updates and published minimal source backports for 7.4, 8.0 and 8.1. It has not published a statement about PHP 5.
No exploitation observed Superseded: exploitation reported since October 17 (see the timeline above); still not in the KEV catalog

What to update: patching checklist#

  1. Upgrade supported branches to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source and Windows builds are on php.net’s downloads page.
  2. Use your vendor’s packages where you have them. PHP says Linux distributions and LTS vendors received the patches in advance. Distributions often backport fixes into their own version numbers, so check your distro’s security advisory rather than matching upstream version strings.
  3. Users of the volunteer-run rpms.remirepo.net repository: PHP says that repository will not have updates on October 21 and urges switching to distribution packages or building from source.
  4. Patch in order of exposure: internet-facing mod_php first, then other public web SAPIs (FPM, CGI, FrankenPHP, LiteSpeed), then internal apps.
  5. Rebuild and redeploy container images, then restart every PHP-FPM pool and web server so no worker keeps running the old binary.
  6. Handle PHP 8.1 and older now. Get a backport from your distribution or LTS vendor, build from PHP’s source backport branches, or upgrade. PHP 8.2 itself goes end of life on December 31, 2026.
  7. Re-scan to confirm no unpatched PHP remains, including appliances and hosted sites.

Find PHP versions

# Version of the CLI and of PHP-FPM
php -v
php-fpm -v 2>/dev/null || ls /usr/sbin/php-fpm* 2>/dev/null

# Installed PHP packages (Debian/Ubuntu, then RHEL family)
dpkg -l | grep -E '^ii\s+php' 2>/dev/null
rpm -qa | grep -i '^php' 2>/dev/null

# Container images that look like PHP
docker images | grep -i php

Vulnerability scanners can speed up the inventory across many hosts. Tenable lists Nessus plugin 369483 for the upstream versions, plus distribution-specific local checks, and Web App Scanning plugins 115719 to 115722, according to its PHP2Shell FAQ. If you need a scanner, Check Tenable Nessus pricing. This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Check for compromise#

Patching stops new attacks; it does not undo an earlier one. Because exploitation began before disclosure, Amazon recommends starting any investigation from October 17, not October 21.

  • Look for session upload progress abuse. Amazon’s indicator is POST requests with PHP_SESSION_UPLOAD_PROGRESS in multipart form uploads. Standard access logs do not record request bodies, so check WAF, reverse proxy or request-body logs where you have them.
  • Find products that bundle PHP. The Dutch NCSC (NCSC-NL) maintains a public PHP2Shell repository (TLP:CLEAR) with an inventory of software that has a PHP dependency, plus detection and mitigation material. It describes itself as incomplete and still being expanded, so treat it as a pointer and check the vendor’s own notice for each product.
  • Check the published IP addresses. Amazon lists six, all on shared anonymization infrastructure, so it recommends investigating activity from them rather than simply blocking them: 103.216.220.92 (October 17), and 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 and 95.217.98.37 (October 21).
  • Look on the server itself for unexpected processes started by the web server or PHP-FPM user, and new or modified files under web roots (for example dropped .php files) since October 17.
  • If anything looks wrong, treat the host as compromised: isolate it, preserve logs, rotate credentials the application could reach, and rebuild from a known-good image rather than cleaning in place.
# Requests from the published IPs in common web server access logs (adjust paths for your setup)
grep -E '103\.216\.220\.92|31\.223\.184\.166|37\.19\.200\.5|134\.209\.159\.64|103\.114\.163\.188|95\.217\.98\.37' \
  /var/log/nginx/access.log* /var/log/apache2/access.log* /var/log/httpd/access_log* 2>/dev/null

# PHP files created or changed under the web root since October 17
find /var/www -name '*.php' -newermt '2026-10-17' -ls 2>/dev/null

If you cannot patch immediately#

PHP is explicit that only an update is a complete solution. Its advisory lists measures that reduce exposure to specific attack paths but do not make an installation safe:

CVE-2026-109618 (OOM corruption)

  • Set memory_limit=-1 in a way applications cannot override (for example php_admin_value in the FPM pool or Apache config). PHP notes an underlying allocation failure can still reach the vulnerable path.
  • Set a low post_max_size (8M without file uploads, 32M with them) and keep upload_max_filesize below it.
  • 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. PHP warns against substituting RLIMIT_AS or RLIMIT_DATA, which can cause the vulnerable allocation failure.

CVE-2026-109619 (stale global state)

  • Set session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration, and restart every worker. PHP says not to rely on ini_set() or FPM .user.ini.
  • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
  • Remove invalid or deprecated per-request settings that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
  • Fix attacker-reachable fatal errors and execution timeouts.

Other stopgaps reported since release

  • Amazon suggests blocking multipart file uploads where your applications can tolerate it, and says no configuration-only workaround fully covers both CVEs.
  • Cloudflare says its WAF rules cover known exploit vectors for traffic routed through it, as a stopgap rather than a substitute for patching, per Tenable.
  • CERT-EU recommends isolating internet-facing applications from public networks until a fix is applied and verified, per Tenable.

PHP applications that make outbound HTTPS calls through Composer’s ca-bundle package are also affected by this week’s eMudhra intermediate CA compromise. Composer ca-bundle 1.4.16 and 1.6.0 carry the fix, so update it in the same maintenance window.

Related reading: Why “patch everything” is bad advice, What is Patch Tuesday? and our CVE explainers.

This advisory is informational. Confirm affected versions and fixes against the official PHP release and your vendor’s guidance.

Sources

Last verified: 2026-10-22

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.