php2shell: Two Critical PHP Vulnerabilities (CVSS 9.2): What Hosting Providers Need to Know

SECURITY ADVISORY • PHP RUNTIME

Critical vulnerability alert

php2shell: Two Critical PHP Vulnerabilities (CVSS 9.2): What Hosting Providers Need to Know

Two critical PHP vulnerabilities, publicly referred to as php2shell, have prompted an emergency security release scheduled for October 21, 2026. Hosting providers and Linux server administrators should assess exposure, apply temporary mitigations, and prepare to patch all affected PHP runtimes.

Published: October 21, 2026. Information status: Pre-release advisory; verify details against the latest official PHP security announcements.

php2shell: Key Facts at a Glance

• Vulnerability name: php2shell (name used in public research).

• Severity: Critical; two vulnerabilities reported with CVSS v4.0 scores of 9.2.

• CVE identifiers: CVE-2026-109618 and CVE-2026-109619, as reported publicly; verify against official advisories.

• Potential impact: Remote code execution (RCE).

• Suspected attack surface: PHP session upload-progress handling, according to preliminary research.

• Affected versions: Not yet officially confirmed at the time of this pre-release update.

• Emergency release: October 21, 2026, 14:00 UTC (16:00 CEST), as scheduled.

• Known exploitation: No confirmed in-the-wild exploitation in the reports available for this update.

Important: PHP's confirmation of two critical vulnerabilities should be distinguished from researchers' preliminary claims about the root cause, affected versions, and exploit reliability. This article will need updating when the official advisories and patched releases are available.

What Is php2shell?

php2shell is the name used in security reporting for two critical vulnerabilities in PHP. Because PHP powers many websites and hosting platforms, vulnerabilities in the PHP runtime can affect infrastructure independently of the applications deployed on top of it.

Potentially exposed environments include:

• Shared hosting platforms serving large numbers of PHP websites

• VPS and dedicated servers running PHP-FPM or Apache mod_php

• WordPress, Drupal, Joomla, and Magento hosting environments

• cPanel, Plesk, and DirectAdmin installations with multiple PHP versions

• LiteSpeed PHP, CloudLinux, and containerized PHP deployments

The concern is possible remote code execution (RCE) , which could allow an attacker to run unauthorized code with the privileges of the affected PHP process. The precise prerequisites and impact must be checked against the official technical advisories.

How Does the php2shell Attack Work?

According to preliminary researcher findings, at least one issue may involve a memory-handling flaw in PHP's session upload-progress functionality. Researchers describe a crafted multipart HTTP POST request that contains the PHP_SESSION_UPLOAD_PROGRESS form field and a session identifier.

PHP can process upload-progress information before the requested application script executes. If the research is confirmed, this would make application-level defenses insufficient on their own: an application may encounter the vulnerable PHP behavior even when it does not explicitly implement session handling.

Why This Matters for Hosting Providers

Updating WordPress plugins or validating application input does not patch a vulnerability in the underlying PHP interpreter. Hosting providers need to evaluate the PHP runtime, its configuration, the HTTP request path, and available server-level security controls.

Research status: The complete root cause and whether the same mitigation addresses both reported vulnerabilities remain unconfirmed in this pre-release summary.

Which PHP Versions Are Affected?

At the time of this update, the official affected-version matrix had not been published. Independent researchers have suggested that the suspected upload-progress issue could extend back to PHP 5.4, but that is not an officially confirmed version range for both vulnerabilities.

Administrators should inventory every deployed PHP runtime, including PHP selectors, alternative PHP packages, LiteSpeed PHP, PHP-FPM pools, and containers. Unsupported PHP branches may not receive upstream security fixes, so their upgrade or vendor-support status requires particular attention.

Do not assume a newer PHP branch is unaffected or that an older branch will receive a patch. Use the official PHP advisory and your operating-system or hosting-vendor guidance to determine exposure.

How to Mitigate php2shell Before Patches Are Available

The following measures are intended to reduce risk while official security updates are pending. They are not a confirmed complete fix for both vulnerabilities.

1. Disable PHP Session Upload Progress Where It Is Not Needed

For the suspected upload-progress attack path, researchers recommend disabling the built-in PHP session upload-progress feature in the server-level PHP configuration:

  
    session.upload_progress.enabled = Off
  

Apply the directive to the web-facing PHP runtime, such as PHP-FPM, Apache mod_php, or LiteSpeed PHP, then reload or restart the appropriate service and verify the effective configuration.

• The setting cannot be changed for this purpose with application-level ini_set() .

• Disabling it affects PHP's built-in session upload-progress tracking; test custom applications that depend on it.

• Standard WordPress functionality does not depend on this specific built-in progress feature.

• This measure may address only one of the two vulnerabilities.

2. Add Targeted Web Application Firewall Protection

A WAF may help filter multipart requests containing the PHP_SESSION_UPLOAD_PROGRESS field. Inspect parsed form parameters, not just raw request strings, and validate request-body handling and rule placement.

• Identify multipart/form-data requests targeting PHP endpoints.

• Inspect form parameters for the upload-progress field.

• Test targeted blocking or monitoring against legitimate upload workflows.

• Review WAF events for repeated attempts and suspicious sources.

Prefer narrowly scoped controls over blocking all multipart requests. A targeted WAF rule is a defense-in-depth measure, not a substitute for an official patch. Production ModSecurity rules should be reviewed and tested by the security team before deployment.

3. Monitor Suspicious PHP and Web Server Processes

Unexpected child processes can be signs of attempted or successful exploitation. Investigate activity such as:

• php-fpm or Apache spawning sh or bash

• Web-facing processes invoking curl or wget

• Unexpected execution of nc or other networking tools

