PHP2Shell: What Shopware Shop Owners Need to Do About CVE-2026-109618 and CVE-2026-109619

PHP shipped emergency releases today: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two bugs in the PHP engine that let an attacker run code on the server without logging in. The researchers who found them call the pair PHP2Shell. PHP itself doesn’t use the name, but everyone else does, so I’ll stick with it.

If you run a Shopware shop, the short version is: your shop code doesn’t matter here. According to Huntress and the PHP advisories, a single unauthenticated request can trigger the attack before any application code runs. Updating Shopware or a plugin does nothing. Updating PHP does.

Status: 21 October 2026, evening. This is moving fast, and several sources still contradict each other. Where they do, I say so.

What happened

Researchers at Calif, Wiz and OpenAI found and reported the bugs. Calif sent PHP its first report on 11 August and a working RCE proof of concept on 14 August, Wiz reported on 24 August. Wiz says AI models (it names Gemini 4 Argon and GPT-5.6 Sol) helped it find the vulnerability and build the exploit. Details leaked online on 20 October. According to Huntress, it started with a Hacker News post that was taken down, but not before screenshots spread. PHP published an advance notice the same day and released the fix on 21 October at 14:00 UTC, one day earlier than the original embargo.

Both CVEs are rated 9.2 on CVSS v4.0. (The leak claimed 10.0. That number didn’t come from PHP.)

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), “RCE via OOM corruption”. When PHP runs out of memory while setting up a request, it can abort with part of the request data still uninitialised. The shutdown at the end of the request then reads that invalid data.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), “RCE via stale global state”. State that belongs to one request survives after its memory is freed, and a later request on the same worker uses it before PHP resets it. The advisory confirms two paths: session upload progress, and on PHP 8.5 the fatal error backtraces.

Wiz describes all of them as memory-safety bugs in how PHP handles fatal errors during a request, especially out-of-memory errors. It also says they let an attacker read process memory without achieving code execution, “including passwords, tokens, and API keys”.

Who is affected

PHP’s advisory names “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed”, and considers the risk highest for mod_php. Calif says the earliest affected code path dates to PHP 5.4.0 and is exploitable under default configuration. Wiz says even a plain “Hello World” application on an affected PHP version can be vulnerable.

On PHP-FPM the sources are less clear-cut. The GHSA for the OOM bug says FPM is susceptible based on source analysis, but “no complete FPM exploit has been demonstrated”. The stale-state bug was validated against both mod_php and FPM, and Calif’s demo video shows the exploit running against nginx with PHP-FPM.

Calif confirmed pre-auth RCE against Magento 2.4.9 and other PHP applications, and Sansec lists WordPress, Drupal, Joomla, Nextcloud, Laravel 13.11 and Symfony 8.1 among them. Shopware isn’t on the list. Sansec’s assessment: “The flaws are in the PHP engine, so Magento, Shopware and WooCommerce stores are exposed even when their own code is clean.”

What to update to

Branch	Fixed in
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

PHP 8.1 and older don’t get official releases. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1 as branches in php-src, but that’s source code, not a package you can install. Shopware 6.5 runs on PHP 8.1, so a 6.5 shop on 8.1 has no packaged fix from PHP. And 8.2 itself reaches end of life on 31 December 2026.

How you get the update depends on where PHP comes from:

• Distribution packages. Linux distributions and LTS vendors received the patches in advance. They backport fixes into the version they ship, so the version string can still look old. The Hacker News, following Debian’s advice, recommends checking the package changelog for the CVE number rather than the version. On Debian or Ubuntu that’s apt changelog <package> | grep CVE-2026-109618, for example with php8.3-fpm.
• Remi’s repository (rpms.remirepo.net) had no updated packages on 21 October, according to Sansec and Huntress.
• Docker images and managed or shared hosting. You need a build that contains the fix. Ask your host when it lands, and check the version yourself afterwards.

Whatever the route, restart PHP-FPM (or Apache) afterwards and check the version on the process that serves traffic. The Hacker News makes the point that php -i on the shell shows the CLI binary, not necessarily what FPM runs. A phpinfo() page that you delete right afterwards settles it.

If you can’t update today

None of the following replaces the update. PHP’s core developers were blunt about it: “the only mitigation is patching / upgrading PHP” (Gina Peter Banyard), “ini settings won’t save you” (Joe Ferguson, release manager). The GHSAs still list partial hardening for systems that can’t be updated right away.

For the stale-state bug, switch off session upload progress in php.ini or the FPM pool config and restart every worker. According to the advisory it’s enabled by default and doesn’t need session_start(). On PHP 8.5, also set fatal_error_backtraces=0. The advisory says not to rely on ini_set() or an FPM .user.ini for this.

; php.ini or FPM pool (php_admin_value[...])
session.upload_progress.enabled = 0
; PHP 8.5 only
fatal_error_backtraces = 0

For the out-of-memory bug, PHP suggests memory_limit=-1, preferably as php_admin_value, and checking that no pool, directory or application setting restores a finite limit. Add tight request size limits: post_max_size = 32M if you need uploads, 8M if not, with upload_max_filesize below post_max_size. Keep in mind that memory_limit=-1 removes PHP’s per-request memory cap entirely.

Cloudflare has pushed emergency rules into its Managed Ruleset, available to all customers including the free plan, according to its CTO Dane Knecht. Cloudflare itself calls them “a STOPGAP only”, and they only cover traffic that goes through Cloudflare, so the origin must not be reachable around it. Blocking multipart/form-data at the web server cuts off a suspected attack path, but Sansec points out it breaks file uploads.

If none of that is possible, CERT-EU suggests isolating internet-facing applications from public networks until a fix can be applied, and the UK NCSC suggests taking unpatched systems offline. Sansec notes that the maintenance modes in Magento and WordPress don’t help.

Was I already hit?

Nobody has published reliable indicators of compromise yet. Wiz suggests looking for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies in responses, and unexplained PHP worker churn. Huntress recommends watching for suspicious child processes spawned by php-fpm, php-cgi, httpd or apache2. The GHSA warns that the absence of log entries is not proof of safety.

As of this evening, nobody had confirmed a successful break-in. Cloudflare says it is seeing early attacks, watchTowr says its honeypots observed exploitation, and Huntress had not seen any across its partner base as of 10am ET. Before the release, The Hacker News wrote that the public exploit code going around had not been shown to work. Sansec expects mass exploitation now that the write-ups are public.

Because of the memory disclosure Wiz describes, credentials can leave the server without a single file being touched. If your shop was exposed and you see anything from the list above, rotate what the PHP process had access to after patching: DATABASE_URL and APP_SECRET from .env or .env.local, and the API keys of your payment provider and other integrations.

Sources: PHP security advisory, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, Calif, Wiz, Sansec, Huntress, The Hacker News (before release), The Hacker News (after release), Help Net Security, Cloudflare changelog, Shopware 6.5 to 6.6 update guide.