PHP2Shell: PHP Security Updates and a Response Checklist

What should PHP website owners do now?

Identify the PHP runtime behind every website you operate, apply the appropriate security update, and verify that the running service uses the fixed build. On 21 October 2026, PHP released fixes for CVE-2026-109618 and CVE-2026-109619, often called PHP2Shell. These flaws can permit remote code execution without authentication. Patching is the complete remedy; temporary filtering does not replace it. PHP’s security release explains the scope and fixes.

For Indian organisations, CERT-In’s critical-severity note CIVN-2026-0510, issued on 21 October, provides a local reference for this response. It identifies the affected supported branches and urges updates. A website-maintenance contract should therefore lead to a concrete confirmation from the hosting or development provider, rather than an assumption that someone else has patched PHP. See the CERT-In advisory.

Why this matters beyond the development team

A business may know which content management system runs its website without knowing who maintains the interpreter beneath it. Treat this as an ownership exercise: who controls the hosting account, who can deploy a runtime update, and who verifies that customer-facing functions still work? Include outsourced websites and internal portals in the discussion.

Our recommended response is to track three separate outcomes: exposure identified, vulnerable software replaced, and suspicious activity investigated. Closing the patch ticket addresses only the second. Keeping these outcomes separate helps a small team avoid declaring the entire incident response complete after a successful installation.

How the two vulnerabilities differ

CVE-2026-109618 concerns memory handling when a request runs out of memory. PHP can abort while internal request structures are incomplete, then process that invalid state during cleanup. The PHP advisory describes a demonstrated application-independent path in Apache mod_php. It also explains why PHP-FPM behaves differently during startup failures; that difference is not a blanket exemption from risk. Read PHP’s out-of-memory advisory.

CVE-2026-109619 concerns state retained by a worker across requests. A request can leave a reference to memory that has already been freed; a later operation in the same worker can use it before normal initialisation resets it. Exploitability depends on the affected internal state and configuration. These are runtime flaws, so a login page is not evidence that the underlying request-processing path is protected. Read PHP’s stale-state advisory.

Deployment details matter. Red Hat’s bulletin distinguishes its usual PHP-FPM deployments from higher-risk mod_php configurations and documents product-specific differences. Use the advisory for your operating system or managed product alongside the upstream notice; do not interpret a general PHP version string as the whole risk assessment. Check Red Hat’s product guidance where applicable.

Which versions contain the fixes?

The PHP project lists the following first fixed upstream releases for the supported branches. Select the appropriate supported vendor update for your environment, including later security releases when available. Verify against the official release notice.

PHP 8.1 and older are outside normal upstream support. CERT-EU notes that some distribution or long-term-support vendors provide backports, and that limited source backports exist for certain older branches. A backport needs vendor evidence; it is not permission to assume an old installation is safe. Plan migration to a supported branch. See CERT-EU’s legacy-version and package guidance.

A practical patch-and-verify workflow

The following is CyberDefend’s operational checklist, not a claim that we have inspected your systems. Use your normal authorised change process, with urgency appropriate to an exposed critical vulnerability.

• Create an asset record for each application: owner, hostname, hosting provider, PHP branch, package build, deployment image and exposure to untrusted requests. Ask vendors to account for embedded PHP as well as visibly PHP-based websites.
• Get a precise remediation answer from the owner. For managed hosting, ask which fixed package or runtime is deployed and when. For a vendor-maintained appliance, obtain its product-specific advisory and upgrade path.
• Apply the approved update and replace or restart the affected workers through the supported service procedure. For containers, rebuild and redeploy the application image; changing a base-image tag alone does not demonstrate that existing instances were replaced.
• Verify the runtime serving web traffic, not just the command-line interpreter. Capture the package or image identifier and vendor advisory reference. Use authenticated administration or deployment records rather than exposing a public diagnostic page.
• Test important journeys such as sign-in, forms, uploads and scheduled processing. Record the result and patch time. If an update breaks the application, contain the exposed service while resolving compatibility rather than silently returning it to an unpatched public state.

Investigate activity before the disclosure date

Amazon Threat Intelligence reported an exploitation attempt in MadPot telemetry on 17 October 2026 and further attempts on 21 October before disclosure. Its report explicitly says it was unclear whether those early attempts would have succeeded on real-world systems. This is evidence of attempts observed by Amazon, not evidence that your organisation was breached. Read Amazon’s original report.

Amazon recommends investigating from at least 17 October and examining POST uploads containing PHP_SESSION_UPLOAD_PROGRESS. Preserve available web, proxy, runtime and endpoint telemetry covering that period and earlier where feasible. Treat a matching field as a lead requiring context, not as a standalone compromise verdict. See Amazon’s investigation recommendations.

As general defensive triage, correlate unusual requests with worker crashes, unexpected child processes, unexplained outbound connections, new files and account changes. Compare events with deployments and legitimate upload workflows. These are investigative ideas, not validated PHP2Shell signatures. Access logs often omit request bodies, so a search with no matches cannot establish that exploitation did not occur. Escalate corroborated suspicious activity through your incident-response process.

What temporary controls can and cannot do

AWS explains that a web application firewall can reduce exposure to some request patterns but cannot observe PHP worker memory or cover every vulnerable path. Blocking multipart requests may be useful where an application has no legitimate uploads, while other applications would lose essential functionality. Validate the coverage and business impact of any rule before relying on it. Read the AWS discussion of WAF coverage limits.

If you cannot promptly patch an exposed application, CERT-EU recommends considering isolation from public networks until the fix is applied and verified. Assign an owner and a deadline to that exception. Avoid copying emergency runtime settings without understanding their availability effects and the remaining vulnerability paths. Review CERT-EU’s containment guidance.

The useful takeaway

A reliable response produces evidence: an inventory with owners, a verified fixed runtime, a record of functional checks and an investigation decision. Keep that evidence with the change record. The same approach will make the next runtime advisory easier to handle, even when the application itself has not changed.

This article reflects the sources checked on 23 October 2026. Exploitation evidence and vendor guidance can evolve. Consult the linked advisories for your exact product and configuration; this overview does not certify a deployment as secure.

For further practical learning, explore CyberDefend Academy’s learning paths and hands-on labs. Businesses reviewing their remediation process can also explore our security advisory services.