PHP2Shell stems from the discovery of two critical vulnerabilities within PHP itself. Unlike many Web vulnerabilities, the issue does not lie in a specific website, plugin or content management system: it directly affects the PHP engine responsible for executing server-side code.

The two vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. Under certain conditions, a specially crafted request can trigger corruption of PHP's internal state and ultimately lead to unauthenticated remote code execution.

Their disclosure was initially intended to be coordinated, giving the different parties involved time to prepare their protections. However, information about the vulnerabilities, including their CVE identifiers and some risk-reduction measures shared with sensitive operators, began circulating publicly ahead of schedule. The disclosure timeline was therefore accelerated.

On October 21, 2026, the PHP team urgently released new versions fixing both vulnerabilities. The official security advisory urged all PHP users to update immediately.

Exploitation attempts even before public disclosure

One of the most significant findings emerged after the fixes were released. While retrospectively analyzing data from its detection infrastructure, Amazon Threat Intelligence identified an attempt targeting PHP2Shell as early as October 17, 2026.

This activity predates the official release of the fixes by four days. It shows that at least one actor was already attempting to exploit the vulnerabilities while their details were not yet officially available to the public.

Other cybersecurity organizations also observed requests or exploitation attempts before the disclosure. This does not mean that all of these attacks succeeded, nor that the targeted servers were necessarily compromised. But it significantly narrows the period during which administrators could assume that the risk would only begin once the vulnerabilities became public.

Which vulnerabilities are involved?

PHP2Shell does not refer to a single vulnerability. The name covers two distinct flaws discovered in PHP's internal workings: CVE-2026-109618 and CVE-2026-109619. Both can lead to remote code execution, but they do not rely on the same mechanism to achieve it.

In both cases, the issue lies in the way PHP handles certain data in memory while processing Web requests. An attacker capable of triggering a precise sequence of events can cause PHP to manipulate data that is no longer in the expected state.

CVE-2026-109618: triggering an error at the wrong time

The first vulnerability concerns how PHP handles situations in which it reaches its memory limit. When a script or the processing of a request consumes too much memory, PHP should normally stop the operation cleanly and release the resources being used.

CVE-2026-109618 can, however, be used to trigger this memory exhaustion during a particularly sensitive phase. Some internal data associated with the request may then remain only partially initialized, while PHP continues its cleanup operations as though that data were valid.

For a normal user, this type of error should at worst cause a request to fail. In this specific case, however, an attacker can attempt to gain enough control over the memory state to turn the error into an exploitable corruption and ultimately execute code within the context of the PHP process.

The vulnerability is particularly concerning when Apache is used with mod_php. The PHP team says exploitation has been demonstrated in this configuration before the Web application's code even begins to execute. A login page or access controls implemented directly within the application therefore cannot, on their own, prevent the vulnerability from being triggered.

CVE-2026-109619: data that survives the request

The second vulnerability relies on a different mechanism. When a Web request ends, the temporary data associated with it should normally be released, and the state required for the next request should be properly reset.

With CVE-2026-109619, however, some internal references can remain after the memory they pointed to has already been freed. If a new request is then handled by the same PHP process, this previous state can be reused before it has been properly reset.

In cybersecurity, this type of issue belongs to the family of use-after-free errors: a program continues to use an area of memory even though it should no longer be considered valid. By gaining sufficient control over what occupies that memory between operations, an attacker can attempt to influence the program's behavior.

In the case of PHP2Shell, researchers have shown that this sequence of events can also be used to achieve remote code execution. Exploitation may require multiple requests to be handled by the same PHP process, distinguishing it from the mechanism used by CVE-2026-109618.

Two different mechanisms, the same potential outcome

The two vulnerabilities should therefore not be confused. The first primarily exploits a memory-related interruption that leaves internal data in an inconsistent state. The second relies on references persisting after the data they pointed to has already been freed.

What they share is their potential consequence: on a vulnerable installation, when the necessary conditions are met, a remote attacker can achieve code execution without first having an account on the application.

Another consequence has also been demonstrated: some techniques associated with PHP2Shell can expose the contents of a PHP process's memory. That memory may temporarily contain sensitive information handled by applications, such as passwords, authentication tokens or API keys.

