PHP2SHELL: Two Critical Remote Code Execution Vulnerabilities in the PHP Core

1. EXECUTIVE SUMMARY

PHP quietly powers a large share of the web: content and e-commerce systems such as WordPress, Drupal, Joomla and Magento, shared-hosting platforms, control panels such as cPanel and Plesk, and countless enterprise applications that never advertise that they run PHP. When a vulnerability lands in the PHP core itself, it does not touch a single product — it can affect everything built on that foundation at once.

On October 20, 2026, the existence of two critical PHP RCE flaws leaked ahead of the coordinated disclosure date and before any patch was available. Within hours, independent researchers confirmed the flaws were real, and the PHP team moved the emergency release a day earlier, publishing it on October 21, 2026 at 14:00 UTC. The name is the researchers’ own and usually means one thing: an attacker sends a request to the server and, in return, gains the ability to run commands on it (a shell).

2. HOW IT CAME TO LIGHT: AN EMBARGO LEAK

The most striking part of this incident is how it became public, as much as the vulnerability itself. A critical flaw is normally disclosed in coordination under an "embargo": the patch is prepared first, then the details are published. This time the order broke down.

On the morning of October 20, 2026, a user (petecooper) on Hacker News claimed that two critical PHP RCE flaws would be disclosed on October 22, that both carried CVSS 10.0, and that they affected versions going back to PHP 5. The post included both CVE identifiers, but the only evidence offered was "source: trust me, bro." The post was taken down, but screenshots were already circulating.

Shortly afterward, Kevin Beaumont (GossiTheDog) confirmed the leak, and watchTowr stated the flaws were real. PHP published its advance notice and moved the release a day earlier, to Wednesday 14:00 UTC. At the same hour, the patches and two detailed GHSA advisories were published.

Disclosure Timeline

Table 1. Timeline of the php2shell disclosure, from the initial leak to the official release.

3. CVE DETAILS

The official advisory describes the two CVEs as two distinct mechanisms. Both are fixed by the same releases (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) and classified as CWE-416 (use-after-free).

Table 2. The two CVEs, their official root-cause descriptions, severity and exploitation status.

EXPLOITATION UPDATE (October 22). The status moved from “no exploitation” to active exploitation. watchTowr reports active, ongoing exploitation attempts against both CVEs; per public reporting, Cloudflare observed the first attacks at 07:43 UTC on October 21 — more than six hours before the patch. Public PoC code is circulating. Beyond RCE, the official advisory confirms memory disclosure: the flaw can leak PHP worker memory (passwords, tokens, API keys, even TLS private keys). Patching does not evict an attacker who got in during the pre-patch window — triage and secret rotation are now part of the response.

TECHNICAL DETAILS

The official advisory defines two distinct mechanisms. Both can lead to unauthenticated RCE, are classified as CWE-416 (use-after-free), and are fixed by the same releases.

CVE-2026-109618 — RCE via OOM Corruption

PHP uses "longjmp()" to exit the current context and abort the request on out-of-memory (OOM) errors. In some contexts request memory is temporarily reachable before it is fully initialized. If any allocation fails at that point, PHP does not properly account for the early exit and leaves request memory in an invalid state. The failed allocation does not need to be related to the invalid memory. The request shutdown procedure may then read or branch on that invalid data — which can lead to remote code execution.

Trigger: an attacker can reliably force OOM with multipart requests that stay within apparent PHP limits. Examples include requests without a usable content length that pass the initial post_max_size check and keep supplying body data; a part containing an unrestricted number of headers (which take far more memory in PHP than on the wire, so a request within post_max_size can still exhaust memory_limit); and empty file controls that do not count toward max_file_uploads.

CVE-2026-109619 — RCE via Stale Global State

PHP holds various global state (error, session, object and extension state) that a worker retains but that points to memory owned by a single request. That state must be reset before the request memory is released. Some input, configuration, session and error-handling operations run before the next request’s normal initialization and inadvertently access stale, not-yet-reset state — a use-after-free. A carefully crafted heap layout can produce full RCE. Exploitation requires a "producer" (an operation that stores request-owned state where PHP can reach it later) and a "consumer" (a later operation that reads, frees or branches on that stale state); the two occur in different HTTP requests handled by the same worker.

There are two confirmed consumers. The first is INI diagnostics that run before request initialization: a warning or notice emitted by an invalid or deprecated INI setting can consume stale error state — it need not be fatal, displayed or logged, and error_reporting, "@" or display_errors do not protect against it. The second is session upload progress, which reaches session/decoder state before normal initialization. The strongest demonstrated case is fatal-error backtrace state on PHP 8.5 with "fatal_error_backtraces" enabled; this is the basis of the confirmed mod_php exploitation. The session upload progress lifecycle was validated against both mod_php and FPM. Note: session.upload_progress is enabled by default and requires no call to "session_start()."

