php2shell: Critical PHP Vulnerabilities and What to Do Now

In short: Update PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or install the patched packages from your distribution, and then restart every PHP process. Configuration changes only reduce the risk for individual attack paths. Also check appliances and third-party products that ship with PHP. Information as of October 26, 2026 – we will update this article as the situation develops.

What is php2shell?

php2shell (also written PHP2Shell) is the collective name for two vulnerabilities in the PHP runtime itself rather than in a specific application: CVE-2026-109618 and CVE-2026-109619. The PHP project published both CVE records on October 21, 2026, and rated them critical with a CVSS 4.0 score of 9.2 out of 10 (CVE-2026-109618, CVE-2026-109619). Both can lead to remote code execution: an attacker runs their own code on the server over the network, without logging in, with the privileges of the web server process.

According to the CVE records, the vulnerabilities were reported by Wiz, Calif.io, and OpenAI. Wiz Research describes how AI models were instrumental in finding flaws that had been present in the code for more than a decade and in turning them into working exploits. Wiz states that every PHP version released in the last ten years, going back to PHP 5.4, is affected by at least one of the issues (Wiz Research, Oct 21, 2026).

The timeline:

• October 20, 2026: The PHP project announces an upcoming security release for two critical vulnerabilities.
• October 21, 2026, 13:30 UTC: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 are released together with a security advisory and two detailed technical advisories (PHP security advisory, Oct 21, 2026).
• October 23, 2026: In an informational advisory, PHP recommends disabling session.upload_progress until the next regular bugfix release to fully protect against another attack path it considers unlikely (PHP informational advisory, Oct 23, 2026). CERT-EU tracks this third issue as CVE-2026-115560 (CERT-EU Security Advisory 2026-018). As of October 26, 2026, no public CVE record had been published for it.

Which versions and systems are affected?

According to PHP, every installation that serves web requests is at risk – whether through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, or LiteSpeed. The fixes are included in these versions:

• PHP 8.5: 8.5.12 and later
• PHP 8.4: 8.4.27 and later
• PHP 8.3: 8.3.36 and later
• PHP 8.2: 8.2.35 and later
• PHP 8.6 (pre-release): 8.6.0 RC4 and later – not intended for production use
• PHP 8.1 and older: no longer updated by the PHP project. Some distributions and long-term support vendors provide backported fixes. As an exception, the PHP security team has published minimal source backports for PHP 7.4, 8.0, and 8.1.

Linux distributions received the patches in advance, so a package may already be fixed even if it carries an older version number. What counts is the security notice from your distribution (PHP security advisory).

How exposed a system is depends on how PHP runs:

• Apache with mod_php: highest risk. The demonstrated attack works with a single unauthenticated request before any application code runs.
• PHP-FPM: For CVE-2026-109619, an attack path via the session upload progress feature has been validated, although it requires a suitable operation in the application. For CVE-2026-109618, PHP considers FPM susceptible based on source analysis; the advisory does not report a complete exploit.
• FrankenPHP: according to the advisory, likely susceptible to attacks that do not depend on the application.
• LiteSpeed (LSAPI): application-specific attacks are considered likely but have not been validated.

This assessment comes from the PHP project's two advisories (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).

Two points are easy to miss. First, updating WordPress, Drupal, Joomla, or any other application is not enough, because the flaw lives in the underlying PHP runtime (CIRCL TR-102). Second, PHP is also embedded in appliances, network devices, management interfaces, and other vendor products where you cannot update PHP yourself. Siemens, for example, lists its RUGGEDCOM APE1808 platform as affected (Siemens entry in the CVE record). The Dutch NCSC maintains a continuously updated list of affected and unaffected products (NCSC-NL php2shell).

How the vulnerabilities work

Both flaws arise where PHP aborts a request because of a severe error – above all when the permitted memory (memory_limit) is exhausted.

