PHP2Shell RCE Fix Was Set to Drop October 21 — But the Patching Race Across Hosts and Containers Was Just Beginning

Update, 4 November 2026: The PHP project’s advisories identify the two flaws as CVE-2026-109618 and CVE-2026-109619, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA added both to its Known Exploited Vulnerabilities catalog on 26 October, with a 29 October remediation deadline for US federal agencies. Patch status for each Linux distribution and the official Docker images is on our Linux patch status tracker.

According to The Hacker News reporting published October 21, 2026, PHP was set to release fixes for two critical remote-code-execution flaws — collectively called PHP2Shell — at 14:00 UTC that day. That release would close a window that the security firm and PHP core developers involved described, in the same reporting, as having no reliable workaround until the patch landed.

The fix was available upstream. Whether it had reached any given environment depended entirely on the hosting channel — and for a large share of the PHP install base, that gap may still be open at the time of this writing.

What PHP planned to release and what it rated

PHP rated both flaws 9.2 out of 10. The project did not disclose affected version ranges, the specific subsystem involved, or whether any configuration change reduces exposure before patching — it said full details and fixed binaries would ship with the release, according to The Hacker News on October 21.

At the time that article went to press, the release had not yet dropped, which meant no independent researchers could confirm or rule out proposed defenses. That constraint shapes everything below.

The primary PHP advisory and release notes were not available for direct review at publication time. Readers should consult php.net and their distribution's security tracker for version-specific confirmation.

The workaround that does not work

The defense circulating on social media and security blogs before the patch landed was a single php.ini change:

session.upload_progress.enabled=0

GMO Flatt Security, a Tokyo-based security firm, suggested this setting on the morning of October 21, saying it believed the change would help "with some probability" but could not confirm it fully addressed both flaws. By 14:00 Japan time (05:00 UTC) the same day, the firm walked that back publicly, stating the setting alone is not a complete fix and that attacks bypassing it should be expected. It advised administrators to prepare the update, watch for anomalous traffic, and apply the fix as soon as it was released.

Two PHP project members were more direct. Gina Peter Banyard, a PHP core developer and documentation contributor funded by the PHP Foundation, wrote: "The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much." Joe Ferguson, release manager for the upcoming PHP 8.6, was shorter: "ini settings won't save you."

Both quotes were reported by The Hacker News on October 21.

Why the setting fails: GMO Flatt's hypothesis that PHP2Shell lives inside the Session Upload Progress feature was not confirmed by PHP. An independent code audit — from an anonymous account, so treat with caution — argued the specific bug others described in that feature does not exist in released PHP. The upstream release will settle that question.

Exploitation status

As of October 21 reporting by The Hacker News, Cloudflare said it was observing early exploitation attempts and pushed emergency WAF rules it described as a stopgap pending patching. The same reporting found no confirmed compromise had been reported at that time, and noted that public exploit code was circulating but had not been demonstrated to work. As of that October 21 reporting, neither flaw appeared in CISA's Known Exploited Vulnerabilities catalog — that status may have changed since.

These conditions can change rapidly. Engineering and security teams should not treat the absence of confirmed compromise as a signal to delay.

Where the patching gap lives

Upstream PHP releasing a fix at 14:00 UTC does not mean your PHP is fixed. The path from upstream to running production code passes through several layers that each add delay:

• Linux distribution packages (Debian, Ubuntu, RHEL, Alpine for containers) follow their own build and security-publication schedules. A same-day upstream release may take hours to days to appear as a distribution package.
• Shared hosting providers manage PHP upgrades centrally. Tenants typically cannot self-upgrade and depend on the provider's maintenance window.
• Managed platform-as-a-service environments (WordPress.com, Kinsta, WP Engine, and similar) may pin or gate PHP versions independently of upstream.
• Container base images using php:8.x tags on Docker Hub or equivalent registries will not automatically reflect the fix until the image is rebuilt and redeployed. Teams using pinned digests will not see the update at all without an explicit change.
• Self-managed servers running PHP installed from source or a non-distribution package manager require manual intervention.

No primary statements from major hosting providers or distributions were available for this article. Teams should check their provider's security bulletin or support channel directly.

What to verify right now

1. Identify your PHP delivery channel. Run php -v or check your platform's control panel. Note whether PHP is managed by the OS package manager, a hosting provider, a container image, or a custom build.
2. Check whether the patched version is available in your channel. For distro packages, run apt-get changelog php8.x or equivalent. For container images, check the upstream tag's build date. For hosted environments, open a support ticket if no bulletin has appeared.
3. Do not rely on the session.upload_progress.enabled=0 setting as protection. GMO Flatt Security and two PHP core developers have said explicitly it is not a complete mitigation.
4. Apply Cloudflare's emergency WAF rules if your infrastructure sits behind Cloudflare, treating them as a temporary reduction in exposure rather than a fix, per Cloudflare's own framing as reported by The Hacker News.
5. Watch for anomalous PHP process behavior — unexpected child processes, outbound connections from web server processes, or unexpected file writes — as a signal of compromise attempts, regardless of patch status.
6. Check CISA's KEV catalog at cisa.gov/known-exploited-vulnerabilities-catalog for any update to exploitation status. As of October 21 reporting, PHP2Shell was not listed.

Sourcing note

The primary source for this article is The Hacker News coverage published October 21, 2026 (thehackernews.com), which directly quotes GMO Flatt Security's public updates, Gina Peter Banyard's and Joe Ferguson's statements, and Cloudflare's advisory framing. That article was published before the 14:00 UTC release landed, so the reporting reflects pre-patch conditions. The PHP project's own release notes, affected version list, and CVE identifiers were not available for direct review. Until the primary PHP advisory is confirmed, the CVE identifiers and precise version ranges for PHP2Shell remain unverified in this reporting.