PHP2Shell: How Security Teams Should Assess and Contain the Reported PHP RCEs

The hardest part of a critical infrastructure vulnerability is often finding every place where it is exposed. A company may know which applications use PHP, but not which PHP binaries actually serve those applications, which configuration files they load, or whether a public endpoint accepts request bodies the application never intended to process.

That gap matters with the newly reported PHP2Shell issues, CVE-2026-109618 and CVE-2026-109619. PHP has announced two critical security issues, each scored 9.2 under CVSS v4.0. External research describes an unauthenticated remote-code-execution path in PHP’s multipart upload processing. The PHP project’s detailed advisory and exact affected-version matrix were not yet available when this article was prepared, before its scheduled October 21, 2026, 14:00 UTC security release.

For defenders, the first task is therefore practical: establish where PHP executes, identify configurations that may reach the reported code path, and prepare to replace vulnerable runtimes as soon as vendor fixes are confirmed.

Evidence boundary: PHP has confirmed the severity and release schedule, not the full technical mechanism discussed below. Details about the suspected memory-corruption path come from third-party material, notably JackalSyn. DeXpose has not independently reproduced the reported RCE chain. Treat these observations as preliminary until the vendor’s patched source and advisory can be reviewed.

The exposure is in the runtime, not a particular CMS

It would be a mistake to limit the inventory to WordPress plugins, Laravel controllers, or files named upload.php. PHP itself parses multipart/form-data requests before the target PHP application executes. The runtime includes an optional upload-progress mechanism that can update session state while a file is arriving.

The default setting documented by PHP is:

session.upload_progress.enabled = On

The configured form-field name is normally PHP_SESSION_UPLOAD_PROGRESS. When the relevant multipart request conditions are met, the parser may invoke PHP’s upload-progress handling. The PHP manual explicitly states that this session data is written before application script execution.

This changes how security teams should assess exposure. A route that never intentionally handles files may still be served by a PHP runtime capable of parsing multipart requests. Conversely, the presence of PHP or this default setting alone does not prove that either CVE can be exploited. The actual trigger, session backend, SAPI, build, configuration, and request handling matter.

A request can cross several boundaries before application validation

External client
    |
    v
CDN / WAF / reverse proxy
    |
    v
Apache or Nginx routes the request
    |
    v
PHP SAPI parses request body
    |
    +--> multipart parser
    |       |
    |       +--> session upload-progress callback (if applicable)
    |
    v
PHP application bootstrap
    |
    v
Framework routing and business logic

A WAF rule that only protects a known file-upload page may miss this class of exposure if other routes forward multipart bodies to PHP. Application validation can also occur too late to prevent defects triggered during request parsing.

What the public root-cause report alleges

JackalSyn attributes the reported failures to the session upload-progress callback, php_session_rfc1867_callback(), in PHP’s ext/session/session.c. Its analysis focuses on cached zval * pointers associated with upload-progress bookkeeping, including post_bytes_processed and current_file_bytes_processed.

A use-after-free occurs when code uses a pointer after the object or storage it references has been released. In the reported sequence, session-state updates replace or destroy an earlier decoded array while callback state continues to reference entries from it. Subsequent access to that stale pointer can touch memory that has since been reused.

The external report claims it can turn this memory-lifetime error into control of a PHP function-call structure and ultimately reach zend_call_function(). It describes build-dependent offsets, heap allocation behavior, and separate proof-of-concept chains. These details are technically significant, but they have not yet been confirmed by PHP’s published fixes.

Two points deserve caution. First, a memory-safety flaw does not automatically imply a reliable RCE on every compiled PHP build. Second, the existence of two CVE identifiers does not by itself establish that a single configuration workaround fully addresses both issues.

Build an inventory based on execution, not package names

For most organizations, the initial failure mode is incomplete runtime visibility. A server may contain multiple PHP versions, containers may bundle their own interpreters, and the command-line version may have nothing to do with the web-facing process.

Start by collecting the following for each public application: its hostname, route to the serving infrastructure, PHP version and SAPI, loaded configuration, session settings, owner, and change window. Include partner-operated systems and externally hosted customer portals if they are inside your responsibility boundary.

On a Linux host, these commands help identify installed executables and running services:

# Inventory hints: installed binaries and running PHP workers.
command -v php || true
php -v 2>/dev/null || true
ps -eo pid,comm,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp'

# Debian/Ubuntu package inventory (where dpkg is used).
dpkg-query -W 'php*' 2>/dev/null || true

# RHEL-family package inventory (where rpm is used).
rpm -qa | grep -E '^php([0-9]|-|$)' || true

Do not treat php -v as evidence of the web server’s version. PHP CLI, Apache mod_php, and distinct FPM pools can load different binaries and php.ini files.

For each actual web-serving SAPI, collect its effective configuration through your deployment management or a short-lived, access-restricted diagnostics endpoint. Remove that endpoint immediately afterward. Avoid exposing phpinfo() to the internet, since it can disclose environment and system details.

Relevant settings to record include:

