Emergency PHP Updates Fix PHP2Shell RCE Bugs

The PHP security team released emergency updates on October 21, 2026, to fix two critical flaws that let unauthenticated attackers execute remote code. Researchers now refer to the pair collectively as PHP2Shell, and the bugs carry the official identifiers CVE-2026-109618 and CVE-2026-109619, respectively.

The PHP team assigned each vulnerability a CVSS v4.0 score of 9.2, which places both flaws firmly within the critical severity range. The fixes followed reports that details had leaked ahead of disclosure, and PHP developers warned administrators one day before the release.

On October 20, the PHP development team published an advisory announcing a security release for Wednesday, October 21, at 14:00 UTC. The team also contacted its ANNOUNCE mailing list subscribers and urged every administrator to prepare servers so they could upgrade without delay. The developers withheld technical details, affected versions, and fixed releases, although they reserved the right to ship patches earlier if details surfaced or exploitation appeared.

Meanwhile, researchers at watchTowr told BleepingComputer that the two flaws enabled remote code execution and likely affected PHP versions 5, 6, 7, and 8. watchTowr CEO Benjamin Harris said the leaked information was genuine, stating that "we can confirm that these vulnerabilities are indeed real."

The firm also claimed it had reproduced CVE-2026-109618, yet it chose to withhold technical information until official security patches became available. A now-deleted Hacker News post had earlier claimed that both flaws carried CVSS scores of 10.0 and reached back to PHP 5. Those figures differed from the official assessment, since the PHP security team ultimately rated each vulnerability at 9.2 rather than the maximum score.

Researchers from Calif, OpenAI, and Wiz discovered vulnerabilities that affect every PHP installation serving web requests across common server configurations. Affected setups include PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, which together power a substantial portion of the modern web.

The PHP security team singled out one configuration, stating that "we consider the risk highest for mod_php" because of a demonstrated exploit. In that scenario, an unauthenticated request can trigger the attack before any application code runs, so application-level defenses offer no protection against it.

Both flaws stem from the same underlying weakness: PHP can leave its memory in a corrupted state when a request ends abnormally. CVE-2026-109618 involves out-of-memory handling in the interpreter, since an allocation failure can interrupt PHP while internal request data remains only partially initialized.

The request cleanup routine may then treat that invalid data as valid, which gives attackers a path to code execution as the web worker account. Attackers can reach this condition through several multipart parsing tricks, such as sending parts with unlimited headers or requests without a usable content length.

CVE-2026-109619 involves stale global state, in which internal data belonging to one request survives after PHP has already freed its backing memory. A later request that reaches the same worker can use that stale data before normal initialization resets it, creating a use-after-free condition.

According to the GitHub advisory, attackers can exploit this flaw to perform unauthenticated heap use-after-free, disclose memory, and execute code remotely with worker privileges. The advisory also highlights PHP's session upload progress feature, which ships enabled by default and can both produce and consume the stale state.

Patched Versions and Support for Older Releases

The PHP project shipped PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to address both flaws, and it urged all users to update immediately. Website owners unsure which version they run can follow our guide on how to check and update your website’s PHP version. Linux distributions and long-term support vendors received the patches in advance, so administrators should check with their vendors for updated packages right away.

The PHP project no longer maintains PHP 8.1 and older branches, although some distributions and vendors still provide backported fixes for those releases. Given the severity, the security team also published minimal source backports for PHP 7.4, 8.0, and 8.1 to help anyone building from source.

The developers also urged users of the volunteer-run rpms.remirepo.net repository to switch to distribution packages, since that repository could not deliver same-day updates. PHP 8.2 reaches end of life on December 31, 2026, so administrators running that branch should also plan an upgrade to a supported version. Organizations that run outdated branches face the greatest risk, because they may lack any official fix for these newly disclosed flaws.

Cloudflare responded on October 21 with an emergency update that added seven new rules to its Cloudflare Managed Ruleset for detecting anomalous request patterns. The new detections, labeled Generic Rules Anomalous Execution 1 through 7, all carry a default action of Block rather than simply logging suspicious traffic.

Cloudflare CTO Dane Knecht confirmed that the protections cover all customers, including free plan users, and that the company had already observed early attacks. Knecht nevertheless stressed that these rules offer only temporary protection and urged administrators to install the official PHP updates without delay.

The UK National Cyber Security Centre also warned organizations to update PHP systems immediately or take them offline until administrators can apply patches. VirusTotal estimates that more than 5.1 million PHP hosts sit exposed online, and roughly 3.8 million of them have at least one open port. PHP powers an estimated 75 to 80 percent of all websites, including platforms built on WordPress, Joomla, and Drupal, which magnifies the potential impact.

The PHP security team shared several temporary measures for administrators who cannot update immediately, though it warned that none fully prevent exploitation. PHP core developer Gina Peter Banyard also cautioned that no workaround completely blocks the attacks, which leaves the official patches as the only permanent defense. For CVE-2026-109618, the PHP team recommends the following configuration changes, which reduce exposure to the confirmed out-of-memory attack path in particular:

• Set memory_limit=-1 through php_admin_value in the FPM pool or Apache configuration, and confirm that no application or directory setting restores a finite limit.
• Lower post_max_size to 8M for applications without file uploads, or to 32M when uploads remain necessary, and keep upload_max_filesize below that value.
• Enforce container or cgroup memory limits that kill only the affected worker, and avoid using RLIMIT_AS or RLIMIT_DATA, as they can trigger the vulnerable path.

The team also urges administrators to enforce limits on request size, field count, multipart part count, and nesting depth at the web server or proxy level. These limits must also cover requests that lack a valid Content-Length header, since attackers can exploit them to bypass initial size checks. For CVE-2026-109619, the team suggests a separate set of changes, and administrators must restart every PHP worker after applying each one:

• Set session.upload_progress.enabled=0 in php.ini or server configuration, rather than through ini_set() or .user.ini, to block the confirmed session-based attack paths.
• On PHP 8.5, set fatal_error_backtraces=0 to remove the fatal error backtrace path, which researchers used in the confirmed mod_php exploitation case.
• Remove invalid or deprecated per-request settings that emit diagnostics early, because hiding warnings with error_reporting, display_errors, or the @ operator does not help.
• Fix fatal errors and execution timeouts that attackers can reach, including failures inside callbacks, upload processing, import routines, and cleanup code paths.

Some researchers also proposed blocking HTTP requests that use the multipart/form-data content type, although this approach can break website forms and file uploads. Administrators should therefore treat every workaround and firewall rule as a stopgap, rather than a substitute for installing the patched PHP releases.

With public attention on PHP2Shell growing and early attacks already reported, threat actors will likely accelerate efforts to weaponize both flaws against unpatched servers. Organizations running PHP should identify every exposed server, apply the relevant updates, and review logs for signs of compromise as quickly as possible.