PHP Critical Vulnerability CVE-2026-109618 and CVE-2026-109619 Explained for Website Owners

Short answer: On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. If your website runs on PHP (WordPress, Joomla, Drupal, Magento, Laravel or custom code), the fix has to come from the PHP version on your server, not from your CMS. Ask your host or IT provider today which PHP build you are running and whether it includes the fix. This article reflects what was published as of 2026-10-25.

What happened, in plain English

PHP is the programming language that runs a very large share of websites. When a visitor loads a page, a PHP "worker" on the server builds that page. Two separate bugs were found in how PHP handles its own internal memory while processing a web request.

The PHP project published the details on php.net on 21 October 2026, in an advisory titled "Security advisory: Critical remote code execution vulnerabilities, update now". It says the two flaws can allow unauthenticated remote code execution, and that all PHP users are strongly encouraged to update immediately.

CVE-2026-109618: memory corruption after an out-of-memory event

The advisory describes this one as remote code execution via out-of-memory (OOM) corruption. When the server runs out of memory at a bad moment, PHP can be interrupted while the data describing the current request is only half set up. Later, the cleanup step may treat that half-built data as if it were valid. That mismatch is what an attacker could try to abuse.

CVE-2026-109619: stale state left over between requests

The advisory describes this one as remote code execution via stale global state. Some request-owned internal data can survive after the memory behind it has been freed. A later request handled by the same worker may then use that stale data before PHP resets it normally.

You do not need to follow the memory details. The practical point is that both bugs sit in the PHP engine, below your website code.

What "unauthenticated RCE" actually means

The phrase sounds technical, but each word matters for your risk.

Term	Plain meaning
Unauthenticated	The attacker does not need a username, password or any account on your site.
Remote	The attacker can attempt it over the internet, without physical or local access.
Code execution	The attacker can try to make your server run commands of their choosing, not just read a page.
CVSS 9.2	A severity score out of 10, in the critical range, assigned by the PHP project using the v4.0 scale.

Put together, "unauthenticated RCE" is the category defenders worry about most, because it removes the usual barrier of a login. That is why the PHP project asked everyone to update. It does not mean every site has been or will be attacked.

Who is affected

According to the php.net advisory, all PHP installations that serve web requests are at risk, and the risk is highest for mod_php (PHP running inside Apache). The advisory does not publish a precise affected version range, so do not assume that an older version is safe just because it is not listed.

That covers a long list of everyday software:

• WordPress and WooCommerce sites
• Joomla and Drupal sites
• Magento and other PHP stores
• Laravel, Symfony and other framework apps
• Custom PHP sites, client portals and old internal tools that still face the internet

If you run a static HTML site with no PHP on the server, this advisory does not apply to that site. If you are unsure, your hosting control panel normally shows the PHP version in use.

Why updating WordPress alone is not enough

This is the most common misunderstanding we expect to see. WordPress, a plugin or a theme is software written in PHP. PHP is the engine underneath. These flaws are in the engine.

Think of it as a car: updating the GPS app on your dashboard does not fix a defect in the engine. Updating WordPress core, plugins and themes remains good practice, and you should keep doing it, but it does not change which PHP build your server runs.

A web application firewall (WAF) or a security plugin may block some attack attempts and can be a useful extra layer. It is not a substitute for the PHP fix. The PHP advisory describes its configuration changes as partial mitigations, not a substitute for updating.

Timeline

Date	Event (source: php.net)
24 Sep 2026	Earlier routine security release: PHP 8.5.11, 8.4.26, 8.3.35 and 8.2.34. These do not contain the October fixes.
20 Oct 2026	"Upcoming Critical PHP Security Release" notice: two flaws rated CVSS v4.0 9.2, release set for 21 Oct at 14:00 UTC, no details yet.
21 Oct 2026	PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released, plus the security advisory with details. PHP 8.6.0 RC4 also carries the fixes.
23 Oct 2026	A separate, narrower informational advisory about session upload progress (CVE-2026-115560). It is a different issue and is not part of this article.

The practical lesson from the timeline: if your server last got a PHP update on or around 24 September, you are on the previous release and still need the October one.

Which versions to look for

Your PHP branch	Fixed in	Note
8.5	8.5.12	Security support until 31 Dec 2029
8.4	8.4.27	Security support until 31 Dec 2028
8.3	8.3.36	Security support until 31 Dec 2027
8.2	8.2.35	Security support ends 31 Dec 2026, plan an upgrade
8.1, 8.0, 7.4 and older	No upstream release	PHP published minimal source backports on GitHub for 7.4, 8.0 and 8.1. Hosts or Linux vendors may offer their own backports. Best path: move to a supported branch.

