Emergency PHP Updates Fix Critical PHP2Shell Flaws Under Active Exploitation

Emergency security releases have landed for the PHP language runtime following the leak and early disclosure of two critical remote code execution (RCE) flaws collectively named PHP2Shell. Tracked as CVE-2026-109618 and CVE-2026-109619, these vulnerabilities allow unauthenticated attackers to execute arbitrary code or read process memory on servers running vulnerable PHP versions. Because the defects exist within the engine itself rather than application-layer code, virtually any website hosted on an unpatched PHP runtime—regardless of whether it runs WordPress, Laravel, or a basic static script—is directly exposed.

The updates were published around 14:00 UTC on October 21 after an October 20 post on Hacker News leaked details and forced the PHP maintainers to accelerate their release schedule from a planned October 22 disclosure. Both flaws carry a CVSS v4.0 severity rating of 9.2. Security teams at Wiz Research, Calif, and OpenAI’s Codex Security team discovered and reported the vulnerabilities, working alongside the PHP security team and Google’s Gemini team to develop patches.

Vulnerability Mechanics and AI-Assisted Weaponization

PHP2Shell targets memory management flaws deep within the core PHP interpreter engine, stemming from code that has existed in the codebase for over a decade. Researchers traced elements of the vulnerable code path back to PHP architectural research from 2004.

Despite the vintage of the underlying bugs, modern exploit development techniques dramatically shortened the window between discovery and weaponization. Researchers reported that AI models assisted in analyzing the obscure primitives, enabling a single researcher to build a working remote code execution exploit in roughly a week—a process that historically would have demanded months of engineering effort from a dedicated team.

The vulnerabilities manifest across two primary operational vectors:

1. Unauthenticated Remote Code Execution: Depending on how PHP is deployed to handle HTTP requests, an attacker can send a crafted payload that triggers corrupt memory states before application execution even begins.
2. Process Memory Disclosure: Prior to or independent of achieving full code execution, an attacker can issue requests that dump live memory from running PHP worker processes. In multi-tenant environments or shared worker architectures, this worker memory holds sensitive data from other requests, including authentication tokens, API keys, database credentials, and session cookies.

Server Runtime Impact and Attack Dynamics

The severity of PHP2Shell varies based on the Server Application Programming Interface (SAPI) used to host PHP:

• Apache mod_php: Represents the highest risk profile. Working exploits demonstrate that a single, unauthenticated HTTP request can execute arbitrary code before any web application logic or framework setup runs.
• PHP-FPM: Handles worker initialization differently by tearing down worker processes when setup fails early. While PHP-FPM mitigates some early-stage setup triggers, CVE-2026-109619 remains exploitable to full code execution on PHP-FPM when triggered via operations reached during application execution.
• Other Engines: Systems running php-cgi, FrankenPHP, and LiteSpeed are similarly susceptible to memory leakage and execution vectors described in the advisory.

Active exploitation attempts emerged almost immediately following the leak. Cloudflare reported observing early attack vectors targeted against web infrastructure shortly after details surfaced. Security firm watchTowr similarly confirmed active exploitation attempts against both CVE-2026-109618 and CVE-2026-109619.

Organizational Impact and Global Outages

Because PHP powers a substantial portion of the web, multiple organizations elected to take critical systems entirely offline as a precaution while applying runtime updates:

• HR and Payroll Infrastructure: BambooHR temporarily shut down its platform across the United States, Canada, and Ireland to protect subscriber data, warning customers of delayed payroll processing.
• Government and Public Services: In the Netherlands, public broadcaster NOS reported that several major national platforms—including DigiD, the citizen portal MijnOverheid, the parliamentary website, the National Cyber Security Centre (NCSC-NL), and multiple education platforms—were proactively taken offline during patch deployment.

Patching and Mitigation Guidance

The only complete fix for PHP2Shell is updating the underlying PHP engine. Application-level updates (such as updating WordPress plugins or updating framework packages) do not remediate these vulnerabilities.

1. Primary Remediation

Upgrade the host system, container images, or server packages to the following fixed versions and immediately restart all web server processes (Apache, PHP-FPM, LiteSpeed, or custom workers):

• PHP 8.5: Upgrade to 8.5.12
• PHP 8.4: Upgrade to 8.4.27
• PHP 8.3: Upgrade to 8.3.36
• PHP 8.2: Upgrade to 8.2.35

For end-of-life branches (PHP 8.1, 8.0, and 7.4), the PHP project has provided official source backports. Enterprise Linux distribution vendors (Debian, RHEL, Ubuntu) have backported fixes into their long-term support repository packages; system administrators should check package changelogs for the CVE IDs rather than relying solely on the reported version string.

2. Post-Patch Configuration Adjustments

The patch introduces a hard internal memory limit that terminates worker processes instantly if breached, bypassing application shutdown handlers. Administrators should audit memory_limit and post_max_size directives in php.ini to ensure legitimately heavy application requests do not trigger unintended worker terminations post-update.

3. Temporary Workarounds (If Immediate Patching Is Blocked)

If an immediate upgrade cannot be executed, the following settings reduce surface exposure but do not offer complete protection:

• For CVE-2026-109618: Enforce memory_limit=-1 in php.ini to prevent application code from overriding limits, maintain restrictive post_max_size thresholds, and enforce strict request payload size caps at your reverse proxy or web application firewall (WAF). Do not use RLIMIT_AS or RLIMIT_DATA OS-level limits, as PHP maintainers warn these trigger the same vulnerable execution path.
• For CVE-2026-109619: Disable upload progress tracking by setting session.upload_progress.enabled=0 in php.ini and restart all worker processes. On PHP 8.5 builds, also set fatal_error_backtraces=0.

4. Detection Indicators

Security operations teams monitoring for post-exploitation or reconnaissance activity should hunt for:

• Large, unusual multipart HTTP POST requests.
• Spikes in HTTP 500 error responses coupled with memory_limit exhaustion logs.
• Abnormally large PHPSESSID response cookies.
• Unexplained or rapid automated restarts of PHP-FPM or Apache child worker processes.