This technical severity alone, however, does not determine how many servers are actually exploitable. Running a vulnerable PHP version represents a first level of risk, but the server configuration, the way PHP is executed and the application's behavior can affect the available exploitation paths.

Who is actually exposed?

PHP2Shell's potential scale stems first from PHP's place in the Web ecosystem. The language is used directly by websites, applications, content management systems and many products that integrate it as a server-side technology.

The PHP team considers all PHP installations serving Web requests to be at risk. This includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. This does not, however, mean that all of these installations can be compromised in the same way or with the same level of ease.

The server configuration, the PHP version in use, the way requests are handled and the application's behavior can all affect the conditions required for exploitation. Among the configurations studied, the PHP team currently considers mod_php to present the highest level of risk.

Millions of potentially vulnerable instances

Initial measurements nevertheless provide an indication of the scale of the affected surface. According to telemetry data published by Unit 42, more than 22.6 million exposed instances have been identified as potentially vulnerable to CVE-2026-109618 and CVE-2026-109619.

This figure does not represent 22.6 million compromised servers, nor does it necessarily represent 22.6 million systems on which successful exploitation is possible. These are exposed instances with characteristics consistent with the affected versions.

Other analyses also point to very large numbers. Qualys says it identified 167 million PHP package installations across the customer environments it observed. Of the 156 million for which a version could be determined, a large proportion are located on Internet-accessible assets. These figures do not represent the entire Web and should not be directly extrapolated to estimate the number of vulnerable servers worldwide.

Using PHP does not mean being exploitable

This distinction is essential. A website can use PHP without running a vulnerable version. A server may also be running an affected version while using a configuration that makes a known exploitation path more difficult to reproduce.

Conversely, an installation that is directly accessible from the Internet, runs a vulnerable version and uses a configuration compatible with techniques already demonstrated faces a significantly greater risk. With Apache and mod_php, exploitation before the application's code begins to execute has notably been demonstrated.

In this situation, authentication within WordPress, Drupal, Magento or a custom-built application does not necessarily provide protection. The vulnerability can be triggered at the PHP level before the security mechanisms implemented by the application have a chance to intervene.

Software that embeds PHP may also be affected

Exposure is not limited to servers on which an administrator deliberately installed PHP to host a website. Commercial products, appliances and software can include their own PHP environment to power a Web interface or an administration service.

In these cases, users may not have direct access to the embedded PHP version and may depend on an update released by the product manufacturer. CERT-EU therefore also recommends checking third-party software that may include PHP.

Vulnerable, exploitable or compromised: three different levels

An installation is vulnerable when it runs an affected and unpatched version of PHP. It becomes effectively exploitable when an attacker can meet the conditions required to trigger one of the vulnerabilities in that specific environment.

A compromise represents another level entirely: it means that exploitation actually succeeded and that the attacker gained access or performed actions on the system. The millions of instances currently identified as potentially vulnerable therefore cannot be presented as an equivalent number of compromised machines.

This distinction is particularly important for PHP2Shell. The potentially affected surface is considerable, but only observing actual attacks and their consequences can establish the real impact of these vulnerabilities.

What can PHP2Shell actually do?

The most serious consequence associated with PHP2Shell is the possibility of achieving remote code execution, or RCE. In practical terms, when exploitation succeeds, an attacker can cause the server to execute instructions of their choosing without first having an account on the application.

This capability completely changes the nature of the incident. The attacker is no longer simply sending an abnormal request or causing an error in PHP: they can begin using the compromised process as an entry point into the system hosting the application.

The consequences are not identical on every server, however. The attacker's code runs within the context of the compromised PHP process. The permissions granted to that process, the operating system configuration, the isolation in place and the services accessible from the machine then determine what can be done next.

From code execution to server takeover

One of the first actions may be to run system commands. An attacker can use them to identify the environment they are in, the users present on the machine, installed software, accessible files and the network connections available from the server.

If permissions allow it, they may also download and execute an additional malicious payload. This could be a script, a tool designed to maintain access to the system, a program intended to steal information or software used to establish communication with infrastructure controlled by the attacker.

Remote code execution does not automatically mean that the attacker obtains the highest privileges on the system. A properly configured server may run PHP under an account with limited permissions. The attacker would then need to find other ways to escalate their privileges if they wanted broader control over the machine.