session.upload_progress.enabled
session.upload_progress.name
session.save_handler
session.auto_start
file_uploads
post_max_size
upload_max_filesize

These values are exposure context, not a confirmed vulnerability test.

Containers need a separate pass

An updated host does not fix PHP bundled into an older application image. Enumerate deployed images, inspect their digests and PHP package versions, and plan image rebuilds rather than assuming a host-level package update reaches every service. The same applies to managed hosting: request confirmation of the runtime actually serving traffic, not a generic statement that the platform supports a secure PHP release.

Prioritize externally reachable services

Until PHP publishes its affected-version matrix, use a conservative triage order.

This table is a response order, not a claim that the listed categories are confirmed exploitable. In particular, an unknown version is an inventory problem that should be corrected before it becomes a patching delay.

Temporary controls and their limits

The only dependable long-term remedy is a vendor-confirmed fixed PHP build, deployed to every affected execution environment. Before that is available, security teams can reduce unnecessary entry points.

Disable upload progress where applications do not use it. PHP documents this facility as optional. Apply the setting in the serving PHP configuration, not merely in the CLI configuration:

session.upload_progress.enabled = Off

Reload or restart the appropriate Apache/FPM service according to your deployment setup, then verify the effective value from the web SAPI. A successful configuration reload is not, by itself, proof that all workers use the new setting. Where possible, check both newly started worker processes and application behavior.

Filter multipart bodies on routes that never require them. A proxy or WAF can reject multipart/form-data for specific endpoints after application owners confirm that those routes have no legitimate multipart clients. Avoid blanket rules without testing: multipart requests are used for ordinary workflows, including document uploads and some API integrations. A Content-Type check is an interim restriction, not a proven patch for either CVE.

Reduce direct origin exposure. If an origin should only be reachable through a controlled proxy, enforce that boundary at the network level. Where patching is not feasible and the service is highly exposed, temporary isolation may be warranted. CERT-EU specifically recommends considering isolation of affected internet-facing applications pending a fix.

Do not overstate the workaround. Turning off session.upload_progress may eliminate a suspected trigger path, but the public technical report itself does not establish that it removes every path associated with both CVEs. Operators should not mark systems remediated solely because that flag is Off.

Detection: what can be observed and what cannot

Defenders should look for unusual multipart activity, particularly where an endpoint normally receives only JSON or URL-encoded forms. Useful telemetry includes the request method, target path, content type, response status, duration, origin host, PHP worker errors, and whether an edge control blocked the request.

A first-pass investigation might search web logs for unexpected multipart submissions. For Apache installations that actually log request headers, an example workflow is:

# Illustrative only: requires a custom log format that includes Content-Type.
grep -i 'multipart/form-data' /var/log/apache2/*access*.log

Standard Apache combined logs normally do not contain the request Content-Type header. On those installations this grep will produce no useful result. Use reverse-proxy, WAF, or explicitly configured header logging instead. Avoid recording complete multipart bodies, session identifiers, or uploaded files just to gain visibility; those can contain credentials and sensitive customer data.

In the same window, investigate PHP worker crashes, abnormal restarts, process execution from PHP service accounts, and unexpected outbound connections. These are investigation leads, not signatures unique to PHP2Shell. A quiet log does not demonstrate that exploitation is impossible.

If suspicious activity is found, preserve available proxy records and runtime logs, isolate the host according to the organization’s incident procedure, and assess potential credential exposure. Rebuilding a compromised PHP worker without rotating exposed application secrets may leave the intrusion unresolved.

What to validate after the PHP release

The vendor’s release should change this from precautionary triage into version-specific remediation. Security teams should verify four items before closing tickets:

1. Exact affected releases: use the PHP advisory and changelog, not an unverified claim that every version since PHP 5 is vulnerable. PHP 6 never had a generally released production line, and the upload-progress feature was introduced in PHP 5.4.0; neither fact supplies the official CVE version range.
2. Fixed packages and backports: check package-level security notices. A distribution may backport the fix without changing the upstream-looking version string as expected.
3. Patch deployment: confirm the actual web-facing PHP workers and container images were replaced or restarted as required, and that old pools no longer receive traffic.
4. Residual exposure: keep route restrictions where they serve an independent purpose, then review whether temporary controls can safely be retired.

The initial disclosure is a reminder that a software bill of materials is only the starting point. Security teams also need to know which executable processes untrusted HTTP input and which protections run before that process begins parsing it. Treat PHP2Shell as an urgent runtime inventory and patch-readiness exercise today; close the incident only against the vendor’s confirmed fixes.

References

• PHP: Upcoming Critical PHP Security Release (20 October 2026)
• PHP manual: Session upload progress
• PHP manual: Session configuration
• JackalSyn: PHP-UP-2026 technical report
• CERT-EU: Critical Vulnerabilities in PHP, Advisory 2026-018
• watchTowr: CVE-2026-109618 FAQ
• Ahmed Sultan (0x4148): PHP2Shell, PHP Core RCE Technical Analysis