TL;DR
On October 21, 2026, the PHP team released PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 to fix two critical PHP RCE vulnerabilities. Both CVE-2026-109618 and CVE-2026-109619 score CVSS v4.0 9.2 and allow unauthenticated remote code execution as the web worker account. PHP has now published full advisories, and admins should update immediately.
- Product: PHP Group PHP
- Vulnerabilities: 2 flaws (CVE-2026-109618, CVE-2026-109619)
- Highest severity: 9.2 (Critical Β· CVSSv4)
- Worst impact: RCE via OOM corruption
- Status: No confirmed exploitation yet; patches available
- Action: Update to 8.2.35, 8.3.36, 8.4.27, 8.5.12 now
| CVE | CVSS (CVSSv4) | Type | Fixed in | Status |
|---|---|---|---|---|
| CVE-2026-109618 | 9.2 | RCE via OOM corruption | 8.2.35, 8.3.36, 8.4.27 (+1) | Not exploited |
| CVE-2026-109619 | 9.2 | RCE via stale global state | 8.2.35, 8.3.36, 8.4.27 (+1) | Not exploited |
Why It Matters
PHP powers WordPress, Drupal, Magento and most shared hosting. Both flaws sit in PHP’s core request handling, not in a rarely used extension. Moreover, the confirmed attacks work before any application code runs.
These PHP RCE vulnerabilities leaked before the patch, which forced an early warning from the PHP team on October 20. Shortly after, Cloudflare CTO Dane Knecht said his company was “seeing early attacks emerging” and had deployed firewall rules for the “known exploit vectors.”
How the Attacks Work
CVE-2026-109618: memory corruption after out-of-memory
PHP jumps out of the current task when it runs out of memory. According to the advisory for CVE-2026-109618, this can leave “the request memory in an invalid state.” The cleanup code may then act on that broken memory.
Attackers can force the out-of-memory condition with crafted multipart requests that stay within normal size limits. PHP says this “happens entirely before any application-specific code begins execution” on Apache mod_php.
CVE-2026-109619: stale state between requests
PHP keeps some global state across requests in the same worker process. The advisory for CVE-2026-109619 explains that some operations “inadvertently access stale state not reset by the previous request.” That causes a use-after-free.
Exploitation needs two linked requests handled by the same worker. One leaves stale data behind, and the next one uses it. PHP confirmed two such paths, one in PHP 8.5 fatal error backtraces and one in session upload progress.
Which setups are exposed
- Apache mod_php: confirmed remote code execution for both flaws, with default limits.
- PHP-FPM: confirmed for the session upload progress path. For CVE-2026-109618, PHP calls FPM “susceptible,” but no full exploit has been shown.
- FrankenPHP and LSAPI: likely or conditionally susceptible, based on source analysis.
Detection is hard
Logs offer limited help. Hiding errors with error_reporting or display_errors does not block CVE-2026-109619. PHP adds that “absence of an error in logs is not proof of safety.” Even so, it urges admins to review logs for repeated warnings, fatal errors and timeouts on routes that attackers can reach.
The advisories credit four reporters on GitHub, along with four PHP developers who built the fixes.
Exploitation status
Cloudflare reports early attacks, but PHP’s advisories do not confirm exploitation in the wild. Neither CVE appears in CISA’s KEV catalog yet. PHP has not released exploit code.
Affected Versions
Both flaws affect PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. PHP 8.1 and older no longer receive official fixes, so those servers stay exposed unless a Linux vendor backports the patch.
Patch and Mitigation Steps
PHP is blunt: updating “is the only complete mitigation.” Upgrade to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, then restart every PHP worker.
If you cannot update yet, PHP lists partial workarounds:
- For CVE-2026-109618, set memory_limit=-1 administratively. PHP warns “this is not a complete mitigation.”
- On PHP 8.5, set fatal_error_backtraces=0.
- Set session.upload_progress.enabled=0 unless you need it.
- Block multipart requests at the frontend if your app does not use them.
- Keep post_max_size small and limit input nesting, variables and uploads.
PHP also warns against using RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable code path. Given early attack reports, these PHP RCE vulnerabilities belong at the top of every web team’s patch list.
Support Our Threat Intelligence
Find our vulnerability reports and weekly recaps helpful? Support our work today and unlock a 100% ad-free reading experience!