PHP2Shell: What Organizations Need to Know About Two Critical PHP RCE Flaws

Two critical vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619, create a serious exposure for organizations operating internet-facing PHP applications. The flaws, collectively referred to as PHP2Shell, can allow an unauthenticated attacker with network access to a vulnerable PHP application to execute arbitrary code in the security context of the PHP process.

Securelist, the research publication of Kaspersky, describes the vulnerabilities as affecting PHP versions across branches 5, 6, 7, and 8. Both were rated 9.2 on the CVSS scale in the material reviewed by Securelist. The PHP security team released fixes on October 21, 2026, after details were publicly disclosed ahead of the planned disclosure schedule.

The immediate risk is greatest for public-facing servers running unsupported or unpatched PHP versions. However, the presence of a vulnerable PHP interpreter does not by itself demonstrate compromise. Organizations must distinguish between exposure, exploitation attempts, and confirmed post-exploitation activity while moving quickly to identify and remediate affected systems.

What the vulnerabilities affect

According to Securelist, the flaws involve PHP’s handling of multipart/form-data requests together with the session.upload_progress mechanism. The researcher who published the proof of concept associated the issues with use-after-free and memory-corruption conditions. PHP’s security advisories subsequently confirmed the core vulnerability information.

These are interpreter-level defects rather than issues that can be corrected solely in WordPress, Joomla, Drupal, Magento, MediaWiki, phpBB, Laravel, Symfony, or another application built with PHP. Securelist therefore emphasizes that updating the PHP runtime is the essential remediation. Application-level changes may reduce exposure in the short term, but they do not repair the underlying memory-safety flaws.

The reported attack model is significant: authentication is not required. An attacker needs network access to a PHP application, and successful exploitation results in code execution on behalf of the PHP process. The supplied research does not establish that every PHP deployment is equally exploitable, nor does it confirm compromise of any named victim. Configuration, application architecture, web-server behavior, and the presence of relevant PHP functionality remain important factors for individual risk assessment.

What is known about PHP2Shell

PHP2Shell is the unofficial name used for the exploit associated with the vulnerabilities. Securelist reports that a demonstration appeared online and showed exploitation against servers running several widely used web platforms, including WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal, and WHMCS.

That demonstration should be interpreted carefully. At the time of Securelist’s publication, its authenticity and exact behavior had not been independently verified. The existence of public exploit material nonetheless increases operational pressure because it gives defenders less time to rely on obscurity or delayed patching. Securelist also cites an external estimate that widespread exploitation could begin within 15 minutes of the update release. This is an assessment from the cited researchers, not a confirmed measurement of exploitation activity.

The source material does not provide a confirmed victim list, campaign attribution, malware family, command-and-control domain, IP address, or email indicator. It also does not establish that a single threat actor is responsible for PHP2Shell activity. Administrators should avoid treating exploit references or generic post-exploitation behavior as proof of a particular actor or campaign.

Likely attack sequence and post-exploitation risk

The supported attack sequence begins with an unauthenticated request sent over the network to a vulnerable PHP application. The request abuses the interaction between multipart form processing and session upload progress, triggering the underlying memory-safety flaw. If exploitation succeeds, code runs in the context of the web server’s PHP process.

From there, the consequences depend on the permissions granted to that process and the system’s local controls. Securelist’s detection guidance identifies several behaviors associated with potential exploitation or follow-on activity:

• Suspicious processes created by a web-server process.
• Shell or interpreter execution originating from PHP or another web-server component.
• Creation of executable files or scripts in a web application directory.
• Creation of files with uncommon extensions in web-accessible locations.
• Reconnaissance commands executed under the web-server account.
• Commands associated with persistence.
• Delivery or launch of web shells.

These behaviors describe detection opportunities rather than a confirmed sequence in every PHP2Shell incident. A web shell, for example, may be one possible post-exploitation outcome, but the supplied research does not say that every exploit attempt deploys one. Similarly, file creation inside a web directory can be legitimate during application updates, so context and change-management records are essential.

On Linux and Windows systems, the permissions of the PHP process are especially important. Excessive write access to application directories can make it easier for an attacker who gains code execution to place scripts or other executable content where the web server can later invoke it. Separating application files from writable upload locations and limiting service-account privileges can reduce the impact of a successful exploit, although these measures do not replace patching.

Detection opportunities identified by Kaspersky

