PHP2Shell: A Four-Stage Response to Two Critical PHP Vulnerabilities

On October 21, 2026, the PHP project and the Canadian Centre for Cyber Security published advisories for two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619. Researchers and Amazon have called the issue PHP2Shell. The flaws sit below the application. A website can be exposed even when its own code is sound.

What follows is an incident-based analysis of that public reporting, and a four-stage response SecureBit recommends for turning it into a bounded program of work. It is not a reconstruction of a SecureBit investigation, and it does not describe a client incident.

Executive summary

PHP2Shell is an engine problem. The PHP security advisory says the two vulnerabilities can allow unauthenticated remote code execution. The Canadian Centre for Cyber Security's alert AL26-026 says internet-facing PHP servers and applications are at heightened risk. The alert says PHP assesses the risk as greatest for Apache with mod_php, because a demonstrated exploit lets an unauthenticated request trigger the vulnerability before application-level code runs. PHP's own October 21 advisory says the project considers the risk highest for mod_php. Installations named by both include PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

For CVE-2026-109618 and CVE-2026-109619, the supported fix is still an upgrade. PHP and the Cyber Centre name the same fixed releases: 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older no longer receive updates from the PHP project. PHP also published minimal source backports for 7.4, 8.0, and 8.1 for people building from source or without a vendor package. The PHP 8.2.35 release note says PHP 8.2 reaches end of life on December 31, 2026. A vendor package is worth confirming. A guess that an old branch is safe is not.

Amazon Threat Intelligence reported a PHP2Shell exploitation attempt in its MadPot honeypot on October 17, 2026, four days before public disclosure, and later described broad exploitation attempts once the embargo lifted on October 21. Amazon also recorded further attempts that morning, before the embargo lifted at 14:00 UTC, and said it was unclear whether those attempts would have succeeded on real systems. AL26-026 is dated October 21, 2026, and was updated on October 23. It still says the Cyber Centre has seen open-source reporting of a proof of concept and has not identified active exploitation at this time. Those statements describe different observations. For a look-back, Amazon's October 17 date is the earlier one.

October 23, 2026: a separate PHP advisory

This section is not part of the PHP2Shell fix. On October 23, 2026, PHP published an informational advisory about session upload progress, tracked as CVE-2026-115560. The same day, the Cyber Centre added Update 1 to AL26-026. Both say this issue is not resolved by the security updates released on October 21. PHP recommends setting session.upload_progress.enabled=0 until the next regular bugfix release. The Cyber Centre repeats that recommendation until a security update is available, and says organizations that already kept this setting in place for CVE-2026-109619 do not need further action specifically for CVE-2026-115560.

PHP says the issue can occur only under an unusual combination of configuration and application code. The session serialization handler must be set to php_binary or php_serialize, the application must change it to php at runtime with ini_set() before session_start(), and session upload progress must still be enabled. The Cyber Centre describes the same requirement as an uncommon combination of configuration and application behaviour. Applications that do not change the serialization handler at runtime are not exposed to this vector. PHP says those applications can keep the feature enabled.

PHP has not stated a severity, a fixed release, or a patch date for CVE-2026-115560. It says a full advisory will be published with the next release. None of this withdraws the October 21 fixes. PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 remain the supported fixes for CVE-2026-109618 and CVE-2026-109619. The upload-progress setting was already a partial mitigation in PHP's October 21 advisory for CVE-2026-109619. PHP's technical advisory for that CVE, GHSA-6wmf-4rv5-p3rp, also says it might be prudent to leave the feature disabled after patching when an application does not need it. That precaution belongs to the earlier issue. It is not a claim that the October 21 releases failed.

The two PHP2Shell vulnerabilities

Wiz Research says it reported the issues to the PHP security team on August 24, 2026, after confirming unauthenticated remote code execution against representative deployments. PHP acknowledged the reports on September 21, 2026, and published patched releases on October 21, 2026. Wiz's write-up attributes the research to its own team working with the PHP project, Calif, and OpenAI. That timeline is theirs. SecureBit was not part of it.

The PHP advisory describes the two CVEs in plain language. CVE-2026-109618 is remote code execution via out-of-memory corruption: out-of-memory handling can interrupt PHP while internal request data is only partially initialized, and request cleanup may then treat that invalid data as valid. CVE-2026-109619 is remote code execution via stale global state: request-owned internal state can survive after its backing memory has been freed, and a later request handled by the same worker may use that stale state before normal initialization resets it. The Cyber Centre classifies both as use-after-free issues, CWE-416.

Wiz Research also describes memory disclosure, in which process memory from outside the attacker's request could be returned, and says the vulnerable behavior reaches across many PHP versions, including releases from the last decade and back to PHP 5.4. Treat that scope as Wiz's research claim. The operational list to act on is the one in the PHP and Cyber Centre advisories: supported branches before the fixed releases, plus any older install whose vendor has or has not shipped a backport.

• CVE-2026-109618: remote code execution via out-of-memory corruption, as described in the PHP security advisory. Fixed in the October 21 supported releases.
• CVE-2026-109619: remote code execution via stale global state on a later request to the same worker, as described in the same advisory. Fixed in those same releases.
• CVE-2026-115560: a separate issue in PHP's October 23 informational advisory. The October 21 releases do not resolve it. PHP has not named a fixed version.
• Public disclosure of PHP2Shell: October 21, 2026. Amazon reports a honeypot exploitation attempt on October 17, 2026, before that disclosure.

Business impact