CVE-2026-115560 — RCE via Session Serialize-Handler Switch

CVE-2026-115560 is a separate code-execution path tied to PHP’s session upload progress feature — the built-in mechanism that writes upload progress into $_SESSION so applications can render a progress bar without a separate backend. It is enabled by default. Unlike the php2shell flaws, this issue is reachable only through a specific, uncommon sequence of session-handling moves within the same request path, which is why PHP characterizes it as “unlikely.”

The vulnerability fires only when all of the following line up: session.serialize_handler is set to php_binary or php_serialize in php.ini or an equivalent configuration layer; the application then calls ini_set('session.serialize_handler', 'php') at runtime, switching the handler to the legacy format; that ini_set() call happens before session_start(); and session.upload_progress.enabled is still 1. An application that never changes the serialize handler at runtime can leave the feature on and is not exposed through this path. The practical consequence is that the attacker-controlled upload-progress data is written and later read back under a mismatched serializer, which PHP states can lead to remote code execution.

As of disclosure (October 23, 2026), PHP had published only a short informational advisory and had not released the technical root cause, a CVSS score, the affected version range, or the fixed release. PHP has also not confirmed whether CVE-2026-115560 shares a root cause with CVE-2026-109619; both are reached through session upload progress and both are mitigated by the same setting. PHP is not issuing an emergency fix and will address it in the next routine release. No exploitation has been reported, and the in-the-wild activity since October 21 targets the two php2shell flaws, not this one.

5. AFFECTED VERSIONS AND SUPPORT STATUS

The official GHSA records list the affected versions for both flaws as "< 8.2.35, < 8.3.36, < 8.4.27 and < 8.5.12." Given the severity, the PHP security team also published minimal source backports for the end-of-life (EOL) 7.4, 8.0 and 8.1 branches. There is no official PHP fix for 7.3 and earlier, or for 5.x.

Distributions (Ubuntu, Debian, RHEL, SUSE, Alpine, Amazon Linux, official Docker images) and LTS vendors received the patches in advance; to decide whether a host is patched, rely on your distribution’s security tracker rather than the upstream version number.

Table 3. PHP branches, fixed versions and support status. Only 8.2–8.5 receive full official fixes; EOL 7.4/8.0/8.1 get minimal source backports.

6. EXPOSED SURFACE: THE SIZE OF INTERNET-FACING PHP

The figures below are drawn from VirusTotal’s internet-scanning data (October 21, 2026). These are fingerprint counts; they describe the size of the exposure window, not confirmed vulnerable systems.

Table 4. Internet-facing PHP footprint. Only about one in five hosts discloses its version, so banner counts are a lower bound.

THE SINGLE MOST IMPORTANT FINDING

About four in five PHP servers hide their version ("expose_php = Off", stripped headers, reverse proxies). Hiding the version does not hide the vulnerability — so banner-based counts are a lower bound on the real exposure.

What Runs On Top

Table 5. Web servers and applications most often seen on internet-facing PHP hosts (VirusTotal).

Because the official advisory rates mod_php the highest risk, Apache installations running mod_php should be scanned first. The geography is concentrated: ~920K of the PHP hosts with an open port are in the United States, and a handful of cloud/hosting providers (AWS, DigitalOcean, Alibaba, OVHcloud, Hetzner) hold a large share.

7. BLACK KITE EXPOSURE ANALYSIS

Black Kite measured the taggable exposure by scanning internet-facing PHP across the affected-era range (5.4.0 – 8.5.11) on Shodan, one version at a time. A total of 471 distinct versions were queried. Two baselines were used: all internet-facing PHP excluding honeypots (including hosts that hide their version), and hosts that disclose a version in their banner.

Query pattern used

http.component:"php" -tag:honeypot            -> 1,898,841 (baseline)
http.component:"php" "PHP/8.3.33" -tag:honeypot -> 29,758

Figure 1. Share of version-disclosing internet-facing PHP by support status (de-overlapped Shodan data, Oct 21, 2026).

Distribution by Branch (de-overlapped)

Exposure concentrates in long-lived, slowly upgraded branches: PHP 7.4 (~223K), 5.4 (~201K) and 5.6 (~155K) lead. On the supported side the largest load is on PHP 8.2 (~175K) and 8.3 (~119K) — patchable, but requiring fast action.

Figure 2. Host distribution of version-disclosing internet-facing PHP by branch; red = EOL (no patch), green = supported.

Most Common Individual Versions