Securelist says Kaspersky Endpoint Detection and Response can alert on suspicious activity in the context of a web server. The named detection rules include creating_windows_shell_from_a_web_servers_process, possible_web_shell_creating_via_exploit, spawning_process_from_webserver_more_filters_linux, webserver_interpreter_execution_linux, and executable_file_in_www_folder.

Kaspersky Anti Targeted Attack is described as detecting exploit activity in network traffic with verdicts for CVE-2026-109618 and CVE-2026-109619. Kaspersky Endpoint Security, now available as Kaspersky Next according to the report, can also identify malicious post-exploitation behavior through its behavior-detection component. Securelist lists the generic verdicts PDM:Exploit.Linux.Generic and PDM:Exploit.Win32.Generic.

Kaspersky’s Managed Detection and Response service is said to monitor for the behavioral indicators listed above, including suspicious process generation, executable or script creation in web directories, reconnaissance and persistence commands, and web-shell activity. Kaspersky SIEM users are provided rules for suspicious shell execution by web applications and possible web-shell behavior on Linux systems.

Organizations without these products can still apply the underlying logic to their own telemetry. Prioritize parent-child process relationships, file-write events, web-server account activity, and command execution from PHP-related processes. Securelist specifically recommends monitoring executable and script creation when developing custom rules or conducting threat hunting. Relevant extensions in the report include PHP, ASP, ASPX, JSP, JavaScript, shell scripts, PowerShell, batch files, and other executable formats.

Detection should cover both Linux and Windows estates. On Linux, useful evidence includes web-server process trees, file creation events, and system-call or audit telemetry where available. On Windows, administrators should review process creation and file-write events involving PHP, IIS, or other web-server components. Alerts should be enriched with the application path, service account, request timing, deployment history, and whether the file was subsequently executed.

What organizations should do now

1. Inventory PHP exposure. Identify every PHP runtime, including those embedded in web servers, hosting panels, third-party appliances, development environments, and managed services. Record the PHP branch, patch level, internet exposure, application owner, and service account.
2. Patch the interpreter urgently. Apply the PHP security updates released for the affected branches. Securelist reports that backported fixes were made available for PHP 7.4, 8.0, and 8.1, while older branches remain outside normal support. Where possible, migrate systems running PHP 8.1 or earlier to a supported current branch rather than relying indefinitely on legacy fixes.
3. Use temporary exposure reduction if patching is delayed. Securelist recommends disabling upload progress with session.upload_progress.enabled = Off through PHP-FPM administration settings, blocking multipart requests at nginx or Apache, and considering temporary isolation of internet-connected PHP applications. These controls can affect legitimate application behavior and should be tested, documented, and treated as interim measures.
4. Review service-account permissions. Confirm that PHP and web-server accounts cannot write broadly across application code, system directories, or other tenants. Separate writable upload areas from executable web content wherever the application permits.
5. Hunt for post-exploitation indicators. Review recent process launches from PHP, nginx, Apache, IIS, or related web-server processes. Search for new scripts, executables, unusual extensions, web shells, unexpected scheduled or startup persistence, and reconnaissance commands executed by web-service accounts.
6. Validate changes and investigate anomalies. Compare suspicious files and processes against approved deployments. Preserve relevant web-server, PHP, endpoint, file, and authentication logs before cleaning systems. If compromise is confirmed, isolate the host and follow the organization’s incident-response process.
7. Confirm coverage. Use vulnerability-management scanning to locate vulnerable PHP versions and verify that endpoint, network, SIEM, and MDR controls are receiving the telemetry needed to detect exploitation and follow-on behavior.

What remains unknown

The supplied research does not provide reliable indicators of compromise such as domains, IP addresses, payload hashes, or fixed exploit strings. It does not name a threat actor, identify confirmed victims, or establish a particular malware family associated with PHP2Shell. The public demonstration’s authenticity and exact behavior were also still unverified at the time of publication.

Those gaps make behavior-based monitoring and asset management more important. Defenders should not wait for a stable IOC set before patching or reviewing web-server activity.

Conclusion

PHP2Shell represents a high-priority PHP maintenance and exposure-management problem because the vulnerabilities are critical, remotely reachable under the reported conditions, and usable without authentication. The most reliable defense is to update PHP, retire unsupported versions, and reduce internet exposure while remediation is underway. Detection should focus on the transition from web request handling to shell or interpreter execution, suspicious file creation, reconnaissance, persistence, and web-shell activity. These signals can help organizations identify attempted exploitation or compromise even when no public infrastructure indicators are available.

Sources

Securelist: Critical RCE vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619)