PHP Vulnerability PHP2Shell: What to Do Now

The PHP vulnerability PHP2Shell affects all versions of the scripting language and hundreds of millions of web applications worldwide, and several hosters took websites offline as a precaution (including their own website). AI tools helped find the flaws, and a published patch itself becomes a race.

On October 21, 2026, shortly before 4 p.m., security updates for PHP were released that close two critical vulnerabilities. The German Federal Office for Information Security (BSI) rated the situation in a security advisory with criticality 3 (orange). Operators should therefore act immediately. In Germany, several websites were temporarily unreachable because operators disconnected their servers from the internet as a precaution.

The flaws can be understood without expert knowledge: a memory error leaves half-finished states behind, which PHP later processes incorrectly. What is affected is the runtime environment, not a single CMS. What is established, unconfirmed and open should be kept clearly apart. The information is current as of October 22, 2026, and details may change.

The PHP vulnerability at a glance

There are two vulnerabilities in the PHP programming language itself, not in a single content management system. They carry the identifiers CVE-2026-109618 and CVE-2026-109619. Both are rated critical with a value of 9.2 under the CVSS 4.0 scoring system (Common Vulnerability Scoring System, a scale from 0 to 10). From these values, the BSI concludes that exploitation requires neither a login nor user interaction. The goal is remote code execution (RCE), that is, running foreign program code on a server from a distance.

Reports also call this PHP vulnerability PHP2Shell. According to the BSI, the name is meant to recall the similarity to the Log4Shell vulnerability. It has nothing to do with the older WordPress flaw "wp2shell".

The timeline is documented by the announcements of the PHP project. On October 20, 2026, a pre-announcement without details was published. On October 21, 2026, the patches and the advisories followed at 14:00 UTC (4:00 p.m. German time). In its BSI security advisory of October 21, 2026 (version 1.1) (the document carries the identifier BITS-H No. 2026-297981-1132, while the URL contains 1032), the BSI writes that a proof of concept is public and that no confirmed exploitation is known yet. However, there are unconfirmed reports of exploits.

What is behind CVE-2026-109618 and CVE-2026-109619

Both flaws belong to the class of memory errors. Put simply, PHP works with memory areas that are reserved per request and released again afterwards. If something goes wrong, states arise that the rest of the program flow does not expect. This is exactly where the vulnerabilities strike. The following description is deliberately simplified and contains no attack details.

For CVE-2026-109618, the PHP project describes an abort on insufficient memory (out of memory). If this abort is triggered while the internal data of a request is only partly prepared, it leaves invalid states behind. During the subsequent cleanup of the request, PHP reads this data and branches on it. As a trigger, the advisory mainly names memory-intensive processing of form uploads (multipart/form-data). Large memory requests by the application itself can also trigger the error.

With CVE-2026-109619, in contrast, state from an earlier request remains in the so-called worker. A worker is a PHP process that serves many requests one after another. A later request can use this stale state before it is reset. So at least two requests that reach the same worker are needed. According to the advisory, confirmed paths are diagnostic messages about settings before initialization, the session upload progress and, in PHP 8.5, the function fatal_error_backtraces.

The situation is most dangerous with Apache using mod_php. An exploit was demonstrated there in which an unauthenticated request can trigger the attack before any application code runs. For PHP-FPM, a partial path was confirmed according to the advisory. What the flaws allow in an individual case depends on the environment. The patches reset the state completely and remove the cause.

Which PHP versions and systems are affected

According to the BSI's assessment, all known PHP versions are affected, going back to at least PHP 5. The flaws are fixed in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP update 8.5.12 applies to the newest branch, the other numbers to the respective older branches that are still supported.

For the already discontinued branches 7.4, 8.0 and 8.1, there are no regular updates any more. According to its security announcement, the PHP Security Team provided minimal backports in the source code. A backport transfers a fix to an older program version without raising the version number. Linux distributions and vendors with long-term support (LTS) partly ship their own fixes. For PHP 8.2, security support ends on December 31, 2026. A branch without support is considered End of Life (EOL).

