PHP2Shell refers to recently disclosed vulnerabilities in the PHP core, tracked as CVE-2026-109618 and CVE-2026-109619. In environments that meet the exploitation conditions, unauthenticated attackers may be able to execute code on a server through network requests. PHP released security updates on October 21, 2026. Both vulnerabilities have a CVSS v4.0 score of 9.2 and pose a critical risk. Organizations should immediately identify the PHP installations actually serving their websites, apply the updates, and disable Session Upload Progress tracking if it is not needed. [1]

RayAegis’s AI system has also recorded requests that triggered PHP2Shell protection rules. This article explains where the vulnerabilities occur, their potential impact, and the response measures organizations should take, from updating PHP and configuring sessions to investigating a possible compromise.

The Relationship Between PHP2Shell and PHP Webshells

A PHP webshell is a backdoor program that attackers place on a web server. Typically written in PHP, it allows them to manipulate files, read configuration data, or execute commands over HTTP, subject to the permissions available. It may be hidden in an upload directory, plugin, or theme, or inserted into an existing application file. Attackers may implant it through file upload functionality, a vulnerable website plugin, stolen credentials, or a server-side remote code execution vulnerability.

PHP2Shell, by contrast, is the collective name for these PHP core vulnerabilities. Implanting a webshell is one possible follow-up action after successful exploitation, but an attacker may also execute code only in memory or steal data directly. The absence of suspicious .php files is therefore insufficient to rule out prior exploitation.

Where the Vulnerabilities Occur in PHP

CVE-2026-109618 Memory Corruption During Out-of-Memory Handling

This vulnerability occurs in PHP’s error recovery and request shutdown procedures when an out-of-memory (OOM) condition arises. If some internal data has not been fully initialized, a memory allocation failure may interrupt processing. Subsequent cleanup may then treat the incomplete data as valid state, resulting in memory corruption and potentially remote code execution. [2]

In the demonstrated scenario involving Apache mod_php, the issue can occur while parsing an HTTP request, before the website’s application code runs. Application-level authentication checks and input validation may therefore have no opportunity to intervene. PHP-FPM handles these conditions differently, and its application-specific paths must still be assessed against the official advisory. [2]

CVE-2026-109619 Use-After-Free Caused by State Retained Across Requests

A PHP worker typically handles multiple requests in succession. If memory belonging to a previous request has been freed but internal global state still points to it, the next request may access that invalid data before normal initialization, creating a use-after-free condition. The official advisory confirms exploitation paths involving the Session Upload Progress lifecycle. The precise conditions depend on PHP’s execution mode, configuration, and application flow. [3]

The entry point may be an ordinary PHP page, such as /index.php, rather than only a visible file upload form. Native Session Upload Progress tracking is enabled by default. The fact that a website does not explicitly call session_start() does not mean this processing path is absent. [3][4]

Which Systems Need Immediate Review

PHP’s official guidance calls for an inventory of all PHP installations serving web requests, including Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. Organizations using WordPress, Drupal, Joomla, custom PHP websites, or internal administration platforms should check the underlying runtime. Updating only the CMS or its plugins does not fix vulnerabilities in the PHP core itself. [1]

PHP Branch	Patched Version for These Two Vulnerabilities
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

These are the first releases in each branch to include fixes for the two vulnerabilities. In practice, organizations should use a currently supported stable release in the appropriate branch that includes the fixes. PHP 8.1 and older branches no longer receive routine upstream security maintenance. Organizations using Linux distribution or LTS packages should verify whether their vendor has backported the fixes, rather than judging solely by the displayed version number. [1]

Why Organizations Must Prioritize Remediation

Remote code execution allows an attacker to go beyond the website’s intended functionality and operate on the system with the PHP worker account’s privileges. If that account can read database passwords, API keys, or other service credentials, the impact may extend to member records, orders, internal integrations, and other systems. If it can write to website directories, an attacker may also implant backdoors, modify pages, or insert phishing content.

The initial execution privileges are usually those of the web service account; they do not automatically grant root or administrator access. The actual damage depends on file permissions, network connectivity, credential protection, and host isolation. A website that still displays normally may nevertheless have been compromised, because backdoors and data theft may not affect the home page.

A Protection Event Detected by RayAegis

RayAegis’s protection system recorded a POST request to /index.php with a multipart/form-data body containing the PHP_SESSION_UPLOAD_PROGRESS field. The field triggered PHP2Shell protection. The event was marked Prevention / Blocked, and the response was HTTP 403.

Figure 1. A PHP2Shell protection event recorded by RayAegis’s AI system.

This record shows that the attack request was rejected by the protection system and that related attacks occurred shortly after the vulnerabilities were disclosed.

Patching and Mitigation Measures for Organizations

Update the PHP Runtime Actually Serving the Website

First identify the PHP version and package source actually used by each website, FPM pool, container, and backend node, then apply updates according to the official PHP or distribution security advisories. After updating, restart the relevant Apache or PHP-FPM service so that all old workers exit. Test login, forms, file uploads, and transaction workflows. Updating only the command-line PHP installation, or checking only php -v, may overlook a different version still serving the website.

Immediately Disable Session Upload Progress Tracking if It Is Not Needed

Add the following setting to php.ini, an FPM pool, or server configuration that takes effect before request parsing, then restart all relevant PHP workers. [1][3]

session.upload_progress.enabled = Off

For common PHP 8.3 deployments on Ubuntu or Debian, check the configuration locations below. Adjust them to match the actual installation when using other versions, containers, or managed hosting.

Deployment	Typical php.ini Path
Apache mod_php	/etc/php/8.3/apache2/php.ini
PHP-FPM	/etc/php/8.3/fpm/php.ini