Table 6. The most common individual PHP versions after de-overlap correction (Shodan, Oct 21, 2026).

8. PARTIES AFFECTED AND EXPOSED

The picture changed within a day of disclosure. As of October 22, 2026, watchTowr reports active, ongoing exploitation attempts against both CVEs, and per public reporting Cloudflare observed the first attacks at 07:43 UTC on October 21 — over six hours before the patch. Public PoC code is circulating. No confirmed breach of a named organization has been reported yet, and the flaws were not in the CISA KEV catalog at the time of writing. The vulnerabilities are credited to multiple researchers, including Wiz Research and calif.io; Google states AI models (including Gemini) assisted in discovery, exploit development and patch validation.

Exposed Platform and Ecosystem Classes

• Content management systems: WordPress (~538K internet-facing instances), Drupal, Joomla.
• E-commerce: Magento / Adobe Commerce and similar PHP-based stores.
• Frameworks and collaboration: Laravel (~141K), Nextcloud (~107K).
• Admin panels: phpMyAdmin, Roundcube webmail, cPanel and Plesk.
• SAPIs: Apache mod_php (highest risk), php-cgi, PHP-FPM, FrankenPHP, LiteSpeed/LSAPI.

Vendors That Responded

Table 7. Vendor and researcher responses to php2shell as of October 21, 2026.

9. DETECTION: WHAT EXPLOITATION LOOKS LIKE

Two detection layers should be used together: request level (the 5xx crash signal, loose multipart parsing and log audit from Section 4) and process level. At the process level, the trace left by this class of PHP RCE is consistent: a PHP worker process spawning an unusual child process.

A PHP worker (php-fpm, php-cgi, php-cgi.exe, httpd, apache2) launching any of the following warrants a closer look:

•    Shells: sh, bash, cmd.exe, powershell.exe

•    Interpreters / tools: python, perl, curl, wget, nc, certutil.exe

•    Reverse-shell patterns: /dev/tcp/, fsockopen, mkfifo

•    Recon commands: whoami, id, uname -a, ipconfig

In addition, the official advisory recommends a log audit: in an isolated audit with log_errors=On, a working error_log and error_reporting=E_ALL, review logs for repeated warnings/deprecations before target scripts run, diagnostics during extension/server cleanup, fatal/parse/uncaught errors, and "Maximum execution time exceeded." The absence of an error in the logs is not proof of safety.

STRONGEST PRACTICAL SIGNAL — OOM FATAL BURSTS
No confirmed indicators of compromise are published yet, so the best available signal is the trigger itself: a fatal error, typically “Allowed memory size … exhausted.” A cluster of these in your PHP-FPM logs around October 21 (including rotated .gz files) is worth a closer look. A read-only triage: verify the FPM binary version that actually serves the site (it can differ from the CLI); count OOM fatals; review the busiest October 21 POST targets (watch endpoints that never take uploads); flag unexpected PHP files in public/ and storage/ and run git status; and check persistence (new cron jobs, authorized_keys, recent SSH logins, odd outbound connections). This is triage, not forensics — it tells you whether to look closer, not that a host is clean.

10. MITIGATION AND PATCHING

UPDATING IS THE ONLY COMPLETE SOLUTION

The PHP security team states plainly that there is no complete generic configuration mitigation — an application, extension or server path may publish stale state or consume it without a predictable log entry. The measures below reduce exposure to specific attack paths but do not make an installation safe.

Table 8. Immediate response steps while planning the update.

On managed cloud platforms the picture varies: Google Cloud auto-patches App Engine standard runtimes and ships Cloud Armor managed WAF rules, but Cloud Run, GKE and self-built container images must be rebuilt with a patched PHP and redeployed. Check your provider’s bulletin, enable managed WAF rules as defense-in-depth, and confirm every container image and deployment pipeline is rebuilt — not just the host.

Interim measures for CVE-2026-109618 (OOM)

; Enforced so applications cannot override (FPM pool / Apache):
php_admin_value[memory_limit] = -1
post_max_size = 8M       ; if no uploads (32M if uploads are needed)
upload_max_filesize < post_max_size
; Do NOT use RLIMIT_AS / RLIMIT_DATA -> triggers the vulnerable path
; A cgroup memory.max is only an availability bound, not a full fix

Interim measures for CVE-2026-109619 (stale state)

; php.ini / FPM pool / server (NOT ini_set or .user.ini), then restart workers:
session.upload_progress.enabled = 0
; PHP 8.5 — removes the confirmed RCE producer:
fatal_error_backtraces = 0
; optional — recycle the worker on every request:
pm.max_requests = 1

Also: eliminate attacker-reachable fatal errors and execution timeouts; remove invalid/deprecated INI diagnostics applied before request initialization.

