Severe memory flaws in PHP expose web servers to remote takeovers

Two long-hidden vulnerabilities in the core engine of PHP permit arbitrary command execution on internet servers before application software can inspect incoming requests.

When a web server runs out of working memory, the software handling the request must abandon what it was doing and tidy up. In well-behaved systems, the program cleanly undoes partial changes and resets its workspace. When an execution engine instead abandons tasks midway through building internal records, fragments of uninitialized memory linger in places where the server expects finished data.

That sequence exposes the server to takeover. An incoming request delivers input designed to exhaust the interpreter memory pool. As the engine attempts to catalog the incoming information, it hits an operating limit and triggers an abrupt exit routine. Because the routine skips normal cleanup, internal pointers remain aimed at discarded or unassigned memory blocks. When the server processes the next step or handles a following request, it misinterprets whatever bytes sit in those locations as valid execution instructions.

On October 21, 2026, the PHP development group issued emergency security updates for two vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619, collectively named PHP2Shell.¹² Both flaws carry a severity score of 9.2 out of 10 under the Common Vulnerability Scoring System, reflecting an ability for unauthenticated remote attackers to execute arbitrary system commands.¹³ PHP acts as the server-side scripting language for an estimated 70% to 80% of websites across the public internet, underpinning content platforms such as WordPress, Drupal, and Joomla.¹² Researchers identified the underlying flaws with assistance from artificial intelligence tools developed by OpenAI, alongside investigators from the security firms Calif and Wiz.¹²

How does an interrupted web request expose server memory?

The PHP interpreter triggers memory corruption by using an abrupt control jump that halts active functions without unwinding internal data structures.³² Amit Serper, an investigator at CrowdStrike, reported that the Zend engine powering PHP relies on a low-level function called longjmp to handle fatal errors such as memory exhaustion or execution timeouts.³ When an allocation crosses the memory boundary, the engine terminates processing without running destructors or rolling back incomplete operations, leaving data structures in an inconsistent state.³

In CVE-2026-109618, the problem occurs within the internal hash table mechanism that PHP uses to store arrays and incoming request variables.³ The engine records that a new element exists and advances its usage counter before the memory for the element key is successfully allocated.³ When that key allocation exceeds the memory limit, the request terminates immediately, leaving an uninitialized entry in the hash table.³ As the request shuts down, cleanup routines attempt to release the uninitialized entry, misinterpreting leftover heap bytes as valid memory pointers and executing attacker-controlled system calls.³

The second vulnerability, CVE-2026-109619, corrupts the persistent state that survives across consecutive requests handled by the same worker process.³⁴ When an error aborts processing during session initialization or data serialization, global variables retain references to memory addresses freed at the end of the request.³ A subsequent web request handled by that same worker then reads the stale pointer, enabling an attacker to manipulate execution across two staged transmissions.³

What makes these flaws reachable before application code runs?

Incoming web data is assembled by the interpreter before any website scripts or security plugins are loaded into memory.³⁵ According to analysis by Amit Serper, the PHP engine parses incoming form variables during initial request startup, prior to activating extensions or compiling application files.³ As a result, defensive security controls written within website software cannot inspect or intercept the malicious input before the corruption occurs.⁶³

Server architecture determines the immediate risk to host environments. The PHP security team assessed the threat as highest for servers running the Apache mod_php module, where an unauthenticated transmission can trigger exploitation before any user code executes.²⁵ Environments utilizing PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed also face exposure, though worker recycling rules can alter the timing needed to exploit global state corruption.¹³ Sergiu Gatlan reported that the affected code paths date back more than seven years, originating in changes introduced during the development of PHP 7.²³

What can server administrators do to close the opening?

Official software upgrades resolve the memory safety errors by fixing structural allocation ordering and resetting global pointers after aborted requests.⁴³ The PHP project released patched builds across its active release branches on October 21, 2026, delivering versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12.¹ Deployments running PHP 8.1 or older releases no longer receive upstream maintenance, leaving older installations dependent on operating system vendor backports or complete language upgrades.¹⁵

These laboratory findings and technical demonstrations evaluate exploit mechanics rather than measuring the exact number of compromised machines in the field. Security scans that tally public server banners indicate exposure rather than active compromise, because specific memory limits, upload settings, and process lifespans govern whether an exploit succeeds. Demonstrations confirm that an unauthenticated attacker can achieve command execution under standard configurations, but they do not prove that every server displaying an affected version banner is vulnerable in practice.

The Check Point Research Team reported that approximately 884,000 public hosts reported running PHP 8.1 or older versions on internet scanning indexes in October 2026, representing about 59% of the roughly 1.5 million servers that broadcast an identifiable version.⁶ To mitigate exposure where immediate updates are delayed, administrators can adjust memory allocations, restrict post body sizes, and disable file upload progress tracking to prevent requests from reaching the vulnerable abort paths.⁴

Save this story

The record

25 sentences trace to 6 sources.

All 6Documents 1Records 0Reporting 5People 0

1. 1 A AlternativeTo Document · alternativeto.net · 22 Oct 2026 PHP patches critical AI-discovered PHP2Shell vulnerabilities affecting millions of sites See the source
2. 2 B BleepingComputer Third-party reporting · bleepingcomputer.com · 21 Oct 2026 PHP ships emergency patches for critical PHP2Shell flaws See the source
3. 3 C crowdstrike.com Third-party reporting · crowdstrike.com CrowdStrike Protects Customers from Threats Delivered via PHP2Shell See the source
4. 4 I ipa.go.jp Third-party reporting · ipa.go.jp PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell) | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構 See the source
5. 5 C cyber.gc.ca Third-party reporting · cyber.gc.ca AL26-026 - Critical vulnerabilities impacting PHP - CVE-2026-109618 and CVE-2026-109619 - Canadian Centre for Cyber Security See the source
6. 6 B blog.checkpoint.com Third-party reporting · blog.checkpoint.com · 21 Oct 2026 PHP2Shell: Critical PHP Vulnerabilities - Check Point Blog See the source