CRITICAL ADVISORY: PHP2Shell · CVSS 4.0 9.2
Source review: 22 Oct 2026Open hardening generator →
PHP2ShellResponse Hub
Menu

PHP2Shell version checker

Compare web PHP and verify deployment changes. Free; no credentials.

CVE-2026-109618CVE-2026-109619
I noticed suspicious activity

Live Website PHP & Security Header Inspector

Inspect an anonymous public homepage response. This optional check runs on our service; the manual version evaluator still runs locally. No login or server credentials are needed.

Homepage only, using HTTP/HTTPS and default ports. No paths, query strings, IP addresses or credentials. Redirects are not followed. The check has a five-second deadline.

1. Your PHP version

Local PHP2Shell advisory comparison only. No network scan is performed. Use the version from the web SAPI; PHP CLI may use another binary or INI file.

I don’t know my PHP version

Open WordPress → Tools → Site Health → Info → Server. Copy the complete PHP version; ask your host for the package revision if needed.

WordPress · official instructions

Use authenticated diagnostics; never leave a public phpinfo page. Enter the complete version above.

Application checks: WordPress / WooCommerce

PHP2Shell upstream fixes: 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12

Branch example only; enter an exact version for a patch assessment.

Choose my deployment

Advisories reviewed: 22 October 2026

Public headers can be hidden or spoofed. They cannot establish internal hardening, active WAF coverage, installed package provenance or historical compromise.

CVE-2026-109618CVE-2026-109619Privacy & maintenance
I noticed suspicious activity

2. Choose an applicable PHP2Shell response

Your access / Serving deployment

Select access and deployment before continuing.

3. Verify your PHP2Shell response

Record observations locally after changes; nothing runs automatically. PHP2Shell comparison cannot establish prior compromise or verify vendor packages.

Choose an applicable deployment and template to see the verification steps.

  1. 1. Before changing anything

    Record PHP2Shell package/image versions and configuration; prepare a tested backup and recovery plan. Returning to a vulnerable runtime does not complete remediation.

  2. 2. Apply and replace workers

    Install both PHP2Shell patches. Validate syntax, replace every worker/replica and check application traffic; a TCP probe alone is insufficient.

  3. 3. Check the serving runtime

    Use authenticated web diagnostics for PHP2Shell checks. Compare every origin/replica with the patch matrix or verified vendor advisory; remove temporary diagnostics afterward.

  4. 4. Test the application

    After the PHP2Shell change, test login, uploads and progress. Compare normal traffic and new log errors before and after.

    WordPress: test media uploads, login and WooCommerce checkout if used.

Investigate suspected PHP2Shell compromise

A patched PHP2Shell version cannot clear an incident. Contact your host or incident-response lead through a trusted channel.

  1. 1. Preserve evidence

    Record times and affected systems. Responders should preserve logs, snapshots and volatile process/network evidence before cleanup or restarts.

  2. 2. Contain with the owner

    Coordinate isolation or traffic restrictions with your host. Preserve evidence while limiting damage; assess availability before changing live services.

  3. 3. Investigate scope

    Compare files with trusted releases; review processes, scheduled tasks, accounts and outbound connections. Include rotated logs. A clean grep is inconclusive.

  4. 4. Recover and monitor

    After evidence collection, rebuild affected systems from trusted sources. Revoke exposed credentials and sessions from a clean device; patch every worker and monitor recurrence.

CISA incident-response guidanceReturn to version result

PHP2Shell affects request memory; exposure depends on SAPI, application and configuration.

PHP2Shell facts

Patches
8.2.35 / 8.3.36 / 8.4.27 / 8.5.12; verify vendor backports against both CVEs.
Temporary containment
Upload-progress controls and WAF heuristics reduce selected PHP2Shell paths. PHP 8.5 needs additional startup review; neither replaces complete patches.
Application impact
Standard $_FILES uploads are independent. Test progress polling and business workflows.
After changes
Replace all workers; verify Web PHP and investigate prior compromise separately.
Return to PHP2Shell version check

PHP2Shell CLI checks & log review

These read-only commands review CLI configuration and PHP2Shell indicators. Web PHP may differ. Access logs usually omit request bodies and cookies; clean results cannot establish safety.

1. Local Runtime Check (Bash Scanner / CLI)

Instant PHP2Shell Runtime Configuration Check

Inspects your active PHP CLI and INI configuration to verify whether session.upload_progress.enabled is active.

php -r 'echo "PHP Version: ".PHP_VERSION."
Upload Progress: ".(ini_get("session.upload_progress.enabled") ? "ENABLED (review web SAPI)" : "DISABLED (not a safety verdict)")."
";'
2. Compromise Forensics (Nginx / Apache Logs)

Scan Server Logs for PHP2Shell Exploitation Probes

Searches uncompressed HTTP access and error logs for anomalous PHP_SESSION_UPLOAD_PROGRESS query strings or FPM worker segmentation faults (SIGSEGV).

sudo grep -rnE "PHP_SESSION_UPLOAD_PROGRESS|SIGSEGV.*php-fpm" /var/log/nginx/ /var/log/apache2/ /var/log/php* 2>/dev/null

PHP2Shell WordPress audit & IDS rule suite

Use these PHP2Shell heuristics alongside vendor advisories. They cannot certify a host as protected.

PHP2Shell WordPress integrity check (WP-CLI)

Run as the site owner from the WordPress root. Checks published core/plugin checksums where available; custom and premium code needs a separate integrity review. This does not establish PHP patch status.