What to do today: 5 steps

Step 1: Find out what PHP your site runs

Log in to your hosting control panel (cPanel, Plesk, hPanel or similar) and look for "PHP version" or "Select PHP version". WordPress owners can also open Tools, then Site Health, then Info, then Server, and read the PHP version there. Write it down, including the full number such as 8.3.35.

Step 2: Ask your host, in writing, about the patch

On shared hosting you cannot compile or replace PHP yourself, because the host builds the packages. Send a short message asking: "Has the fix for CVE-2026-109618 and CVE-2026-109619 been applied to the PHP builds on my plan? Which version or package should I select?" Keep the reply.

Step 3: Select a fixed PHP branch if one is offered

Many panels let you choose the PHP branch per site. If your host has already published 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor-patched equivalent), pick a supported branch and test the site afterwards. If you are on 8.1 or older, this is also the moment to plan the move. Back up first.

Step 4: If you manage your own server, update PHP and restart workers

Install the fixed packages from your operating system vendor or from PHP directly, then restart PHP-FPM or Apache so every worker loads the new code. The PHP advisory also lists interim mitigations (for example disabling session upload progress in the php.ini or FPM configuration, setting a low post_max_size and enforcing request limits at the web server) and warns not to use RLIMIT_AS or RLIMIT_DATA to cap memory, because that can trigger the vulnerable condition. Treat these as a stopgap only, and read the advisory on php.net before changing settings.

Step 5: Back up, update the rest, and watch for oddities

Take a fresh backup stored away from the web server. See our guide to cloud backup for business and our cloud backup page. Then update WordPress core, plugins and themes, remove plugins you no longer use, and review admin accounts. Keep an eye out for unexpected files, new admin users, or sudden slowdowns. Our article on warning signs of a compromise and the cybersecurity overview can help you judge what you see.

If this feels like too much, our team can walk through it with you by remote repair, and the same approach applies to Windows-based office machines through Windows support. Our team can walk through either one with you in a remote session.

What is still unconfirmed

Information about this issue is still moving, so treat the following as things to re-check rather than facts.

• Exploitation in the wild. Some third-party outlets reported that security vendors saw early attack attempts around 20 and 21 October, and that a public exploit had not been seen at that time. These reports are not from php.net and may have changed since. Check current status from a trusted security source.
• Official listings. As of 20 to 21 October, third-party reporting said the issue was not on the CISA Known Exploited Vulnerabilities list. Verify that directly.
• The "PHP2Shell" nickname. Some outlets use it. It is not an official name from the PHP project.
• Your host's status. Whether your specific host has patched, and how, can only be confirmed by the host.
• Affected version range. php.net does not publish an explicit range, so we do not state one either.

Nothing here means a site is or is not compromised. Patching reduces risk but cannot guarantee that a site was never touched, so keep the monitoring habits above.

FAQ

What are CVE-2026-109618 and CVE-2026-109619?

They are two critical flaws in the PHP engine, fixed on 21 October 2026. The PHP project rated both CVSS v4.0 9.2 and says they can allow unauthenticated remote code execution.

Is my WordPress site affected?

If it runs on PHP that does not include the fix, it is exposed to the same PHP-level risk as any other PHP site. The flaw is not in WordPress itself, so the fix is a PHP update by your host or server administrator.

Will updating WordPress and plugins fix this?

No. Updating WordPress, themes and plugins is still worthwhile, but it does not change the PHP version on the server. You need a patched PHP build.

Which PHP versions contain the fix?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, plus PHP 8.6.0 RC4. PHP 8.1 and older have no upstream release; backports for 7.4, 8.0 and 8.1 were published on GitHub and some vendors may provide their own.

I am on shared hosting. What can I do?

You cannot patch PHP yourself. Ask your host in writing whether the fixed build is available, select a supported PHP branch in your control panel if offered, and keep your site backed up.

Does a higher version number always mean I am patched?

Not necessarily in both directions. Vendors sometimes backport fixes without changing the upstream version string, so check your host's or distribution's security bulletin rather than relying on the number alone.

Is PHP 8.2 still safe to use?

PHP 8.2.35 contains the fix, but according to php.net security support for 8.2 ends on 31 December 2026. Plan a move to 8.3 or newer.

Can a firewall or security plugin protect me instead?

It may block some attempts and is a helpful extra layer, but the PHP advisory says updating is the only complete remedy.