Conversely, excessive permissions, secrets accessible to the PHP process or poor server segmentation can significantly increase the consequences of an initial exploitation.

Application data may become accessible

A PHP process frequently handles sensitive information: database credentials, API keys, authentication tokens, environment variables, configuration files or data submitted by users.

Once able to execute code in this context, an attacker can attempt to retrieve information that the PHP process itself is authorized to access. Compromising a Web server can therefore expose far more than the content publicly visible on the website it hosts.

Research into PHP2Shell has also demonstrated the possibility of causing memory leaks. Part of a PHP process's memory may temporarily contain information from requests or applications handled by that same process.

This does not mean that exploitation automatically reveals every password or all of the data stored on a server. What can be recovered depends on what is actually present in memory at the time of the attack. This capability nevertheless creates an additional risk, particularly when it exposes information that can be used to continue a compromise.

A Web server can become an entry point into the internal network

The risk does not necessarily stop at the directly affected server. A Web application often communicates with other components: databases, storage systems, internal services, corporate directories, administration interfaces or APIs that are not directly accessible from the Internet.

An attacker who has achieved code execution on the server can then examine the connections available from that machine and attempt to reach these internal resources. The Web server, initially exposed to the Internet, can therefore become a stepping stone toward systems that were not directly exposed.

This progression is not automatic. It depends on the network architecture, filtering rules, credentials available on the server and their associated permissions. A properly segmented infrastructure can significantly limit the attacker's ability to move beyond the initially compromised system.

Data theft, persistence or use of the compromised machine

Once access has been obtained, the attacker's objectives can vary. Some may seek data or credentials, while others may attempt to establish persistent access so they can return to the server even after the original entry point is no longer available.

A compromised machine can also be used as a relay, become part of malicious infrastructure or receive additional software. The first activities observed around PHP2Shell already show that different types of actors are attempting to exploit the same attack surface for different purposes.

These possible consequences must, however, be distinguished from actions that have actually been observed. A vulnerability that theoretically allows code execution does not prove that an attacker has completed every subsequent step: privilege escalation, data theft, lateral movement within a network or the persistent installation of malicious software each require additional conditions.

What do we know about the attacks already observed?

PHP2Shell is no longer just a vulnerability demonstrated in laboratory conditions or targeted by exploitation attempts. Researchers have now observed successful exploitation resulting in remote code execution on honeypot systems, while U.S. authorities have officially recognized both vulnerabilities as being actively exploited in the wild.

On October 26, 2026, CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) Catalog. This marks an important shift: both vulnerabilities are now officially considered to be exploited in the wild.

This development still does not tell us how many servers have actually been compromised. The millions of requests, scans, and exploitation attempts recorded since disclosure should not be interpreted as an equivalent number of successful compromises.

A first attempt detected as early as October 17

Amazon Threat Intelligence identified an exploitation attempt in data from its MadPot honeypot network dating back to October 17, 2026, four days before the public disclosure of CVE-2026-109618 and CVE-2026-109619.

The request originated from an IP address associated with a commercial anonymization service. Amazon considers the targeting of a honeypot from such infrastructure to be consistent with malicious activity, but says it does not know how the actor obtained information about the vulnerabilities before they were published.

This observation is significant, but it must be interpreted carefully. Amazon describes an exploitation attempt detected by its infrastructure. The company says its analysis is ongoing, and it has not established that the attempt would have successfully compromised an actual vulnerable server.

Several actors were already active before the fixes were released

On October 21, a few hours before the embargo was scheduled to end, Amazon detected several proofs of concept as well as new attempts targeting its sensors. The first appeared in its telemetry at around 02:00 UTC, while the official disclosure was scheduled for 14:00 UTC.

Between 02:00 and 08:00 UTC, other anonymized infrastructures began targeting the same vulnerabilities. Differences in the payloads used and their source infrastructure led Amazon to conclude that several distinct actors were probably already testing PHP2Shell.

F5 Labs observed a similar development. Its global sensor network recorded the first scanning activity related to PHP2Shell at 08:36 UTC on October 21, more than five hours before the official publication of the two CVEs and their fixes.