CVE-2026-109618 – memory corruption on out-of-memory aborts: On an out-of-memory error, PHP leaves the current execution context via longjmp(). If this happens while internal request data is only partially initialized, the subsequent cleanup routine treats invalid data as valid. According to the advisory, an attacker can deliberately trigger the memory exhaustion with crafted multipart requests, that is, manipulated form uploads: for example, without a usable declared length, with a very large number of headers per part, or with nested, empty file fields. With mod_php, all of this happens before the application even starts (GHSA-w8hw-w9fx-j79w).

CVE-2026-109619 – stale global state: A PHP worker keeps global state, for example for errors, sessions, or extensions, that points into the memory of a single request. When a request is aborted, this state is not always reset. A later request handled by the same worker can then reuse memory that has already been freed (use-after-free). Confirmed paths include the session.upload_progress feature, which is enabled by default and does not require the application to call session_start(), and, on PHP 8.5, the fatal_error_backtraces setting (GHSA-6wmf-4rv5-p3rp).

Wiz says it chained the flaws into a single exploit and used it to execute code without authentication on the then-current container images of WordPress, Drupal, and Joomla. In addition, it was possible to read memory of the PHP process that can contain passwords, tokens, API keys, or certificates belonging to other requests; Wiz compares this to Heartbleed (Wiz Research). This matters for the follow-up: an unpatched server may have leaked secrets even if no code was executed.

Is php2shell already being exploited?

On October 21, 2026, the US agency CISA assessed in its enrichment of the CVE records that no exploitation was known. As of October 23, 2026, php2shell was not listed in its Known Exploited Vulnerabilities (KEV) catalog (CISA KEV). At the same time, CERT-EU points out that technical details are being discussed publicly and that initial proof-of-concept exploits are circulating, which raises the likelihood that attackers are already exploiting the vulnerabilities (CERT-EU). Numerous exploit and scanner projects are now publicly available (own research, as of October 26, 2026). Assume that internet-facing PHP servers are being actively searched for and attacked.

Immediate actions: update first

The PHP project and CERT-EU agree: only an update fully closes the vulnerabilities. Proceed in this order:

1. Take inventory: Identify every PHP runtime – on your own servers, in containers and images, at hosting providers, and in third-party products. Start with internet-facing systems. On the command line, php -v shows the version. The X-Powered-By header only reveals it if it has not been disabled, and it says nothing about backported patches.
2. Update: Install PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or the patched packages from your distribution. Then restart every PHP worker, including PHP-FPM pools and Apache – only then does the fixed code run.
3. Ask hosting providers and vendors: With shared hosting, managed servers, and appliances, the update is up to the provider. Ask whether and when the systems will be patched, and follow vendor notices, for example via the overview maintained by NCSC-NL.
4. Replace outdated versions: PHP 8.1 and older no longer receive updates from the PHP project. Move to a supported branch, or use a verified backport from your distribution or LTS vendor.
5. Isolate if you cannot patch: CERT-EU recommends disconnecting affected applications from the internet, if necessary, until the update has been applied and verified.

If you cannot update immediately, the following interim measures reduce the risk for specific attack paths. They explicitly do not make an installation safe (PHP security advisory):

• Disable session upload progress: Set session.upload_progress.enabled=0 in php.ini, the FPM pool, or the server configuration and restart every worker – not via ini_set() or .user.ini. This blocks the confirmed session paths and, according to the October 23 advisory, the third attack path as well. If you do not need this rarely used feature, the advisory suggests keeping it disabled even after updating.
• Remove the memory limit: Set memory_limit=-1 in a way applications cannot override, for example with php_admin_value. This removes the controllable memory limit the confirmed exploit relies on. Without a limit, however, a single process can consume unlimited memory, so cap memory with containers or cgroups, ideally so that only the affected worker is terminated. RLIMIT_AS or RLIMIT_DATA are not a substitute, as they trigger exactly the vulnerable code path.
• Limit requests: Keep post_max_size low – 8M for applications without file uploads, 32M with uploads – and keep upload_max_filesize below it. In addition, limit the request size, number of fields, multipart parts, headers, and nesting depth at the web server or proxy, including for requests without a Content-Length. If an application does not use multipart forms, block them before they reach PHP.
• PHP 8.5: Set fatal_error_backtraces=0 and restart every worker.
• Avoid warnings before startup: Remove invalid or deprecated INI settings that are applied per request and emit warnings, for example via php_value in an .htaccess file. Hiding warnings with error_reporting, display_errors, or @ does not help.
• Close error sources: Fix fatal errors and execution timeouts that an attacker can trigger deliberately, including in upload, import, and cleanup routines.

