Two critical PHP vulnerabilities disclosed October 21 allow unauthenticated remote code execution on any server running PHP for web requests. CVE-2026-109618 and CVE-2026-109619 both carry CVSS v4.0 scores of 9.2.

The flaws sit in the PHP engine itself. Magento, WooCommerce, Shopware, and WordPress stores are affected even when their own code is clean.

One of them discloses server memory without requiring code execution at all. That memory holds passwords, session tokens, API keys, and TLS private keys from other requests.

What the Two PHP Vulnerabilities Actually Do

CVE-2026-109618 is an out-of-memory corruption bug. When an out-of-memory error interrupts a vulnerable operation, PHP leaves request data partially initialized.

CVE-2026-109619 is stale global state. PHP retains references to request data after the backing memory has been freed.

Researchers demonstrated unauthenticated RCE against current WordPress, Drupal, and Joomla container images. Sansec reports demonstrated attacks against Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony, and WHMCS as well.

Even a simple Hello World application on a vulnerable PHP version can be exploited.

Every reachable PHP endpoint on an affected server is at risk, including static forms, login routes, and health checks. The flaws are present across every PHP release in the 7.x and 8.x series.

Why Attacks Started Before the Patch

Calif found multiple RCE paths August 1 and reported the first bug to PHP August 11. Wiz Research reported independently on August 24.

Details leaked October 20, a day ahead of coordinated disclosure. Cloudflare reported early attacks the morning of October 21, before PHP released fixed versions at 14:00 UTC.

Amazon's Threat Intelligence team detected an exploitation attempt against its MadPot honeypot dating to October 17, four days before public disclosure.

Sansec updated its assessment October 22, noting mass exploitation appears less likely than expected on release day. That is not a reason to delay patching.

Which PHP Versions Are Fixed

Fixed releases: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

VulnCheck identified PHP on 2,608,039 internet-facing hosts, with more than 700,000 running versions from 3.x through 7.3. Those older installations have no patched release available.

Updating WordPress, a theme, or plugins does not fix this. The vulnerability is in PHP, not the application running on top of it.

Check your PHP version first. If you are on managed hosting, confirm your provider has patched rather than assuming it. GoDaddy patched Managed WordPress October 21 and was still waiting on vendor packages for Web Hosting and Windows Hosting as of October 22.

Why Patching Alone Does Not Close the Exposure

This is the part that matters most for anyone running a store on PHP.

The memory disclosure flaw works without code execution. An attacker could have read credentials out of PHP worker memory during the exposure window and left no backdoor behind.

That means a clean malware scan after patching does not establish that nothing was taken.

Rotate credentials that could have been in process memory: payment gateway API keys, marketplace and channel integration tokens, database credentials, admin passwords, SMTP credentials, shipping carrier API keys, and TLS private keys.

Sequence matters. Patch first, then rotate. Rotating before the vulnerability is closed means the new credential can be read the same way.

The Adobe Commerce StyleSmuggler incident in September established the same pattern on Magento specifically, where Adobe's guidance required rotating integration tokens, payment gateway credentials, and deployment secrets after patching.

Separately, stolen UpdraftCentral keys are being used to plant backdoors on WordPress sites. If you use UpdraftCentral, delete existing keys and create new ones.

What Amazon and Shopify Sellers Need to Check

If your entire operation runs on Amazon or Shopify, your storefront is not directly exposed. Both run on their own infrastructure.

Your exposure sits elsewhere. A WordPress blog or content site on the same hosting account. A Magento or WooCommerce store you still operate. Any self-hosted tool, dashboard, or integration running on PHP.

More importantly: any of those systems holding API credentials for your marketplace accounts. A compromised WordPress install with your Amazon SP-API tokens or Shopify private app keys in its configuration is a path into accounts that are otherwise secure.

Inventory every server you control that runs PHP, including staging environments and sites you forgot about. Check the version, patch it, then rotate anything those systems could reach.