1. Overview.
On October 21, 2026 Wiz Research published an analysis of PHP2Shell. The discovered bugs affect the PHP core and allow code execution without authentication or disclosure of process memory. The researchers demonstrated attacks against WordPress, Drupal and Joomla. These are examples of affected applications: the root cause is in the interpreter, not in individual CMS plugins.
According to Wiz, at least one of the bugs is present in versions starting from PHP 5.4. The exploitability of a specific server depends on version, configuration and request handling. Source: Wiz Research study.
2. What these vulnerabilities are.
PHP2Shell — a collective name for two critical memory safety vulnerabilities. In the PHP Group bulletin they are described as follows:
- CVE-2026-109618 — state corruption on out-of-memory (OOM). Memory allocation failure interrupts the initialization of request data. During cleanup, partially constructed structures can be treated as valid, creating conditions for memory corruption and code execution.
- CVE-2026-109619 — use-after-free of stale global state. Internal references survive the freeing of request memory. A subsequent request handled by the same worker process may access them before normal initialization completes.
Both issues affect the PHP engine. Updating a CMS and its extensions alone does not fix the interpreter. Source: PHP Group, 21.10.2026.
The overall problem is related to abnormal termination of a request: after memory is freed, PHP’s internal state may contain stale references. A following request then uses invalid data. The study examines upload progress handling, deserialization, fatal error tracing and OPcache.
Memory leakage is a standalone risk: it can expose passwords, tokens and API keys. Command execution is not required for such leakage. Wiz also notes the role of AI in finding bugs and adapting exploit development chains.
3. Fixed versions and mitigations.
The PHP team released fixes for CVE-2026-109618 and CVE-2026-109619. You should check the environment serving web requests: PHP-FPM, mod_php, CGI or any other request handler in use.
| PHP branch | Fixed release |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
For distribution packages, check the vendor bulletin: the fix may be backported into a package without matching the upstream release number. For PHP 8.1 and older you must confirm that your vendor provides a supported fix or plan migration to a supported branch.
Temporary mitigations only close specific attack paths. For example, disabling session.upload_progress.enabled requires configuration before request parsing and a restart of all worker processes. It does not eliminate other variants. The full remedy is to upgrade PHP. Details and limitations are provided in the PHP team bulletin of October 21, 2026.
4. Practical infrastructure check.
4.1. Inventory.
For initial collection of information about the installed command interpreter, you can use the following commands that show the version, configuration paths, and loaded modules:
php -v
php --ini
php -m4.2. Update control.
For each service record the owner, Internet exposure, handler in use, package version, and confirmation of the fix. After updating, check logins, file uploads, background jobs, and other critical application operations. For containers, verify the image of the running instance, not just the updated tag in the registry.
5. Signs of an attack.
Some processing occurs before application code is executed. Therefore the CMS log may contain few details, and the absence of suspicious events does not confirm that there was no attack.
For an initial search Wiz recommends correlating unusual multipart requests with out-of-memory errors, HTTP 500 responses, anomalous cookies PHPSESSID and PHP worker restarts. These are reasons to investigate, not proof of compromise.
In practice it is useful to combine web server access/error logs, PHP-FPM logs, and process telemetry on a single timeline. In PHP-FPM the error log location is set by error_log; sending to syslog is possible. Crashes and associated restarts should be considered when analyzing pool stability. See PHP-FPM documentation.
5.1. What to correlate in logs and telemetry.
- Unusually large or corrupted values of
PHPSESSIDin server responses. - Anomalous multipart requests, including chunked transfer or absence of
Content-Length, many parts and unusual field names; their temporal correlation with out-of-memory errors and HTTP 500 is especially important. - Unexplained crashes and restarts of PHP worker processes.
- Atypical child processes of the web server.
- New PHP files in the web directory, changes to cron jobs and SSH keys, outbound connections to previously unseen addresses. Such events require context investigation.
5.2. Actions upon suspected compromise.
Coordinate node isolation with the response team, preserve web server and PHP logs, process telemetry, and information about modified files. Determine which secrets were available to the PHP process. Upon confirmed compromise or reasonable suspicion of leakage, revoke affected tokens and keys, change passwords and terminate relevant sessions; issue new secrets in a trusted environment.
6. Conclusion.
Complete the review by confirming the fixed package in the running web handler and the results of a functional site check. It is useful to record the date, responsible person, verified version, and a link to the vendor bulletin in the work card. If signs of compromise are found, the update should be supplemented with an investigation and assessment of whether affected credentials need to be revoked.