• New suspicious scripts, web shells, or executables in website directories

These behaviors are investigation signals rather than definitive proof of php2shell exploitation. Correlate process activity with HTTP requests, file changes, and other server telemetry.

4. Patch Every PHP Runtime as Soon as Updates Are Available

Prepare to deploy the emergency PHP security updates and any corresponding vendor packages. Include:

• System PHP packages and PHP-FPM pools

• Hosting PHP selectors and alternative PHP installations

• LiteSpeed PHP installations

• CloudLinux and CageFS environments, where applicable

• Container images and application-specific runtimes

• Vendor-managed PHP packages

Verify the PHP version actually serving each website after patching. Updating the default command-line PHP executable does not guarantee that all web-facing PHP runtimes have been updated.

Why php2shell Is Especially Concerning for Shared Hosting

Shared hosting providers often manage thousands of websites with different PHP versions and configurations. A runtime-level vulnerability can therefore require coordinated action across a much larger infrastructure than a single application vulnerability.

• Large attack surface: Multiple sites may depend on the same PHP runtime.

• Legacy software: Customers may still rely on unsupported PHP branches.

• Configuration differences: PHP-FPM, LiteSpeed, and alternative PHP builds can require different remediation steps.

• Operational complexity: Providers must coordinate configuration changes and patch deployment across server fleets.

• Detection gaps: Suspicious PHP child processes may go unnoticed without server-level visibility.

This is why PHP security incidents require both rapid patch management and layered server protection.

How BitNinja Supports Layered PHP Server Security

At BitNinja , we focus on protecting Linux hosting infrastructure through multiple complementary security layers. During critical vulnerability disclosures, these controls can support risk reduction, detection, and investigation while administrators deploy the required software updates.

BITNINJA SECURITY UPDATE IN DEVELOPMENT

BitNinja Is Actively Developing WAF Protection Against php2shell

Our security team is already working on dedicated WAF detection and mitigation rules targeting the attack patterns associated with php2shell.

We are prioritizing the development and validation of these protections to help hosting providers reduce exposure to potential exploitation attempts.

Dedicated php2shell WAF protection is coming soon. We'll share further updates as soon as the new rules are validated and ready for deployment.

In the meantime, we strongly recommend applying the official PHP security patches and following the mitigation steps outlined above. A WAF adds another layer of defense, but does not replace patching.

Discover BitNinja server protection →

Web Application Firewall

BitNinja's WAF helps defend web applications against malicious HTTP requests. Where appropriate, validated detection rules can provide additional protection against known request patterns associated with a vulnerability.

Malware Detection

Attackers who gain access to a server may deploy malicious PHP scripts, web shells, or other payloads. Malware detection helps administrators identify suspicious files and investigate compromises.

IP Reputation and Shared Defense Intelligence

IP reputation and shared threat intelligence can help identify known malicious sources and complement vulnerability-specific controls during scanning or exploitation campaigns.

Centralized Security Visibility

For hosting providers operating multiple servers, centralized security information can simplify monitoring and investigation across their infrastructure.

Protection status: BitNinja-specific php2shell WAF rules are in development and are not yet announced as deployed. The existing capabilities described above complement, but do not replace, official PHP security updates.

Explore BitNinja's Linux server security platform .

Key Takeaways for Hosting Providers

• Two critical PHP vulnerabilities have been reported with CVSS v4.0 scores of 9.2.

• Researchers suspect that PHP session upload-progress handling is involved in at least one issue.

• Application updates alone cannot resolve a vulnerability in the PHP runtime.

• Disabling session upload progress and applying targeted WAF filtering may reduce exposure, but are not confirmed complete fixes.

• Monitor suspicious child processes and unexpected files on PHP hosting servers.

• Deploy official PHP security updates across all relevant runtimes and verify the effective versions.

• Use layered security controls to complement, not replace, patch management.

Frequently Asked Questions About php2shell

What is php2shell?

php2shell is the name used in public security reporting for two critical PHP vulnerabilities disclosed in October 2026. The reported severity is CVSS v4.0 9.2 for both issues.

What are CVE-2026-109618 and CVE-2026-109619?

These are the identifiers associated with the two issues in public reporting. Consult official PHP and CVE records for authoritative technical details and affected versions.

Is WordPress affected by php2shell?

WordPress sites may be exposed if their underlying PHP runtime is vulnerable. This is a PHP runtime concern rather than a confirmed WordPress core vulnerability.

Can php2shell be exploited without authentication?

Preliminary research describes crafted HTTP requests that may reach vulnerable PHP processing without application-level authentication. The exact prerequisites should be confirmed against the official advisories.

Does disabling session.upload_progress.enabled fix php2shell?

It may mitigate the suspected upload-progress attack path, but it is not established as a complete fix for both reported vulnerabilities. Apply official security updates.

Can a WAF protect against php2shell?

A properly configured WAF may block known malicious request patterns, but coverage depends on the rule and inspection behavior. WAF protection should supplement PHP patching.

Has php2shell been exploited in the wild?

No confirmed in-the-wild exploitation had been reported in the sources used for this pre-release update. Continue monitoring official advisories and server telemetry.

When are the PHP security patches scheduled?

The emergency PHP release was scheduled for October 21, 2026, at 14:00 UTC (16:00 CEST). Check the official PHP website for the current release and patch status.

Final Thoughts: Prepare, Mitigate, and Patch

Critical PHP runtime vulnerabilities demand an infrastructure-wide response. Identify exposed PHP installations, apply carefully tested temporary controls, monitor for suspicious activity, and prioritize official patches as soon as they are available.

BitNinja helps hosting providers strengthen their Linux server security with layered protection, visibility, and malware defense. Learn more about BitNinja .