What Are CVE-2026-109618 and CVE-2026-109619? PHP Flaws Explained

CVE-2026-109618 and CVE-2026-109619 are two critical PHP flaws that can let an attacker run code on a web server without logging in. Both are being exploited, and the fix is a PHP update, not a plugin or theme update.

In plain English

PHP is the programming language that runs a large share of the web, including every WordPress site. When someone visits a PHP site, the web server hands the request to PHP, PHP builds the page and sends it back. On a busy server the same PHP worker process handles many visitors’ requests one after another.

These two flaws are in how PHP cleans up after a request goes wrong:

• CVE-2026-109618 happens when PHP runs out of the memory it is allowed for a request. PHP abandons the request in a hurry, and some of its internal bookkeeping is left half-built. When PHP then tidies up, it reads that broken data.
• CVE-2026-109619 happens when internal settings that should be wiped at the end of a request still point to memory that has already been freed. The next request on the same worker can trip over that stale pointer.

Both are memory-safety bugs. With careful, repeated attempts, an attacker can turn them into running their own commands on the server, with the same permissions as the web server. From there they could read your database, change your site or use the server to attack others.

Who is at risk? Anyone running PHP that serves web pages: company websites, WordPress and WooCommerce stores, customer portals, intranets, and appliances or software with PHP built in. The attacker doesn’t need an account or any help from a user. They do need to send specially shaped web requests, often many of them.

Who is affected?

The PHP security advisory and the two GitHub advisories (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp) list the same affected and fixed versions for both CVEs:

Which server set-ups? PHP says all installations serving web requests are at risk, including Apache with the built-in PHP module (mod_php), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The risk is not equal:

• Apache with mod_php is rated highest risk. PHP confirmed full remote code execution against it over HTTP with default memory and input limits.
• PHP-FPM (common behind nginx and on most modern hosts) is susceptible according to PHP’s source analysis, but for CVE-2026-109618 no complete exploit had been demonstrated against it when the advisory was published. The CVE-2026-109619 session upload progress path was validated against both mod_php and PHP-FPM.

End-of-life branches. PHP 8.1 and older no longer get releases from the PHP project. Because of the severity, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves. Otherwise, your options are a distribution or long-term-support vendor that backports the fix, or upgrading to a supported branch. PHP 8.2 itself reaches end of life on 31 December 2026.

Hosting and managed WordPress. If you’re on shared hosting or a managed WordPress plan, your host controls PHP. Many will have patched already, but you should confirm rather than assume. Ask them directly which PHP build you’re running and whether it includes the fixes for both CVEs.

Distribution backports change the version string. Linux distributions often patch their own PHP packages without moving to the new upstream version. For example, Ubuntu lists the fix for 24.04 LTS as package 8.3.6-0ubuntu0.24.04.13, and for 22.04 LTS as 8.1.2-1ubuntu2.28. Running php -v on those servers shows 8.3.6 or 8.1.2, which looks vulnerable but isn’t once the package is updated. Debian shipped 8.2.35-1~deb12u1 for bookworm and 8.4.27-1~deb13u1 for trixie. Red Hat’s bulletin RHSB-2026-013 covers RHEL 7 to 10 (on RHEL 7 only CVE-2026-109619 applies) and says fixes are being expedited. Alpine tracks the php82 to php85 packages. The package version, not the PHP version, is what counts.

Technical analysis

Both flaws sit in the PHP core request lifecycle, not in an optional extension. The PHP changelog entry for the fix reads "Avoid state corruption via bailout" (PHP 8 ChangeLog).

CVE-2026-109618: out-of-memory corruption. PHP uses longjmp() to bail out of the current context when a request hits its memory limit. According to the advisory and the NVD record, some code paths make request memory reachable before it is fully initialised. If an allocation fails at that moment, request shutdown later reads or branches on invalid memory. The advisory describes several ways an attacker can force the out-of-memory condition from outside, mostly through how multipart form bodies and uploads are parsed. On mod_php this can happen during automatic body parsing, before any application code runs, which is why it is application-independent there. PHP-FPM exits the child process when startup fails, which narrows exposure to out-of-memory conditions after normal startup.