wp core version
wp core verify-checksums
wp plugin verify-checksums --all --strict
wp eval 'echo PHP_VERSION, PHP_EOL, PHP_SAPI, PHP_EOL;'
PHP2Shell Suricata HTTP indicator rule

A local heuristic, not a confirmed exploit signature. Requires plaintext HTTP visibility or TLS termination and sufficient request-body inspection limits. Review alerts before taking action.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL upload progress marker observed - investigate"; flow:established,to_server; http.request_body; content:"PHP_SESSION_UPLOAD_PROGRESS"; nocase; classtype:misc-activity; sid:9900618; rev:1;)

# Validate with your installed Suricata version before loading:
# suricata -T -c /etc/suricata/suricata.yaml -S local.rules
PHP2Shell response YARA file triage rule

A broad local triage heuristic for suspicious PHP files. Matches are not proof of compromise; legitimate code may match. It does not identify this memory corruption exploit or scan encrypted traffic.

rule Local_Suspicious_PHP_Execution_Review
{
  meta:
    description = "PHP file triage only; manual review required"
  strings:
    $php = "<?php" nocase
    $decode = /base64_decode\s*\(/ nocase
    $exec = /(eval|shell_exec|system|passthru)\s*\(/ nocase
  condition:
    filesize < 2MB and $php and $decode and $exec
}

// Save as triage.yar; run: yara -r triage.yar /var/www/html

Managing PHP2Shell across a fleet

Track PHP2Shell patches at every origin; EOL hosts need verified backports or migration.

Cloudflare Managed WAF

Confirm PHP2Shell coverage, plan entitlement and origin restrictions with your provider. Filtering supplements runtime patches.

View PHP2Shell Cloudflare rule

WordPress and shared hosting

Without server access, ask your host about both patches and incident support.

Prepare provider questions

PHP2Shell container inventory

Verify image digests and installed packages, not tags alone. Replace every replica; retain application health checks.

Open container examples
In-Depth Technical Advisory • CVE-2026-109618 & CVE-2026-109619

How PHP2Shell affects request memory

Both PHP2Shell CVEs were published on 21 October 2026. They concern PHP runtime memory handling; application updates cannot replace runtime security patches.

1. Does PHP2Shell require an upload form?

A PHP endpoint can parse multipart input before application code, without any upload form. Upload progress touches state before initialization; its configurable PHP_SESSION_UPLOAD_PROGRESS marker cannot cover every PHP2Shell path.

Disable unused tracking and verify Web settings. Standard $_FILES uploads remain separate; test custom progress polling. PHP 8.5 has a fatal-error-backtrace path. Both patches and worker replacement remain necessary.

2. Which PHP2Shell response fits your deployment?

Compare PHP2Shell controls below. Complete runtime patches resolve both vulnerabilities; other layers provide partial containment with deployment-specific requirements.

Select for details.
Remediation options and their deployment requirements
PHP2Shell Defense MethodProtection LevelDowntime RequiredWorks on EOL PHP (5.6–8.1)?Best Use Case
Complete Upstream PatchesReplace Every Worker / ContainerNo (Unless Distro Backported)Supported PHP 8.2–8.5; verify package provenance.
Partial Session-Path ReductionWorker Replacement RequiredYes (All PHP 5.4+ Versions)Temporary session-path hardening only.
Partial Session-Path ControlNginx Reload; Verify PHP WorkersYesAdditional FastCGI control; patch PHP.
Heuristic / Vendor-SpecificNo Origin Restart for Edge RuleYesPartial fleet containment; bypasses remain.

Complete fixes require patched builds and replacement of every worker. Verify backports when the displayed version is older.

Review official patch advisory

3. What remains after patching?

Inventory origins and workers, deploy patches, replace workers and test traffic. Preserve evidence and maintain recovery plans. A patched PHP2Shell runtime does not remove webshells or stolen credentials; absent indicators cannot exclude compromise. Vulnerable rollbacks do not complete remediation.

PHP2Shell primary sources & verification

Reviewed 22 October 2026. PHP2Shell guidance: recheck advisories and vendor packages.

About this guide

Maintainer & corrections

PHP2Shell Response Hub is independent of PHP and Cloudflare. Follow vendor advisories.

Report corrections without credentials or sensitive logs.
What leaves your browser?

Version comparison, configuration and observations stay in memory until reload. Copy buttons write to your clipboard.

Only submitting the optional URL check sends the target to this site’s API and contacts that public host. The application keeps no check history; hosting logs may retain request metadata.

Plausible and Google Analytics load after the page becomes interactive. They may receive URLs, referrers and device data; Google may use identifiers. No custom analytics events contain tool inputs or configuration. Keep secrets out of page URLs.

PHP2Shell change record · 22 October 2026
  1. Version validity, template prerequisites and PHP 8.5 controls.
  2. Deployment routing, actual resource names and verification steps.
  3. Incident guidance, source context, privacy and accessibility review.

Frequently Asked Questions (PHP2Shell / CVE-2026-109618 Guide)

Direct answers to the most critical engineering and DevOps questions surrounding the PHP2Shell vulnerability.

PHP2Shell covers CVE-2026-109618 and CVE-2026-109619, rated CVSS 4.0 9.2: out-of-memory cleanup corruption and stale request state. Remote code execution depends on the SAPI, application and configuration. Upload progress is one relevant path. Review both official advisories.