Some of these early tools were not yet attempting to compromise machines directly. F5 notably observed requests designed to determine whether PHP's session upload progress mechanism was accessible. These probes can be used to identify servers that may meet the necessary conditions before attempting more complex exploitation.

A sharp acceleration after public disclosure

The release of the fixes and technical information then dramatically changed the scale of the activity. Additional proofs of concept appeared in the hours following disclosure and almost immediately began appearing across detection infrastructures.

F5 Labs says it recorded thousands of attempts during the first hours. Around 98% of the activity observed by its sensors targeted CVE-2026-109619, compared with around 2% targeting CVE-2026-109618.

Cloudflare observed an even greater increase across its network. Following disclosure, the volume of requests attempting to exploit PHP2Shell quickly rose into the hundreds of thousands and then into the millions.

The techniques being used are already evolving

The observed activity is not limited to reproducing a single proof of concept. Researchers have identified several request patterns, ranging from simple probes designed to check for the presence of the vulnerable mechanism to attempts actually seeking to trigger the conditions required for code execution.

A large proportion of the observed attacks use PHP's session.upload_progress mechanism. This feature normally allows PHP to track the progress of a file being uploaded to a server, but it also provides one of the paths through which the vulnerable memory states used by PHP2Shell can be reached.

Defenders have also observed malicious requests gradually adapting. As protections have been deployed, some attackers have modified their payloads and methods in an attempt to bypass rules implemented by Web application firewalls.

Attempts to deploy malware

The first campaigns also show that interest in PHP2Shell goes beyond technical research. Opportunistic actors have begun testing the vulnerabilities with the aim of deploying or executing malicious payloads on servers that may be compromised.

The activity being investigated includes attempts associated with malware designed to add machines to botnet-type networks. In some monitored environments, these attempts were blocked before the malicious payload could be executed.

This illustrates a common pattern following the disclosure of a critical vulnerability: several categories of actors can quickly reuse the same techniques. Some are simply looking for vulnerable systems, others are testing proofs of concept, while malicious operators are already attempting to turn the vulnerabilities into a means of gaining access to machines they can later use for their own purposes.

A government breach initially attributed to PHP2Shell can no longer be confirmed

Caution is also necessary when identifying potential victims. Unit 42 initially linked the compromise of a European government agency to the exploitation of PHP2Shell. That attribution was withdrawn on October 25 after researchers were ultimately unable to confirm that the initial access had occurred through CVE-2026-109618 or CVE-2026-109619.

This case highlights an important distinction between confirmed active exploitation of the vulnerabilities and attributing a specific compromise to PHP2Shell. The former is now established, the latter must be demonstrated separately for each incident.

The dramatic increase in the number of observed requests does not, however, provide a direct measure of the number of victims. The available data establishes significant malicious activity around PHP2Shell, but does not support the conclusion that the millions of potentially affected servers have been compromised on a widespread basis.

Fixes, protections and limitations

The priority response to PHP2Shell is to update PHP. Risk-reduction measures can make certain exploitation techniques more difficult, but they do not replace the security fixes.

Protections deployed as an emergency measure can reduce exposure during a transition period, but they should not lead administrators to consider a vulnerable version permanently secure.

PHP versions that need to be updated

For branches that are still maintained, the patched versions are PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 and PHP 8.5.12. Administrators using these branches should upgrade to at least the corresponding patched version or a later version containing the same fixes.

Older installations require particular attention. PHP 8.1 and earlier branches are no longer covered by the PHP project's standard support lifecycle. Some Linux distributions and long-term support providers may nevertheless maintain their own packages and backport security fixes.

In such cases, the displayed version number alone is not always enough to determine whether the system is protected. A distribution may retain an older PHP version while applying the necessary security fixes separately. Administrators should therefore check the security advisories and package status provided by the vendor that actually maintains the installation.

For environments that compile older branches themselves, the PHP team has also published minimal patches for PHP 7.4, 8.0 and 8.1. These patches address PHP2Shell, but they do not restore general support for those versions: other unpatched vulnerabilities may still be present.

Disabling session.upload_progress can reduce the attack surface

A significant proportion of the currently documented exploitation techniques use PHP's session.upload_progress feature. This feature normally tracks the progress of a file upload and makes that information available to the application while the upload is in progress.