CVE-2026-109619: stale global state. PHP keeps some global state (error, session, object and extension state) that temporarily points into per-request memory. In some cases it isn’t reset, or is filled again after being reset. A later request on the same worker can then read it before it’s reinitialised, which is a heap use-after-free (advisory, NVD). Exploitation needs a "producer" request that leaves the state behind and a "consumer" operation on the same worker. Fatal errors, including out-of-memory errors and execution timeouts, can be producers. Paths PHP names include session upload progress (on by default, and it doesn’t require the application to call session_start()), fatal error backtraces on PHP 8.5, and early INI diagnostics from .htaccess or server-level php_value settings. Hiding errors with error_reporting, display_errors or @ does not prevent it.

Scores, and why they differ. PHP, as the CVE numbering authority, scored both at CVSS v4.0 9.2 (Critical):

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

NVD’s own CVSS v3.1 scores differ: 9.8 for CVE-2026-109618 (it rated attack complexity Low) and 8.1 for CVE-2026-109619 (attack complexity High). Red Hat scores CVE-2026-109618 at 8.1 and rates the issue Important, noting that RHEL 8 and later default to PHP-FPM, where exploitation is "difficult in practice". The disagreement is about how hard exploitation is, not whether the impact is serious.

A third, related issue. On 23 October 2026 PHP published an informational advisory for CVE-2026-115560, another session upload progress path that needs an uncommon combination of configuration and application behaviour (changing session.serialize_handler at runtime). The October releases don’t fix it; PHP said the full advisory would come with the next release and suggested session.upload_progress.enabled=0 in the meantime.

Is it being exploited?

Yes. As of 3 November 2026:

• CISA KEV: CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October 2026, with a 29 October due date for US federal agencies. Known ransomware use is listed as "Unknown". CISA’s alert (21 October, revised 26 October) urges immediate patching.
• National CERTs: The Canadian Centre for Cyber Security’s AL26-026 noted open-source reporting of exploitation in its 26 October update. The Netherlands NCSC keeps a product status tracker for software that bundles PHP. In Australia, the ASD’s ACSC published a Critical alert ahead of the release.
• Observed traffic: TU Delft’s php2shell observatory recorded 84,209 exploitation requests from 795 IP addresses in 74 countries between 21 October and 3 November 2026, and saw requests resembling the attack before the fixed releases were published.
• Proof of concept: Several proof-of-concept repositories and scanners are circulating. Most have not been independently confirmed.

What is not publicly known: how many sites have actually been compromised, and whether specific criminal groups are behind the traffic.

How to fix it

1. Find your PHP version safely. On the server, run php -v (and php-fpm -v or your FPM binary, which can differ from the command-line PHP). On a Debian or Ubuntu server, check the package with dpkg -l | grep php; on RHEL-family systems use rpm -qa | grep php. On shared hosting, look in your hosting control panel’s PHP settings or ask the host. If you must use a phpinfo() page, create it with a random file name, read it, and delete it straight away. Never leave it public. Check: you know the PHP branch and, for distribution packages, the exact package version for every site, including staging and old sites.

2. Upgrade to a fixed release or the patched package. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, or install your distribution’s security update (for example, Debian DSA-6574-1 or DLA-4848-1, Ubuntu USN-8948-1). Don’t forget containers and appliances: rebuild images from updated base images, and check vendors for products that bundle PHP. Check: the version or package matches the fixed version in the PHP or distribution advisory.

3. Restart PHP, not just reload. Restart PHP-FPM and the web server (Apache, if you use mod_php) so every worker loads the new code. Long-running workers keep running the old binary until they are restarted. Check: worker processes have a start time after the update.