The business risk is not limited to a single content-management system. PHP still runs a large share of public and internal web applications, including sites an organization may have inherited, hosted for a customer, or embedded in an appliance. Wiz names WordPress, Drupal, Joomla, and MediaWiki as examples of the ecosystem, and says exploitation does not require a flaw in those products. A marketing site, a partner portal, a legacy intranet, and a vendor appliance can all be in scope for the same engine bug.

The technical risk follows from where the flaw executes. Because the demonstrated mod_php path can be reached before application code runs, a well-reviewed plugin, a locked-down admin account, or a passing application scan does not close it. Internet-facing systems are the priority the Cyber Centre names. Systems that are not on the public internet still matter when they process untrusted input or when a bundled PHP runtime is invisible to the application inventory.

There is also a timing risk. Amazon's lesson from this event is that an embargo protects defenders only until someone else finds the same bug, and that the time from patch to working exploit is shrinking. A seven-day or thirty-day patch window assumes a delay Amazon says no longer exists for critical internet-facing flaws. Compromise, if it happened, may predate the advisory. A report that starts on October 21 can miss the days that matter.

A four-stage response framework

The stages below are SecureBit's recommended way to organize the work. They line up with the actions in the Cyber Centre alert and with Amazon's guidance to patch, look backward, and not treat a temporary control as a cure. They are not a diary of work SecureBit performed on this incident.

• Discover exposure. Find every place PHP answers a web request. Include PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed, containers, and appliances or vendor products that ship a PHP runtime. Record the branch and the package, not a yes-or-no answer to whether the organization uses PHP. Start with internet-facing systems, then internal applications that accept untrusted input. The Cyber Centre specifically calls out third-party products that include PHP.
• Prioritize and remediate. Update internet-facing systems and anything that processes untrusted input first. For CVE-2026-109618 and CVE-2026-109619, the complete fix is a fixed supported release, 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or a vendor package that backports the same correction. PHP 8.1 and older are outside PHP project maintenance. Where immediate remediation is not feasible, the Cyber Centre says organizations should consider isolating internet-facing applications from public networks until a fix can be applied. Temporary steps can reduce some attack paths. PHP says they do not make an installation safe. Amazon says there is no configuration-only workaround that fully addresses both of those CVEs. Keep session.upload_progress.enabled=0 until the next regular bugfix release, which is PHP's October 23 recommendation for the separate CVE-2026-115560 follow-up. That setting does not replace the October 21 update.
• Validate and investigate. After the change, confirm the version that is actually running, including workers that did not restart and images that were rebuilt in name only. Then look backward at least to October 17, 2026. Review web, application, authentication, and endpoint logs. Amazon points defenders at POST requests that carry the PHP_SESSION_UPLOAD_PROGRESS field, unexpected process execution, and unexpected file changes on web servers. Wiz Research also suggests attention to unusual multipart requests, memory-limit errors, repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies, and unexplained PHP worker churn. Those are leads for an investigation. They are not proof, and they are not a reason to delay the update.
• Report business risk. Tell leadership which business services depended on an affected runtime, which systems are now on a fixed release or a confirmed vendor backport for the two October 21 CVEs, which still need the October 23 upload-progress setting, and which are still exposed or simply unknown. Separate "patched today" from "no evidence of earlier misuse." Name residual risk in appliances, unsupported branches, and any host that could not be isolated. A version list with an owner and a date is the report. A single green status for PHP is not.

Lessons for CISOs and security leaders

• Treat the public advisory as a notification, not as the first possible day of exposure. For this issue, Amazon says to investigate from at least October 17, 2026.
• For a critical flaw on an internet-facing runtime, Amazon says the useful clock is hours. A seven-day or thirty-day window assumes a delay Amazon says no longer exists.
• Inventory has to include PHP inside images, appliances, and vendor products. The application team may not know the engine version.
• Application security work still matters, and it does not retire an engine vulnerability. For the two PHP2Shell CVEs, the fix is the runtime update.
• Use temporary controls only as a bridge. Say so in the same sentence that approves them. A firewall rule is not remediation, and the October 23 upload-progress setting is not a substitute for 8.5.12, 8.4.27, 8.3.36, or 8.2.35.
• The measurable outcome is a dated list of exposed services, fixed versions, the October 23 follow-up, look-back results, and accepted residual risk. That is the reduction a board can audit.

How SecureBit helps

SecureBit's vulnerability management work is built for this kind of question: where the exposure actually is, which of it matters to the business, and whether the fix can be shown afterward. Incident readiness work is the other half, the look-back and the evidence, when a critical advisory lands before a team has a complete asset list. Neither offer is a claim that SecureBit handled PHP2Shell for a customer.

A conversation is a separate step from reading this note. Sending a message does not start an assessment or a project.

• Vulnerability and risk management
• Incident response and threat readiness
• Book a risk discussion

References and source links

The dates, versions, and exposure notes above are drawn from these sources. Where two sources differ, the article says which one said what. PHP has not published a severity, fixed release, or patch date for CVE-2026-115560.

• PHP security advisory, October 21, 2026: critical remote code execution vulnerabilities
• PHP informational advisory, October 23, 2026: session upload progress (CVE-2026-115560)
• PHP 8.5.12 release announcement
• Canadian Centre for Cyber Security alert AL26-026, updated October 23, 2026
• Wiz Research: PHP2Shell
• Amazon Threat Intelligence on PHP2Shell exploitation in MadPot

This is an incident-based analysis and a response framework SecureBit recommends. It summarizes public reporting on PHP2Shell. It is not a record of a SecureBit client engagement. SecureBit does not claim to have responded to, investigated, or remediated a PHP2Shell incident for a client. No client name, outcome, or savings figure is stated because none is being claimed.