01What was disclosed on October 21
PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619. PHP's security advisory urges all users serving web requests to update immediately. It lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed among the affected deployment types. PHP identifies mod_php as the highest-risk configuration, with a demonstrated attack triggered by an unauthenticated request before application code runs.
This distinction matters: an application can have current plugins and a secure login page while its underlying PHP runtime remains vulnerable. PHP powers applications such as WordPress, Drupal and Joomla, but PHP2Shell is not a vulnerability confined to any one of those products. Nor does a headline about PHP's popularity prove that every PHP website has been compromised.
02Two memory-safety failures, one urgent response
CVE-2026-109618 concerns out-of-memory handling. PHP can be interrupted while internal request data is only partly initialized; cleanup may then treat invalid data as valid. CVE-2026-109619 concerns stale global state: internal state belonging to a request can survive after its backing memory has been freed, and a later request on the same worker can use it before normal initialization resets it.
Both issues cross the boundary between an incoming web request and the engine's internal memory management. Successful exploitation can mean running code with the privileges of the web worker. That is serious, but it is not automatically the same as root access. The potential impact depends on the files, credentials, databases and network resources available to that worker.
03Which releases fix the two PHP2Shell flaws?
The October 21 fixes are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Upgrade to the fixed release for your supported branch, or a later release containing those fixes. If your Linux distribution or hosting provider supplies PHP packages, confirm its advisory: a vendor may backport a security fix without using the upstream version number.
PHP 8.1 and older no longer receive updates from the PHP project. Some distribution and long-term-support vendors provide backports, but support must be confirmed with that vendor. PHP also supplied minimal source backports for 7.4, 8.0 and 8.1; their existence does not make an unsupported branch generally maintained. Do not assume that an old installation is safe because it still works.
Check the runtime used by the website, not only a command-line PHP installation. Inventory hosting accounts, containers, FPM pools and less-visible sites on the same infrastructure. Deploy the updated packages or images, restart or replace the relevant workers, and have the responsible administrator verify the effective runtime and application health. For managed hosting, request confirmation that the web-serving fleet has been patched.
04The October 23 follow-up is a separate issue
On October 23, PHP issued an informational advisory for CVE-2026-115560, a separate session upload progress issue not fixed by the October 21 releases. It requires an unusual combination: session upload progress remains enabled, the application configures session.serialize_handler as php_binary or php_serialize, then switches it to php at runtime before calling session_start(). This is not the same exposure as the original two PHP2Shell flaws.
PHP suggests setting session.upload_progress.enabled=0 until the next regular bugfix release. If you already disabled it following the October 21 guidance, keep it disabled. Have the administrator apply configuration changes at the appropriate server level and restart the relevant workers. PHP says applications that never change the serialize handler at runtime can keep the feature enabled. Follow the latest PHP advisory rather than treating the emergency release as the end of the story.
05Attack attempts are not proof of a breach
AWS Threat Intelligence reported an exploitation attempt against its MadPot sensors on October 17, before public disclosure, and additional activity afterward. These observations make rapid patching important. They do not prove that a particular company has been breached, and the source of the actor's early exploit information remains unclear.
If compromise is suspected, preserve relevant logs and involve qualified responders. Investigate unusual web-worker behavior, unexpected file changes and access to secrets or downstream services. Patching prevents the corrected vulnerability from being used again; it does not remove persistence or undo access that an attacker may already have obtained. Keep confirmed observations separate from assumptions when communicating with customers and colleagues.
06What website owners should do now
Identify who owns each PHP deployment, confirm the correct fixed package is running, and review the October 23 session guidance. PHP explicitly warns that temporary configuration mitigations reduce particular attack paths but do not make an unpatched installation safe. A web application firewall can add protection, but it is not a substitute for updating PHP.
Use this event to rehearse the handoff between business owners, hosting providers and security teams: who receives an emergency advisory, who can authorize the update, and who verifies it afterward? Clear ownership and practiced response turn a critical headline into a controlled action plan. This article reflects advisories available on October 24, 2026; consult the linked sources for subsequent changes.
Sources & further reading
PHP — October 21 security advisory and October 23 session upload progress update
Wiz Research — PHP2Shell technical research and disclosure
AWS Threat Intelligence — PHP2Shell attempts before public disclosure
Continue with MindSec
Explore MindSec cyber defense and incident response training