4. Confirm from the outside. Load the site and check the PHP version reported by the web-serving SAPI (not just the command line). Then remove any temporary phpinfo() file. Check: the site works, and the reported version or package is the patched one.

5. If you can’t update today, apply PHP’s interim settings. PHP lists these, applied in php.ini, the FPM pool or server configuration (for example php_admin_value) so applications can’t override them, followed by a restart of every worker:

   • For CVE-2026-109618: memory_limit = -1; post_max_size = 8M (or 32M if uploads are needed), with upload_max_filesize below post_max_size. Don’t use RLIMIT_AS or RLIMIT_DATA instead, as these can cause the very allocation failure involved.
   • For CVE-2026-109619: session.upload_progress.enabled = 0 (not via ini_set() or a .user.ini file), and on PHP 8.5 fatal_error_backtraces = 0.

   Removing the memory limit lets one request use much more memory, so set a container or service memory boundary and watch for resource exhaustion. PHP is clear that these measures "do not make an installation safe". Check: a fresh phpinfo() (then deleted) or php -i for the same SAPI shows the new values, and the site still works.

6. Deal with end-of-life PHP. On 8.1 or older, use a supported vendor’s backported package or upgrade to a supported branch. CISA advises taking unpatchable or unsupported systems offline. Plan the move off 8.2 before 31 December 2026, too. Check: no internet-facing system runs an unpatched, unsupported PHP.

7. Look for signs of compromise. Because exploitation began around the release date, patching alone doesn’t prove you weren’t hit. Review web and PHP logs from mid-October onwards, and look for PHP workers launching shells, unexpected files in the web root, new admin accounts or odd outbound connections. Check: anything unexplained is investigated, not just deleted.

What this means for WordPress sites

• The fix is a PHP fix. WordPress core, plugins and themes run on PHP, so they don’t carry these bugs and updating them won’t remove them. On managed WordPress, ask your host to confirm the PHP version or package and the date it was applied.
• Plugins can make it easier. Plugins that accept uploads or large forms, or that trigger memory-heavy or slow operations, give attackers more ways to cause the memory and timeout errors these flaws depend on. Keep them updated and remove ones you don’t use.
• Test the upgrade on staging. If you’re moving from 8.1 or 8.2 to a newer branch, test on a staging copy first, because older plugins may not support newer PHP. A patch release within your current branch (for example 8.3.x to 8.3.36) is much lower risk.
• Check the upload progress setting. WordPress doesn’t rely on PHP’s native session upload progress. Disabling it is a sensible hardening step even after patching, as the Netherlands NCSC recommends, but test any plugin that shows upload progress bars.

Key takeaways

• CVE-2026-109618 (out-of-memory corruption) and CVE-2026-109619 (stale global state) are critical PHP core flaws allowing unauthenticated code execution, rated CVSS v4.0 9.2 by PHP.
• Both are listed as exploited by CISA since 26 October 2026, so treat this as urgent rather than routine.
• The fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package, followed by a full restart of PHP workers.
• Distribution version strings can look old even when patched. Check the package against the distribution’s advisory.
• Interim settings only narrow the attack paths. Unsupported PHP 8.1 and older needs a vendor backport, an upgrade or to come off the internet.

Sources

• PHP security advisory and release announcements, 20 to 23 October 2026: php.net
• PHP 8 ChangeLog: php.net/ChangeLog-8.php
• PHP advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618): github.com/php/php-src
• PHP advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): github.com/php/php-src
• NVD: CVE-2026-109618 and CVE-2026-109619
• CISA alert, 21 October 2026: cisa.gov
• CISA Known Exploited Vulnerabilities catalog: cisa.gov
• ASD’s ACSC alert: cyber.gov.au
• Canadian Centre for Cyber Security AL26-026: cyber.gc.ca
• Netherlands NCSC php2shell tracker: github.com/NCSC-NL
• TU Delft php2shell observatory: php2shell.delftintellab.com
• Distribution trackers: Debian, Ubuntu, Red Hat RHSB-2026-013, Alpine