Executive Summary
- What it is: php2shell is the name for two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. They can allow unauthenticated remote code execution (RCE).
- Who is affected: Any PHP installation serving web requests is exposed, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Risk is highest for mod_php, where PHP has demonstrated an exploit.
- How to find your exposure: Use Anya, the “PHP RCE (Oct 2026)” saved view on the Findings page, and an AQL v2 query to see which applications and assets are affected.
- How to fix it: Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution’s patched package. PHP 8.1 and older have no official release, so use a vendor backport or upgrade.
On October 20, 2026, the identifiers for two critical PHP vulnerabilities leaked online before coordinated disclosure. PHP responded with an advance notice, and on October 21 it shipped emergency releases and a full advisory. Both flaws, CVE-2026-109618 and CVE-2026-109619, are rated CVSS v4.0 9.2 and can allow unauthenticated remote code execution (RCE). Researchers are calling the pair php2shell.
The risk is broad. PHP says all installations serving web requests are exposed, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where it has a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.
This post covers what the flaws are, who is affected, what to patch and mitigate, and what to watch for in your telemetry.
Why php2shell is different from other PHP vulnerabilities
Most PHP incidents are application bugs: a vulnerable plugin, a misconfigured CMS, an injectable parameter. These two sit in the PHP core, and that changes the blast radius.
- It sits below your application code. Because the attack can run before any application code does, fixing plugins and frameworks, or filtering at the application layer, will not close it. Updating the runtime will.
- PHP is embedded everywhere. It powers WordPress, Drupal, Joomla and Magento, plus control panels, vendor appliances, Windows software that bundles php.exe or php-cgi.exe, and container base images. Much of it never appears in a package manager inventory.
- Many affected versions will not get an official release. PHP 8.1 and older no longer receive updates from the PHP project, and one analysis estimates roughly 884,000 internet-facing hosts run such versions.
To be clear about what this is not: nobody has reported that PHP’s source, build pipeline or releases were tampered with, so this is not a supply chain compromise like xz or Shai-Hulud. It is a vulnerability in a runtime that your supply chain is full of, which makes it a supply chain exposure problem all the same.
What PHP confirmed
| Item | Details (from PHP’s advisory) |
| CVEs | CVE-2026-109618 and CVE-2026-109619 |
| Impact | Unauthenticated remote code execution |
| Severity | CVSS v4.0 9.2 for both |
| Fixed versions | PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 |
| Highest risk | Apache with mod_php, where PHP has a demonstrated exploit |
| Also affected | PHP-FPM, php-cgi, FrankenPHP and LiteSpeed |
| Mitigations | Interim measures exist for specific attack paths, but PHP says they do not make an installation safe |
How the bugs work
CVE-2026-109618: RCE via out-of-memory corruption
When PHP runs out of memory, the out-of-memory handling can interrupt it while internal request data is only partially initialized. Request cleanup may then treat that invalid data as valid, which leads to memory corruption and code execution. The advisory is tracked as GHSA-w8hw-w9fx-j79w.
CVE-2026-109619: RCE via stale global state
Request-owned internal state can survive after the memory backing it has been freed. A later request handled by the same worker may then use that stale state before normal initialization resets it. The advisory is tracked as GHSA-6wmf-4rv5-p3rp.
Both are memory-safety flaws in how PHP handles request lifecycle and failure paths, which is why they sit in core and not in any single extension or application.
Which PHP versions are affected by php2shell?
| Branch | Status | Fix |
| 8.5 | Vulnerable below 8.5.12 | 8.5.12 |
| 8.4 | Vulnerable below 8.4.27 | 8.4.27 |
| 8.3 | Vulnerable below 8.3.36 | 8.3.36 |
| 8.2 | Vulnerable below 8.2.35 (PHP 8.2 reaches end of life on December 31, 2026) | 8.2.35 |
| 7.4, 8.0, 8.1 | Affected. PHP published minimal source backports for these branches. | No release. Vendor backport, source backport branch, or upgrade. |
| 7.0 to 7.3, 5.x | Reported affected by third-party research. PHP’s advisory does not state the earliest affected version. | None from PHP. Upgrade or isolate. |
Distribution packages often backport fixes without changing the upstream version string, so a vendor package can be patched while still showing an older version. PHP says Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. PHP also warns that the volunteer-run Remi repository would not have updates available on release day, and recommends distribution packages or building from source.
How to detect php2shell (CVE-2026-109618, CVE-2026-109619) with ArmorCode
Speed matters now that exploit details are public. These are the fastest ways to answer “are we affected?” across your portfolio.
1. Ask Anya
Start with Anya, ArmorCode’s security champion, where you can ask targeted questions such as:
- Am I impacted by CVE-2026-109618 or CVE-2026-109619?
- Show me all applications, services, and workloads exposed to CVE-2026-109618 or CVE-2026-109619.
- Have any new findings related to CVE-2026-109618 or CVE-2026-109619 been detected in the last 24 hours?
2. Findings Page: (Absolute Detections)
A pre-built saved view “PHP RCE (Oct 2026)” is available on the Findings page. It covers both the CVE IDs to get one triage queue across all your connected scanners. Sort by internet exposure and asset criticality to decide what to patch first.
3. Exploration Required (Potential Detections)
To hunt for potential or indirect exposure across environment, security engineers can use ArmorCode Query Language (AQL v2) to run a targeted query:
(componentName LIKE '%php%' OR componentName LIKE '%PHP%' OR summary LIKE '%PHP %') AND (componentVersion LIKE '5.%' OR componentVersion LIKE '7.%' OR componentVersion LIKE '8.0.%' OR componentVersion LIKE '8.1.%' OR componentVersion LIKE '8.2.%' OR componentVersion LIKE '8.3.%' OR componentVersion LIKE '8.4.%' OR componentVersion LIKE '8.5.%' OR summary LIKE '%PHP Unsupported%' OR summary LIKE '%PHP 5.%' OR summary LIKE '%PHP 7.%' OR summary LIKE '%PHP 8.0%' OR summary LIKE '%PHP 8.1%' OR summary LIKE '%PHP 8.2%' OR summary LIKE '%PHP 8.3%' OR summary LIKE '%PHP 8.4%' OR summary LIKE '%PHP 8.5%') AND componentVersion NOT IN ('8.2.35', '8.3.36', '8.4.27', '8.5.12') AND status NOT IN ('CONTROLLED','MITIGATED')
Group these findings by Sub-Product, Application, or Asset Name to isolate affected areas. Confirmed findings can then be assigned to development teams or remediation workflows.
If you cannot update immediately
PHP is explicit that only an update is a complete solution. The following measures reduce exposure to specific attack paths and do not make an installation safe. Treat them as a bridge to a patch window, not a substitute.
For CVE-2026-109618 (OOM corruption)
- Set memory_limit=-1, ideally in a way applications cannot override, such as php_admin_value in the FPM pool or Apache config. Check that no pool, directory or application setting puts a finite limit back. This removes the controllable memory-limit failure, but an underlying allocation failure can still reach the vulnerable path.
- Set a low post_max_size: 8M if your applications do not need file uploads, or 32M if they do, and keep upload_max_filesize below it. Also consider enforcing limits at the web server or proxy for decoded request size, input field count, multipart part count, header count and nesting depth, including for requests without a usable Content-Length.
- Use container or group memory limits as an availability boundary, ideally killing only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA, since they can cause vulnerable allocation failure.
For CVE-2026-109619 (stale global state)
- Set session.upload_progress.enabled=0 and restart every worker. Apply it in php.ini, an FPM pool or server configuration that takes effect before request parsing, not through ini_set() or .user.ini. This blocks the confirmed session paths but not other variants.
- On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
- Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
- Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing, and cleanup.
How to fix php2shell: patch and mitigation checklist
- Inventory every PHP install. Start with web servers, then look for control panels, vendor appliances, Windows software bundling PHP, container images and CMS stacks. Prioritize internet-facing hosts, and mod_php above the rest.
- Update to a fixed release. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution’s patched package. For vendor packages, check the changelog for the CVE IDs rather than comparing version numbers.
- Deal with PHP 8.1 and older. Ask your vendor about a backported fix, or upgrade to a supported branch. If you build from source, PHP published minimal backport branches for 7.4, 8.0 and 8.1. Plan ahead for 8.2 too, which reaches end of life on December 31, 2026.
- Apply interim mitigations where you cannot patch today, and treat those hosts as still exposed.
References
- PHP: Security advisory: Critical remote code execution vulnerabilities, update now
- GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- watchTowr: PHP Remote Code Execution FAQ: CVE-2026-109618 and CVE-2026-109619
- Huntress: Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities
Key Takeaways
- php2shell is two critical PHP core flaws. CVE-2026-109618 and CVE-2026-109619 are both rated CVSS v4.0 9.2 and can allow unauthenticated remote code execution (RCE).
- The risk is broad. Any PHP installation serving web requests is exposed, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php carries the highest risk because PHP has demonstrated an exploit there.
- Application-layer fixes won’t close it. The attack can run before any application code does, so only updating the PHP runtime fully fixes it.
- Patch to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution’s patched package. PHP 8.1 and older have no official release, so use a vendor backport or upgrade.
- Interim mitigations are a bridge, not a fix. PHP says they do not make an installation safe.
- ArmorCode shows your exposure fast. Use Anya, the “PHP RCE (Oct 2026)” saved view, and AQL v2 to find affected applications and assets.