PHP CVE-2026-109618: Exploited RCE Flaw and How to Patch

On October 21, 2026, the PHP project published fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. Both can lead to unauthenticated remote code execution (RCE) in the PHP runtime itself. On October 26, CISA added CVE-2026-109618 to its Known Exploited Vulnerabilities catalog.

If you run a website on PHP, including WordPress, WooCommerce, Laravel or any custom application, this affects you even if every plugin and framework is current. The flaw is in PHP, so the fix is a PHP update and a restart of the PHP workers.

What happened

The PHP maintainers released patched versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. According to the vendor advisories, all earlier releases in those four branches are affected. The two issues are tracked in separate advisories, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), and the first advisory tells administrators to follow the remediation advice from the second as well.

CISA describes CVE-2026-109618 as an out-of-memory corruption vulnerability allowing unauthenticated remote code execution. Its entry lists a due date of October 29, 2026 for federal agencies, says forensic triage is required, and marks use in ransomware campaigns as unknown.

What we know about exploitation

The exploitation signal comes from the CISA catalog listing for CVE-2026-109618. The research does not include details of who is exploiting it, how many sites are affected, or what attackers do after gaining access, so we will not guess at those.

On the other side, Wordfence reported on October 22 that attacks were continuing but that it had not observed any confirmed compromises resulting from these vulnerabilities. It took that as an indicator of the exploit's complexity. That statement predates CISA's listing, so treat it as reassurance about difficulty, not as a reason to wait.

There is also a source discrepancy. The CVE record we reviewed shows CVE-2026-109618 in the KEV catalog and CVE-2026-109619 without a KEV entry. However, CISA's own catalog page for CVE-2026-109619 shows an entry with the same October 26 date. Because the sources disagree, the safest reading is to treat both as urgent and patch for both.

Technical details in plain terms

CVE-2026-109618: out-of-memory corruption

When PHP runs out of memory, it uses a C mechanism called longjmp() to abandon the current request immediately. The advisory explains that in some contexts, request memory is reachable before it is fully initialized. If an allocation fails at that moment, PHP leaves that memory in an invalid state, and the cleanup step at the end of the request then reads or branches on it. The advisory states that multiple out-of-memory strategies can consistently trigger this and lead to RCE.

The advisory lists several ways a request can reach an out-of-memory condition while appearing to stay within normal limits, mostly around multipart form parsing: requests without a usable declared content length, parts with an unrestricted number of headers, empty file fields that do not count toward max_file_uploads, and deeply nested field names. Application-specific paths can also exhaust memory.

Exposure depends on how PHP is run. The advisory says Apache mod_php always runs the shutdown step even when request startup failed, and that the problem can occur before any application code runs. FrankenPHP is likely susceptible by source analysis. PHP-FPM exits the affected child when startup fails, but the advisory says source analysis still supports FPM as susceptible, with no complete FPM exploit demonstrated. LSAPI is described as modeled on FPM, with application-specific exploits likely but unvalidated.

CVE-2026-109619: stale global state

Here, PHP keeps global state such as error, session and object state that points into memory owned by a single request. If that state is not reset before the memory is freed, a later request handled by the same worker can use it, a use-after-free. The advisory says the demonstrated producing and consuming steps happen in different HTTP requests handled by the same worker, and that a crafted heap layout can produce full RCE.

The advisory notes that changing error_reporting, using the @ operator, or turning off display_errors or log_errors does not protect against this. It also says reachability differs by setup: with Apache mod_php, .htaccess and php_value or php_flag directory configuration is applied early enough to matter, while FPM is conditionally exposed when the frontend passes PHP_VALUE or PHP_ADMIN_VALUE parameters that cause an early diagnostic.

Who is realistically exposed

• Any server running PHP 8.2, 8.3, 8.4 or 8.5 below the fixed versions listed above. The advisories do not say whether other branches are affected, so check your version against the vendor pages.
• WordPress sites: Wordfence states that updating WordPress will not fix these flaws. PHP itself must be updated and restarted.
• Sites on Apache with mod_php, and FrankenPHP deployments, which the advisory identifies as the clearest candidates for application-independent attacks.
• Shared and managed hosting customers, where your host controls the PHP version. You may need to ask the provider or switch versions in the control panel.

How to check your exposure

1. Find your PHP version. Run php -v on the server, check the hosting control panel, or look at a phpinfo page restricted to administrators. In WordPress, Tools, Site Health, Info shows the server PHP version.
2. Compare it to the fixed releases: 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or later in the same branch). Anything lower in these branches is vulnerable.
3. Identify how PHP runs: Apache mod_php, PHP-FPM, FrankenPHP or LSAPI. This tells you which advisory notes apply to you.
4. Check packaged builds. Linux distributions and hosting vendors may backport fixes without changing the upstream version number, so consult your vendor's security notice if the version looks old.
5. Look for oddities in web server logs around and after October 21: unusually large or malformed multipart POST requests, repeated PHP worker crashes or out-of-memory restarts, and unexpected new files in web directories.

What to do now

1. Update PHP to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer. The advisory states that updating to a patched release is the only complete mitigation.
2. Restart every PHP worker and the web server after updating, so running processes load the patched code.
3. Verify afterwards that the running version is the new one, not just the installed package.
4. If you cannot update immediately, the advisory names memory_limit=-1 as the primary configuration mitigation, enforced administratively. It also warns this is not complete, because a failing underlying allocation can still reach the vulnerable path, and that no pool, directory or application setting should restore a finite limit. Weigh this carefully, since removing the memory cap has its own stability risk.
5. Keep post_max_size conservative, enforce request body size at your frontend, lower max_input_nesting_level, and bound input variables, multipart parts, headers per part and uploads. If your application does not use multipart forms, block such requests before they reach PHP.
6. Do not use RLIMIT_AS or RLIMIT_DATA as a memory control, because the advisory says they cause mmap() to fail and trigger the vulnerable path. Container or cgroup limits are not a complete mitigation either.
7. Review the related CVE-2026-109619 guidance in the second advisory as well.

Detection and monitoring afterwards

Once patched, look for changed or unfamiliar PHP files, new administrator accounts, unexpected scheduled tasks and outbound connections from the web server. Our guides on checking if a website is hacked and what to do if your website is hacked walk through this. A free malware scanner can give an outside view of visible problems, though an outside-in check cannot see everything on the server, as explained in what outside-in malware detection can and cannot see.

Keep watching for further PHP point releases, since the advisories say exact affected configurations depend on internal state and details may evolve. For WordPress owners, the WordPress security checklist covers keeping the runtime, core and plugins current. You can follow other security news on the Webforta blog.

Key facts at a glance

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

• RCE via OOM corruption (github.com)
• Known Exploited Vulnerabilities Catalog | CISA (cisa.gov)
• RCE via stale global state (github.com)
• Known Exploited Vulnerabilities Catalog | CISA (cisa.gov)
• PHP Memory Corruption Vulnerability (CVE-2026-109618) is being actively exploited (nvd.nist.gov, 26 October 2026)
• Attacks on PHP2Shell Continue, But No Known Compromises as a Result Yet (wordfence.com, 22 October 2026)
• Why It’s Urgent to Update PHP on Your WordPress Site: Two Critical PHP Vulnerabilities and What Our Testing Found (wordfence.com, 22 October 2026)

Tags: PHP, CVE-2026-109618, RCE, CISA KEV, WordPress