PHP2Shell

The required outcome

Within the first response cycle, every organisation should know which PHP runtimes are affected, which can be reached by attackers, who owns each system, how it will be fixed or isolated, whether compromise needs investigation, and what evidence is required before closure.

How to use this playbook

• The CISO / Incident Commander uses Sections 1–3 to set priorities, owners and reporting.
• Application, Infrastructure, Cloud and Vendor teams use Sections 4–7 to find and fix affected runtimes.
• SOC / Incident Response uses Section 8 to investigate possible exploitation.
• The vulnerability coordinator uses Sections 9–11 to track exceptions, verify closure and report status.

Important: Use the official PHP and operating-system/vendor advisories as the source of truth for each package. Do not use exploit code against production to test exposure.

1. What is the issue?

PHP2Shell refers to two critical vulnerabilities in the PHP runtime: CVE-2026-109618 and CVE-2026-109619. Under relevant conditions, crafted network requests can cause memory-safety errors that may permit unauthenticated remote code execution or exposure of sensitive process memory. The published severity is CVSS v4.0 9.2 for each CVE.

Fixed upstream releases

Potentially affected web-serving configurations include PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, plus products or appliances that bundle PHP. Public-facing services deserve the fastest response. A host's CLI version may differ from the runtime serving web requests.

Key principle: A source-code scan alone cannot prove production is safe. The organisation must identify and verify the actual runtime, package/build, process state and network exposure.

2. First 24 hours: action plan and decision gates

3. Prioritisation: which systems come first?

Prioritisation must consider internet reachability, data sensitivity, business criticality, runtime privilege, shared tenancy, known exploitation signals and whether safe isolation is possible—not CVSS alone.

4. Role ownership: who does what?

5. Practical discovery checklist: code to production

Safe administrator checks

• Run php -v only as a discovery clue. It reports the CLI binary and may not represent the web runtime.
• Check the actual PHP-FPM or Apache/PHP runtime, package release, loaded modules and process restart status using the operating system/vendor's documented commands.
• For Debian/Ubuntu, RPM-based Linux, Windows, managed hosting or appliances, use the relevant package manager and vendor advisory. A vendor backport may retain an older-looking upstream version string.
• For containers, scan and verify the image digest actually running—not only the tag or a newly built image. Confirm all replicas and autoscaling templates are updated.
• Do not use public proof-of-concept exploit code against production. Use package/advisory validation and controlled, authorised checks.

6. Validate attacker reachability

Reachability labels: PUBLIC = reachable from internet; BROAD INTERNAL/PARTNER = reachable from user, partner or shared networks; RESTRICTED = tightly segmented; NO ROUTE FOUND = no path identified after documented checks. “No route found” does not remove the need to patch.

7. Remediation runbook

• Create or update the change record and confirm application owner, maintenance window, rollback plan and business validation contact.
• Choose the supported fixed PHP release for the application's branch, or apply a vendor-confirmed backport for the exact OS/product package.
• Test compatibility in staging where feasible; for exposed P0 systems, do not let routine release cadence delay immediate containment or urgent patching.
• Update every instance: production, UAT where exposed, DR, standby, secondary region, workers, queue consumers, autoscaling templates, container images and rollback artefacts.
• Restart/recycle PHP-serving processes as required. A package installation alone is insufficient if vulnerable workers remain running.
• Verify the actual web-serving runtime after the change; check package release, process state, image digest and all replicas.
• Run application health and regression checks, review service errors and confirm expected traffic and business functions.
• Update the central tracker with evidence and have a reviewer independent of the implementer confirm closure.

If patching is blocked

• Prefer taking the affected service offline or isolating it from public/untrusted networks until a fix is applied if safe containment is not possible.
• Apply vendor-recommended temporary mitigations and restrict inbound access to explicit trusted sources; block direct-origin routes; minimise service-account privileges and unnecessary outbound access.
• Some configuration changes may reduce exposure but are not a complete fix. Do not label the system remediated on the strength of WAF rules or settings alone.
• Open a time-bound exception with business owner, security risk owner, reason, compensating controls, vendor case, target fix date and next review date.

8. SOC / Incident Response: look for possible compromise

For systems exposed while vulnerable, patching and a clean scan do not prove that exploitation did not occur. SOC should review an agreed time window and escalate credible indicators through the incident response process.

If compromise is suspected: contain the host/workload, preserve relevant logs and volatile evidence where feasible, notify Incident Response, assess lateral movement, rotate potentially exposed credentials from a clean administrative path, and rebuild from a trusted image when indicated. Do not wipe or rebuild before evidence-preservation decisions are made.

9. Closure criteria: no ticket closes without evidence

• Asset identity, business owner, technical owner, environment and criticality are recorded.
• Actual web-serving runtime/SAPI and package/build are identified; CLI version alone is not accepted.
• Fixed upstream release or exact vendor-confirmed backport is documented for both CVEs.
• All relevant PHP workers were restarted/recycled and the fixed runtime is confirmed running.
• All replicas, regions, DR systems, container digests, autoscaling templates, build pipelines and rollback images are covered.
• Public and internal reachability has been checked; origin bypass and alternate routes have been considered.
• Application health/regression tests passed and relevant monitoring is active.
• SOC review status is recorded for systems exposed while vulnerable; suspicious indicators have an incident ticket.
• Evidence links, change ID, verifier, date and any residual-risk acceptance are recorded.

10. Tracker template and reporting

Recommended leadership dashboard

• Total PHP assets identified / total estimated; number with unknown owner or unknown runtime.
• Affected assets by public, broad internal, restricted and no-route-found exposure.
• P0/P1 outstanding, fixed pending validation, closed, exceptions and overdue items.
• Internet-facing systems patched and independently verified; systems isolated/offline.
• Suspected or confirmed incidents, investigation status and business impact.
• Top blockers, accountable owner, decision needed and target resolution date.

11. Communications template for service owners

Subject: Urgent — PHP2Shell vulnerability response and evidence required

Please urgently identify all PHP runtimes supporting your applications and platforms, including production, DR, containers, bundled/vendor components and managed hosting. Confirm the actual web-serving PHP build and whether it is reachable from the internet or other untrusted networks. Prioritise public-facing affected systems, apply the applicable fixed release or vendor-confirmed backport, restart the PHP-serving processes, and submit evidence of the running build and validation. If immediate patching is not possible, restrict or isolate access and raise a time-bound exception with compensating controls and an approved target date. For systems exposed while vulnerable, coordinate a log and endpoint review with SOC. Do not close the item until all instances, runtime processes and exposure paths have been verified.

12. Official references

• PHP2Shell operational information — NCSC-NL
• PHP security release archive
• PHP informational advisory — CVE-2026-115560 (23 October 2026) — subsequent issue outside this playbook's Version 2.0 scope.
• PHP source advisory — CVE-2026-109618
• PHP source advisory — CVE-2026-109619
• Canadian Centre for Cyber Security alert
• NHS England Digital alert

Disclaimer: This playbook supports operational response and governance. Validate package-specific applicability with the official PHP, OS, hosting or product vendor advisory. Any exploit validation requires explicit written authorisation and a controlled test plan.