According to the BSI and the PHP project, all PHP installations that process web requests are affected. Named are PHP-FPM (a process manager that provides PHP for web servers), Apache with mod_php (PHP as a module in the web server), php-cgi, FrankenPHP and LiteSpeed. The statements are not entirely consistent. For some environments, the GitHub advisories name only a suspected or unvalidated path. The only safe conclusion is therefore: anyone running PHP for websites should assume they are affected until proven otherwise.

In addition, the vulnerabilities affect the runtime environment and not a single application. The BSI makes clear that updating the application is not enough. Among the PHP-based projects, the BSI mentions WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense and OPNsense as examples. A WordPress update alone therefore does not fix the flaws; what matters is the PHP version on the server.

How AI found the flaws

It is documented that AI tools played a role in the discovery. According to the BSI, the companies Wiz and Calif were involved in the discovery. The role of other parties such as OpenAI remains open here. Calif describes that publicly available language models were used as assistants, for example to look for ways around the memory limit and to analyze memory management. According to the post, no special test environments or non-public models were used. The authors stress at the same time that knowledge of the target system remained decisive. A model does not simply find "all bugs" through a simple prompt. Calif points to a memory limit bug in PHP from 2004 as a prehistory.

Wiz also reports an AI-assisted discovery. Frontier models, it says, lowered the barrier to chaining bugs into a working exploit and adapting it to different PHP versions and configurations. Which models exactly were used and how large the share of human and machine was cannot be independently verified from the vendors' statements. Both posts come from parties involved and are also self-promotion. The statements should be read as self-reporting.

The dates given for the discovery differ. Calif names August 1, 2026 for the first findings and August 11, 2026 for the first report to PHP. Wiz names August 19, 2026 for the first flaw discovered and August 24, 2026 for the report to the PHP security team. Both accounts can stand side by side because several groups worked independently. Which group reported first cannot be settled conclusively from the sources.

An assessment by the author: the same tools are in principle also available to attackers. That is an evaluation, not proof that they were used for attacks in this case.

Patch diffing: how a security fix can become an exploit

The term patch diffing does not appear in the BSI warning. Here it is the author's technical name for the process the BSI describes. In patch diffing, the changes between the old and the new program version are compared. The difference shows which spot was repaired and thus where the vulnerability lay. For open-source projects like PHP, the patch can be inspected publicly as soon as it is released.

The problem: from the moment of release, not only defenders know the spot, but attackers as well. Whoever turns the difference into a working attack faster than operators can update gains a window of time. According to the BSI's assessment, AI tools can shorten this analysis. The BSI considers a broad exploitation within a few hours after the patches appear in the short term to be "likely". As justification, it writes: "At the latest since the emergence of AI-based tools for exploit development, actors have the means to analyze patches within a short time and generate exploits." (translated from German)

This is an assessment by the BSI, not an observed fact. A concrete case in which malicious AI carried out patch diffing here is not documented in the sources. In its update of October 21, 2026, the BSI considers short-term exploitation of vulnerable systems likely because of the technical details now available. Social media reports first attack attempts that could not be verified.

A simple rule follows for operators: the window between the release of a patch and its installation should be kept as small as possible. In the author's view, exactly this window of a few hours, for a flaw announced in advance, was an important reason for the shutdowns. A statement by the hosters on this is not available in every case.

Why hosters took websites offline

The BSI writes in update 1 that some operators of PHP web servers disconnected systems from the internet in the course of the day as a precaution, to prevent attacks via the temporarily unpatched flaws. As a result, various websites in Germany were temporarily offline or only partly reachable until the affected servers were updated. Providers of web application firewalls (WAF), that is, filters in front of web applications, including Cloudflare and Bunny Shield, published rules for the attack paths known so far. According to the BSI, only patching or disconnecting from the internet offers complete protection.

The hoster mittwald serves as an example. The provider's status entry is titled "Precautionary restrictions due to the current PHP vulnerability" (translated from German). It began on October 21, 2026 at 2:16 p.m. (CEST) with the announcement that form uploads would be disabled in advance. At 4:17 p.m., mittwald wrote that a risk to the systems could not be ruled out, so all systems would be shut down and incoming web traffic blocked. Email remained functional. According to the entry, the patches for PHP 7.2 to 8.5 were rolled out by 10:52 p.m.