Several providers, including Cloudflare, Fastly, and Google Cloud, have prepared protective measures and guidance for their customers (Wiz Research). A web application firewall buys time but does not replace the update.

Detecting signs of an attack

The attacks take place below the application layer, so application logs often contain little. Wiz lists the following signals worth investigating:

• unusual multipart requests followed by memory limit errors or repeated HTTP 500 responses
• unexpectedly large or malformed PHPSESSID cookies in server responses
• PHP workers that restart frequently for no apparent reason

For a targeted review, the PHP project recommends enabling log_errors=On, a working error_log, and error_reporting=E_ALL in an isolated environment. Then search the Apache, PHP-FPM, and reverse proxy logs for repeated warnings, fatal errors, and Maximum execution time exceeded. Missing entries, however, do not prove that no attack took place (GHSA-6wmf-4rv5-p3rp).

If an internet-facing server ran an affected version before the update, check after patching whether credentials, tokens, and keys processed by that server need to be rotated – because of the possible memory disclosure, even without any sign of code execution. If you have a concrete suspicion, a compromise assessment clarifies whether attackers left traces such as web shells or new accounts. If an attack is already visible, report the emergency directly to our team.

Not sure where PHP runs in your environment? A vulnerability assessment identifies your internet-facing systems, including their versions, and prioritizes the findings. Whether your web applications are vulnerable beyond php2shell is shown by a web application penetration test.

Checklist: working through php2shell

• Every PHP runtime is inventoried, including in containers, at hosting providers, and in appliances
• Internet-facing systems run PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a confirmed backport
• Every PHP worker was restarted after the update
• Systems on PHP 8.1 and older have been replaced or secured with a maintained backport
• session.upload_progress.enabled=0 is set as long as the feature is not needed
• Vendor and hosting provider notices for the products in use have been reviewed
• Logs have been checked for the signals listed above
• Credentials and keys on exposed systems have been assessed and rotated where necessary

Conclusion: patch, restart, investigate

php2shell does not affect a single application but the platform that runs a large part of the web – according to Wiz, around 70 percent of all websites. What matters now is updating the PHP runtime wherever it processes requests from the network, restarting every worker, and following up with vendors on systems you cannot patch yourself. Interim measures only help against individual attack paths. If you ran unpatched servers on the internet, check them for traces afterwards and rotate their secrets.

Sources

All sources accessed on October 26, 2026.

• PHP project: Security advisory: Critical remote code execution vulnerabilities, update now, Oct 21, 2026
• PHP project: Informational advisory: Session upload progress, Oct 23, 2026
• PHP project: GHSA-w8hw-w9fx-j79w – RCE via OOM corruption (CVE-2026-109618), Oct 21, 2026
• PHP project: GHSA-6wmf-4rv5-p3rp – RCE via stale global state (CVE-2026-109619), Oct 21, 2026
• CVE Program: CVE-2026-109618 and CVE-2026-109619, including the CISA assessment and vendor entries
• CERT-EU: Security Advisory 2026-018 – Critical Vulnerabilities in PHP, version 1.2 of Oct 23, 2026
• NCSC-NL: Operational information regarding the 2026 php2shell vulnerabilities
• CIRCL: TR-102 Critical Remote Code Execution Vulnerabilities in PHP
• Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, Oct 21, 2026
• CISA: Known Exploited Vulnerabilities Catalog, as of Oct 23, 2026
• CSIRTs Network: Overview of warnings from European CSIRTs (CNW-2026-04)