Check your configuration

grep -rnE 'session\.upload_progress\.(enabled|name)' \
  /etc/php/ /etc/php.ini /etc/php.d/ /etc/php-fpm.d/ \
  /usr/local/etc/php/ 2>/dev/null

After patching: triage and secret rotation
Because the first attacks preceded the patch, patching is not the end of the response. Treat “we patched” and “we were not hit” as two separate questions.

Triage (read-only). Verify the FPM binary version that actually serves the site; look for a burst of “Allowed memory size exhausted” fatals in FPM logs around October 21; review the busiest POST targets for endpoints that never take uploads; flag unexpected PHP files in public/ and storage/ and run git status; and check persistence (cron, authorized_keys, recent SSH logins, odd outbound connections).

Rotate secrets. Because this is also a memory-disclosure bug with a pre-patch window, rotate anything that lived in PHP worker memory: app keys (e.g. Laravel APP_KEY — keep the old one in APP_PREVIOUS_KEYS so existing sessions/encrypted data keep working), database credentials, third-party API keys, and any origin TLS private keys on the same host.

Close the WAF gap. Edge WAF rules (e.g. Cloudflare) only help if the origin is not directly reachable. Ensure no DNS record points at the origin unproxied, and restrict ports 80/443 on the origin to the WAF/CDN IP ranges.

Indicators of Compromise (IOCs)

The following source IP addresses were observed by Amazon Threat Intelligence in its MadPot honeypot network while attempting to exploit php2shell (CVE-2026-109618 and CVE-2026-109619):

Note: Per AWS, these addresses include shared anonymization infrastructure and are not exclusive to this threat activity. Organizations should investigate any observations involving these addresses rather than block them outright.

12. BLACK KITE PERSPECTIVE: PHP2SHELL IN THE SUPPLY CHAIN

The real story of php2shell is not a single server; it is scale. PHP is the invisible foundation of third-party ecosystems — even if an organization runs no PHP on its own assets, the web portals, customer panels and e-commerce infrastructure of its critical suppliers very likely run on it. This is a textbook case of cascading risk: a single core flaw travels downstream through third and fourth parties.

From a third-party cyber risk management (TPCRM) standpoint, the critical question is: "Which of my suppliers are affected by this vulnerability, and which should I reach first?" The Shodan data points to a clear priority here: 72.5% of the version-disclosing exposure sits on EOL branches that will get no patch; those suppliers are not a "just patch it" group but an "upgrade the branch or take it off the internet" group.

FocusTag®: Bridging a Global Threat to Your Ecosystem Risk

Black Kite®’s FocusTag® approach is designed precisely to close this gap: it takes a global threat (here, php2shell) and connects it to concrete, named risks in your own supplier ecosystem. A FocusTag® turns "there is a critical PHP vulnerability somewhere on the internet" into "these suppliers in your ecosystem run the affected version range, and here is how exploitable they are."

• External, non-intrusive detection. Determine which suppliers run internet-facing PHP, and their exposure profile, from external signals without sending the supplier a single questionnaire.
• Prioritization. Instead of "patch everything," "go to these suppliers first": those running EOL PHP, exposed to the internet and hosting high-value applications.
• Nth-party visibility. See where the risk concentrates not only in your direct suppliers but in the sub-suppliers they depend on (your Nth-party ecosystem).

As the window from disclosure to first exploitation keeps shrinking — and in this case a working exploit is already proven — a defensible supply-chain posture is measured by speed and precision. The right question is not "are our servers patched?" but "is our entire cyber ecosystem patched?"

Black Kite's php2shell FocusTag® details critical insights on the event for TPRM professionals.

REFERENCES

https://www.php.net/archive/2026.php#2026-10-21-5

https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

https://www.upwind.io/feed/initial-assessment-php2shell-two-critical-unpatched-php-rces-cve-2026-109618-cve-2026-109619

https://watchtowr.com/intelligence/php-cve-2026-109618-faq/

https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities

https://sansec.io/research/php2shell

https://thehackernews.com/2026/10/php2shell-two-unpatched-critical-php.html

https://www.bleepingcomputer.com/news/security/php-warns-admins-of-two-critical-flaws-emergency-patches-coming-tomorrow/

https://blog.virustotal.com/2026/10/sizing-php-exposure-window-for-cve-2026.html

https://pentestit.com/php-cve-2026-109618-and-cve-2026-109619-what-we-know-about-php2shell/

https://cert.europa.eu/publications/security-advisories/2026-018/pdf

https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619

https://laracraft.tech/en/blog/php2shell-were-you-hit-a-read-only-triage-script-for-your-server