php2shellPatchUpdate chronologyOverviewWhat to do nowAssess your exposure with an agentCloudflare coverageEvidence and sources

Assess whether the infrastructure available to you is affected by the original php2shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) and the related session upload progress issue CVE-2026-115560. Perform a read-only assessment within your authorized access. Do not send exploit payloads, trigger memory exhaustion, or change systems.

1. Verify the current PHP advisories at https://www.php.net/archive/2026.php#2026-10-21-5 and https://www.php.net/archive/2026.php#2026-10-23-1, along with any superseding PHP, operating-system, or hosting-provider advisories. Establish affected and fixed releases or interim guidance for each CVE, including vendor backports. Cite sources and retrieval dates; flag anything you cannot verify. Report applicability, patch status, and exploitation evidence separately for each of the three CVEs. Do not extend CISA KEV evidence for the original two vulnerabilities to CVE-2026-115560.

2. Inventory PHP across accessible hosts, containers, Kubernetes workloads, images, and managed hosting, including WordPress, Magento, and other PHP applications. Record the service, environment, owner where known, runtime/package version, and image digest or build identity. Distinguish running deployments from repository declarations and unused images. Check the PHP runtime actually serving requests (for example PHP-FPM or Apache), not just the CLI version. If updates were installed, verify that running processes and replicas use the updated build.

3. Compare each deployed runtime against authoritative advisories for the original two CVEs. Do not treat an older version string as vulnerable if the vendor documents a backported fix, or an updated application/plugin as evidence that PHP itself is patched. Identify internet-facing and internal request paths, including origins reachable directly. Record access gaps; absence of PHP in one repository does not establish its absence across the infrastructure.

4. Assess CVE-2026-115560 separately. Inspect effective session.upload_progress.enabled and session.serialize_handler configuration, and application code that uses ini_set() to switch the serializer from php_binary or php_serialize to php before session_start(). Verify the relevant request-handling configuration rather than relying on CLI defaults. If configuration or code is inaccessible, report unknown. Follow current vendor guidance to distinguish fixed, mitigated, and not-applicable deployments; do not assume that updates for the original two CVEs also resolve this follow-up. Report findings without changing settings.

5. Report WAF or other compensating controls separately from runtime patch status. Where configuration is accessible, check whether relevant traffic is proxied, applicable rules are enabled in Block, and exceptions or bypass paths exist. Verify coverage for each CVE rather than assuming one php2shell rule covers every path. A WAF rule, blocked attack, or lack of alerts does not prove that the runtime is patched or that compromise has not occurred.

Return a concise summary and a table: asset/service | deployed runtime/build | assessment per CVE (affected, fixed, not applicable, or unknown) | compensating controls | exposure | supporting evidence | next action. Prioritize affected internet-facing services. List unassessed systems and the exact evidence or access needed to resolve unknowns. Link to current vendor remediation guidance and propose verification steps without applying changes. Do not conclude that the entire infrastructure is unaffected unless the assessed scope supports that conclusion.

Find more information and resources at https://radar.cloudflare.com/security/zero-wire/php2shell