For Apache mod_php, check the Apache configuration after making the change, then restart the service:

sudo apache2ctl configtest && sudo systemctl restart apache2

For PHP-FPM, check the configuration for the corresponding version, then restart FPM. The executable path and service name may vary with the installation:

sudo /usr/sbin/php-fpm8.3 -t && sudo systemctl restart php8.3-fpm

This setting disables PHP’s native upload progress tracking. Ordinary file uploads and session functionality remain available, but any progress display that depends on this feature should be tested. For this risk, which arises during early request processing, do not rely on ini_set() in application code or on FPM’s .user.ini files, because they may take effect too late. [1][3]

On October 23, 2026, PHP issued an additional notice concerning CVE-2026-115560. An unusual combination of session serialization settings and a runtime change of the serialization handler can create an additional risk. PHP recommends keeping session.upload_progress.enabled=0 until a subsequent regular bugfix release. Even after installing the versions that fix the original two vulnerabilities, organizations should therefore verify this setting and follow subsequent advisories. [1]

Consider Disabling the Entire Session Module if Native Sessions Are Not Needed

If neither the application nor its plugins depend on native PHP sessions, organizations can consider disabling the entire Session module to remove the associated functionality and attack surface. Before doing so, check dependencies in login state management, shopping carts, CAPTCHAs, form workflows, and third-party packages, as disabling the module may disrupt these functions.

The method for fully disabling the module depends on how PHP was built. If Session is provided as a dynamically loadable shared extension, disable its loading according to the package vendor’s documentation. If it is compiled into PHP, removing an extension directive will not disable it; a build without Session support is required. PHP documents the following compile-time option: [5]

–disable-session

This is a configure option used when rebuilding PHP. It must be planned together with the existing build options and is not a directive to paste into php.ini. There is no universal session.enabled=Off switch. Setting session.auto_start=Off, disabling the session_start function, or simply not calling session_start() in application code does not remove the module. [4][5]

PHP must still be updated after disabling the entire Session module, because PHP2Shell also involves other core processing paths. If an immediate update is not possible, restrict external access and, where necessary, temporarily suspend the affected service. Session configuration alone cannot fully remediate both vulnerabilities. [1][3]

Deploy Compensating WAF Controls and Verify Normal Business Workflows

During remediation, a WAF can restrict upload progress fields that are not needed and enforce reasonable limits on multipart requests, decoded request sizes, field counts, and nesting depth. If a system forwards content that exceeds its inspection limits without further inspection, a detection gap may remain. Configure rejection or restriction policies according to business requirements.

Test the rules against legitimate login, form submission, and upload workflows. Blocking the PHP_SESSION_UPLOAD_PROGRESS field alone can serve as a compensating control where the feature is not used, but it must not be presented as covering every PHP2Shell exploitation path. Continue monitoring alerts, unusual errors, and emerging attack variants after patching.

Verify That Settings Have Taken Effect in the Web Runtime

Verification must cover the PHP runtime actually used by each website and backend node, rather than only the CLI. A temporary diagnostic page restricted to administrators can be used to check PHP_VERSION, PHP_SAPI, php_ini_loaded_file(), and
ini_get(“session.upload_progress.enabled”). If the entire module has been disabled, also confirm that extension_loaded(“session”) returns false. Remove the diagnostic page afterward to avoid exposing environment information.

Investigation and Recovery When Exploitation Is Suspected

If a system was exposed to the internet while unpatched, or suspicious processes, files, or outbound connections are found, initiate an intrusion investigation. Patching can prevent further exploitation of the vulnerabilities, but it does not automatically remove backdoors already implanted. We recommend the following sequence:

• Restrict the affected host’s outbound and lateral connections. Preserve WAF, reverse proxy, Apache / Nginx, PHP-FPM, system, and cloud audit logs, and build a timeline that covers the period before patching. Where feasible, preserve disk snapshots and necessary volatile evidence.
• Compare website core files, plugins, themes, and deployment files against trusted sources. Check upload, temporary, and session storage directories, as well as .user.ini, .htaccess, scheduled tasks, services, and newly created accounts. Do not judge whether the system is clean solely by filenames, modification times, or scans for a single string.
• Correlate child processes spawned by PHP workers, unusual outbound connections, database activity, and file writes. OOM events, timeouts, and process crashes can provide investigative leads, but none alone proves successful exploitation. The absence of error logs does not establish safety either.
• If a host is confirmed to be compromised, prioritize rebuilding it from a trusted image and applying the patches. Rotate potentially exposed database passwords, API keys, and other credentials from a clean environment, and revoke relevant authenticated sessions according to the scope of the incident. Restore service after correcting the root cause and completing verification.

Security Recommendations for Organizations

Responding to PHP2Shell requires runtime patching, disabling optional functionality, and host-level investigation. RayAegis recommends first verifying the version actually serving the website, then updating PHP and configuring Session Upload Progress. Correlate WAF events with host evidence to determine whether unusual requests have had any subsequent impact. RayAegis can assist organizations with exposure assessments, protection rule reviews, and incident investigations.

References

Technical information was checked on October 25, 2026. Versions and mitigation recommendations may change as further advisories are published. Before deployment, check the latest information from PHP and your package vendor.

[1] PHP Official Security Advisory and Session Upload Progress Update

[2] CVE-2026-109618 Official Technical Advisory – RCE via OOM corruption

[3] CVE-2026-109619 Official Technical Advisory – RCE via stale global state

[4] PHP Manual – Session Runtime Configuration

[5] PHP Manual – Session Installation