When this feature is not required, disabling it can remove one of the paths used by known exploitation techniques. Several security recommendations therefore suggest this measure as temporary protection for environments that cannot be updated immediately.

It is not, however, a fix for PHP2Shell. The vulnerabilities exist within PHP itself, and other exploitation paths may exist or be discovered. A configuration change should therefore be treated as a risk-reduction measure, not as a permanent solution.

Web application firewalls can block attacks, not remove the vulnerability

Security service providers and Web application firewall vendors quickly deployed rules designed to identify requests associated with the first PHP2Shell exploitation techniques. These protections can prevent a significant proportion of known attempts from reaching the vulnerable PHP server.

They nevertheless depend on the ability to recognize the behavior of an attack. The payloads observed since disclosure have already evolved, with some actors modifying their requests in an attempt to bypass signatures and filtering rules deployed as emergency measures.

A Web application firewall therefore provides an additional layer of defense, particularly when an immediate update is not possible, but it does not modify the vulnerable code present on the server. The system remains technically affected until the PHP security fix has been applied.

A system that cannot be patched should be isolated

When an update cannot be applied immediately, reducing exposure becomes the priority. A vulnerable service that does not need to be directly accessible from the Internet should not remain exposed while the necessary security measures are being implemented.

Cybersecurity authorities recommend isolating or temporarily removing unpatched systems from exposure. In the most sensitive environments, this may mean temporarily taking the affected service offline until sufficient mitigation measures have been implemented.

This approach can be disruptive for a production service, but it avoids deliberately keeping an installation accessible when unauthenticated remote code execution is publicly documented and actively being targeted.

Updating does not always close the incident

The existence of exploitation attempts before public disclosure also changes how the incident should be handled. Installing the patch prevents future exploitation of the corrected vulnerabilities, but it cannot determine whether the server had already been compromised beforehand.

Systems that were exposed before being updated may therefore require an investigation for signs of exploitation: unusual processes launched by PHP, abnormal network connections, recently created or modified files, unexpected downloads and other behavior that does not match the application's normal operation.

This investigation is particularly important for systems that were accessible from the Internet before October 21. Amazon's observations show that activity related to PHP2Shell existed at least four days before the public disclosure.

Have the fixes already been bypassed?

The rapid publication of proofs of concept and new research has led to claims that the patched versions themselves may be bypassed. It is important here to distinguish between a new exploitation path, a particular configuration and an actual bypass of the fixes applied to the two original vulnerabilities.

A technique that achieves code execution on a recent version of PHP does not automatically demonstrate that CVE-2026-109618 or CVE-2026-109619 remain exploitable after being patched. It may involve another vulnerability, application-specific behavior or a configuration that introduces a separate risk.

As of October 24, 2026, the available evidence does not establish any widespread bypass of the official PHP2Shell fixes. CVE-2026-115560, disclosed on October 23, is a separate vulnerability and does not demonstrate that CVE-2026-109618 or CVE-2026-109619 remain exploitable after being patched.

Timeline and evolving situation

October 17, 2026 currently marks the earliest known point in the timeline: Amazon Threat Intelligence retrospectively identified an attempt targeting PHP2Shell in its MadPot honeypot network, four days before the vulnerabilities were publicly disclosed.

October 20: PHP announces an exceptional security update

On October 20, the PHP security team issued an advance warning. It announced a security update for the following day to address two critical vulnerabilities, both rated 9.2 out of 10 under CVSS v4.0.

At that point, the technical details had not yet been made public. PHP nevertheless urged all users to prepare to update their installations as soon as the fixes became available. The team also stated that it reserved the right to bring the release forward if details of the vulnerabilities became public or active exploitation was detected.

October 21: fixes, disclosure and a surge in exploitation attempts

During the early hours of October 21, before the scheduled time for full disclosure, activity was already increasing. Amazon detected several proofs of concept and additional attempts from around 02:00 UTC, originating from different anonymized infrastructures and using distinct payloads.

F5 also observed reconnaissance activity related to PHP2Shell before the official disclosure. Several actors appeared to be looking for servers with the characteristics required for exploitation.