On October 22, 2026 at 12:28 a.m., the entry was set to "Resolved". The flaw was fixed for nearly all affected versions, except versions below PHP 5.6 without official security updates. According to mittwald, there were no indications of exploitation. For other hosters, no verified primary sources are available.

The reasoning behind the shutdowns follows from the situation. Many customer projects with different PHP versions run on a hosting platform. Every variant must be patched, tested and restarted. That takes time. The flaws can be exploited remotely without a login, and the details were public from the release date. A temporary block on incoming traffic is then the measure that, according to the BSI, reliably protects. Whether a platform does so is a trade-off between availability and risk. How many websites were affected in total is not documented. Figures in the millions are not documented in the primary sources reviewed.

What operators of PHP and WordPress websites should do now

With shared hosting and managed hosting, responsibility for PHP usually lies with the provider. Here it helps to look at the status page and, if necessary, ask support. Things the hoster manages should not be changed on your own. Anyone who runs their own server or virtual server must act themselves. The BSI recommends the following steps:

1. Check the PHP version, on the server with php -v or in the hosting panel. For Linux packages, compare against the distribution's status, since fixes often appear as a backport without a new version number. Ubuntu, Debian and Red Hat publish their own advisories.
2. Patch: to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to the distribution package with the fix.
3. Rebuild applications in Docker containers, since they contain their own PHP.
4. Migrate discontinued versions to a supported branch or secure them with an LTS provider.
5. If a patch is not immediately possible: disconnect the server from the internet temporarily. If neither patching nor disconnecting is possible, implement at least the workarounds of the PHP project.
6. Use a WAF as a supplement, restrict access to web applications and harden components.
7. Monitor logs and servers for anomalies. According to the BSI, there are no binding indicators of compromise yet.

For the workarounds, the PHP project names, among others, memory_limit=-1 (preferably set so that applications cannot override it), a low post_max_size, session.upload_progress.enabled=0 and, for PHP 8.5, fatal_error_backtraces=0. Afterwards, all workers must be restarted. RLIMIT_AS and RLIMIT_DATA should not serve as a substitute.

Why workarounds are no substitute for the update

In its update on the situation, the BSI states:

The BSI sees the workarounds only as a stopgap and requires that all of them be implemented together. The measures of the PHP project reduce the attack surface but do not close it. Each workaround blocks one confirmed path, for example via sessions or backtraces, while other variants remain unblocked. With the memory limit bug, a failure of the underlying memory allocation can also still reach the vulnerable code path. The PHP project writes in both advisories that only an update with the complete state reconciliation protects reliably.

The stopgap still makes sense when an update fails because of organizational hurdles, for example with software that only runs on an old PHP version. The approach should then be understood as an emergency measure that is documented and time-limited. Lasting security arises only from a supported PHP version and a well-maintained system.

What is still open

With such a recent situation, many points remain unresolved. The three-way split into documented, unconfirmed and open helps.

• Actual exploitation: The BSI knows of no confirmed attacks, but of unconfirmed reports of exploits and attack attempts. How this develops is open.
• Release date: The PHP project reserved the right to release earlier if details became known. Media reports mention a leak. Calif and Wiz, by contrast, describe a coordinated disclosure. A leak cannot be proven from primary sources.
• Number of affected websites: Wiz writes that PHP runs on roughly 70 percent of all websites but cites no source for it. That does not qualify as a reliable figure.
• Status at individual hosters: A verified status report exists only for mittwald. For other providers, the status should be requested from them if needed.
• Further variants: The advisories point out that there is no complete generic configuration measure. Further paths are not ruled out.
• Role of AI: Its use in the discovery is documented by the vendors. Its use by attackers is an assessment by the BSI, not an observed case.

In short: the PHP vulnerability is real, critical and, since October 21, 2026, fixed by updates. Anyone who runs PHP themselves must install the update; for everyone else it depends on the hoster. The question of AI-assisted exploitation remains for now a justified concern and not a proven finding.