The PHP project then released fixes for CVE-2026-109618 and CVE-2026-109619, along with new versions addressing both vulnerabilities.

Both vulnerabilities were confirmed as capable of allowing unauthenticated remote code execution. Their CVSS v4.0 score of 9.2 places them in the critical severity category.

In the hours following publication, new proofs of concept became available and began appearing almost immediately across detection infrastructures. Amazon now describes exploitation as being widely attempted in the wild.

October 21 and 22: protections are deployed as attacks evolve

Security service providers responded alongside the release of the fixes. Cloudflare says it prepared and activated protections against PHP2Shell before public disclosure in order to filter some requests matching known exploitation paths.

AWS also deployed specific rules in its Web application firewall. These protections were subsequently adjusted as new techniques and new forms of malicious requests were identified.

This period illustrates the race that now follows the disclosure of a critical vulnerability: administrators update their servers, security providers adapt their protections and attackers simultaneously modify their payloads to search for new targets or bypass filtering mechanisms.

The activity detected as early as October 17 also led Amazon to recommend that investigations should not be limited to the day of disclosure. For PHP2Shell, searches for suspicious activity should extend back at least to that date.

October 23: a third PHP vulnerability emerges

On October 23, another vulnerability capable of enabling remote code execution was publicly disclosed as CVE-2026-115560.

This flaw must be distinguished from CVE-2026-109618 and CVE-2026-109619, which make up PHP2Shell. It affects a more unusual configuration, and PHP considers its risk to be significantly more limited.

It nevertheless introduces an additional concern: the versions released on October 21 to fix PHP2Shell do not address CVE-2026-115560. Pending the fix expected in a future regular release, the specific recommendation is to disable session.upload_progress in environments where this new vulnerability may apply.

The emergence of this third vulnerability therefore does not mean that the PHP2Shell fixes have been bypassed. It shows that a separate vulnerability was identified amid the same period of intensive research into PHP's request-processing mechanisms.

October 24: an active threat, but an impact that remains difficult to measure

As of October 24, 2026, PHP2Shell is generating significant reconnaissance and exploitation activity across the Internet. Proofs of concept are public, while the fixes and several complementary protections have now been deployed.

The actual scale of successful compromises remains difficult to establish. The millions of observed requests, scans and probes do not represent the number of servers actually compromised, and there is currently no evidence supporting the conclusion that the PHP ecosystem has been compromised on a widespread scale.

October 26: CISA confirms active exploitation of both vulnerabilities

On October 26, 2026, CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) Catalog, which tracks vulnerabilities for which evidence of exploitation in the wild has been established.

This listing marks a significant change in the status of PHP2Shell. Until now, public observations had primarily documented scanning activity, millions of exploitation attempts, and activity dating back to at least October 17. Actual exploitation of the vulnerabilities in the wild is now officially recognized.

This does not, however, demonstrate a widespread compromise of the PHP ecosystem. Active exploitation is now established, but the number of systems actually compromised and the true scale of the incident remain unknown.

What we are monitoring now

The main developments to watch now are the true scale of the compromises, the identification of victims whose initial access can be attributed to PHP2Shell with sufficient confidence, the evolution of malicious payloads deployed after exploitation, and the potential discovery of a genuine bypass of the patches for CVE-2026-109618 or CVE-2026-109619.

Investigations into the period before public disclosure also remain important. Additional compromises or exploitation attempts predating October 21 may emerge as organizations continue to review their logs and telemetry data.

This report will be updated when these developments materially change the state of the situation, rather than for every new attempt or proof of concept that appears.

Going further: data and monitoring

The incidents examined in this report are part of a broader cybersecurity environment in which some indicators can change rapidly, including newly exploited vulnerabilities, observed malicious activity and changes in overall exposure.

These data are monitored separately to distinguish the events examined in this report from broader trends that can be observed over time.

The Cyber Radar complements this analysis by regularly tracking several indicators based on public data.

Explore the Cyber Radar →

Follow developments more closely

To follow important developments more directly, you can also find L'Actu sans le Bruit on Telegram. The channel follows new events as they unfold, while this report is updated only when those developments materially change the situation.

The channel is published in French, but Telegram's translation feature can be used to translate posts into English.

Follow L'Actu sans le Bruit on Telegram