Free trial
EN

News Updated on

Vulnerabilities and patches · Magento 2 · WordPress

Critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619): update your Magento store or WordPress site

On 21 October 2026, PHP fixed two critical vulnerabilities that allow anyone to take over a server without an account. Every Magento store and every WordPress site runs on PHP. Here is how to tell whether you are affected and what to do today.

Cédric Michel, Magento developer Adobe certified Published on Updated on 9 min read
Illustration: the red Tocsin24 bell rings above a server, in front of which a cracked blue shield is being patched.
Critical · 9.2 / 10 CVE-2026-109618 · CVE-2026-109619 Fixed on 21 October 2026
Impact
Server takeover Remote code execution, no account needed.
Who is affected
Any site running on PHP Magento and WordPress included, if PHP is not up to date.
Fixed versions
8.2.358.3.368.4.278.5.12 No official release for PHP 8.1 and older.
Exploitation
First proofs of concept published According to CERT-EU, attacks are likely already happening.

In short

  • Both vulnerabilities affect PHP itself, not Magento or WordPress. A security extension cannot block them.
  • The only real protection is to update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, depending on your branch, or to your distribution’s fixed package.
  • PHP 8.1 and older have no official fixed release. Some distributions publish their own fix. Stores on Magento 2.4.4 and 2.4.5 are in this situation.
  • After the update, PHP must be restarted, otherwise the old version may keep running.
Contents

What is happening, in plain words

PHP is the language Magento and WordPress are written in. Your store’s server uses it for every page view. On 20 October, the PHP team announced a critical security release, published the next day with the details of the two vulnerabilities.

An attacker can send your site crafted requests that trigger an internal PHP error, then use it to run their own code on the server. They do not need an account. They could then read the database, change files or install malware.

The problem happens while PHP reads the request, before Magento or WordPress even start. A security extension installed in your store sees nothing.

For developers

CVE-2026-109618 (“RCE via OOM corruption”, GHSA-w8hw-w9fx-j79w). An out-of-memory error interrupts PHP while request data is only partially initialized. Request cleanup then treats it as valid. Exploitation is confirmed on Apache with mod_php. PHP-FPM, FrankenPHP and LSAPI are considered likely vulnerable based on code analysis.

CVE-2026-109619 (“RCE via stale global state”, GHSA-6wmf-4rv5-p3rp). Internal state owned by a request survives after its memory is freed, and a later request handled by the same worker uses it (use-after-free). Cases have been validated on both mod_php and PHP-FPM.

The PHP team considers the risk highest with mod_php, but treats every installation serving web requests as exposed: PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. Scores: 9.2 out of 10 in CVSS 4.0 for both according to PHP; the NVD rates them 9.8 (CVE-2026-109618) and 8.1 (CVE-2026-109619) in CVSS 3.1.

Is your store or site affected?

Yes, if its PHP version is older than the fixed version of its branch. The branch is the start of the number: 8.2, 8.3, 8.4 or 8.5.

PHP branch Vulnerable if the version is… Fixed version
8.5 older than 8.5.12 8.5.12
8.4 older than 8.4.27 8.4.27
8.3 older than 8.3.36 8.3.36
8.2 older than 8.2.35 8.2.35 (last year of support: ends 31 December 2026)
8.1 and older all No official release (branches no longer maintained by PHP; minimal patches published for 7.4, 8.0 and 8.1, and fixed packages from some distributions)

Source: PHP security announcements of 21 October 2026.

This table applies to PHP built from the official sources. Linux distributions sometimes fix PHP without changing its number: on Ubuntu, PHP 8.3.6 can be fixed. See the server section.

What it means for Magento stores

Each Magento version only works with certain PHP branches. Your Magento version therefore decides what you can install.

Magento / Adobe Commerce Compatible PHP What to do
2.4.9 8.5 Move to PHP 8.5.12
2.4.8 8.4, 8.3 Move to PHP 8.4.27 or 8.3.36
2.4.7 8.3, 8.2 Move to PHP 8.3.36 or 8.2.35
2.4.6 8.2, 8.1 Move to PHP 8.2.35. On PHP 8.1, only a fix from your distribution or an extended support vendor protects you.
2.4.5 and 2.4.4 8.1 only No official fixed PHP release is compatible. Ask for a PHP 8.1 fixed by your distribution (Ubuntu 22.04 provides one) and plan a Magento upgrade.

Compatibility based on Adobe’s published system requirements.

For WordPress, updating PHP within the same branch (for example from 8.3.30 to 8.3.36) changes nothing for the site. Moving to another branch, however, means checking that your plugins and theme are compatible.

Find your PHP version

  • WordPress: in the dashboard, Tools, Site Health, Info tab, Server section.
  • Magento: the admin panel does not show it. Check your hosting control panel, or ask your hosting provider or agency.
  • Tocsin24 shows it for every site, along with the status of its branch (see below).

What to do now

  1. Ask for the PHP update from your hosting provider or agency, today. Linux distributions and extended support vendors received the patches before publication.
  2. Have them confirm that the new version is actually running: PHP must be restarted after the update.
  3. On PHP 8.1 or older: ask whether your hosting provider offers a backported fix, and plan the upgrade. For Magento 2.4.4 and 2.4.5, you need a newer version of Magento.
  4. If the update cannot be done quickly, CERT-EU recommends considering taking the site offline in the meantime. Temporary settings reduce the risk (see below), but they do not fully protect you.
  5. After the update, look for signs of intrusion: new admin accounts, unknown PHP files, changed files. The update closes the door, but it does not remove someone who may already be inside.
Message to your hosting provider or agency

Hello,

On 21 October 2026, PHP released a critical security update (CVE-2026-109618 and CVE-2026-109619).

Could you update PHP on our site’s server to the fixed version of its branch (8.2.35, 8.3.36, 8.4.27 or 8.5.12, or the distribution’s fixed package), restart PHP and confirm the version now running?

If our site runs PHP 8.1 or older, could you tell us what solution you offer?

Thank you.

You manage the server: update PHP on Debian or Ubuntu

Debian and Ubuntu have published fixed packages for their own PHP version:

System Package Fixed version Advisory
Debian 13 (trixie) php8.4 8.4.27-1~deb13u1 DSA-6574-1
Debian 12 (bookworm) php8.2 8.2.35-1~deb12u1 DLA-4848-1
Ubuntu 26.04 LTS php8.5 8.5.4-0ubuntu1.5 USN-8948-1
Ubuntu 24.04 LTS php8.3 8.3.6-0ubuntu0.24.04.13 USN-8948-1
Ubuntu 22.04 LTS php8.1 8.1.2-1ubuntu2.28 USN-8948-1

For Ubuntu 20.04 and older, the fixes come with an Ubuntu Pro subscription (USN-8948-2).

  1. Install the updates:

    Terminal
    sudo apt update sudo apt upgrade

  2. Check the installed version. Replace 8.2 with your branch (8.4 on Debian 13, 8.3 on Ubuntu 24.04):

    Terminal
    apt-cache policy php8.2-fpm dpkg -l | grep php

    The Installed line must show the fixed version from the table, for example 8.2.35-1~deb12u1 on Debian 12.

  3. Restart PHP: PHP-FPM, or Apache if it uses mod_php. The package often does it by itself, but a PHP that has not restarted keeps running the old version:

    Terminal
    PHP-FPM (adjust the branch number) sudo systemctl restart php8.2-fpm Apache with mod_php sudo systemctl restart apache2

Temporary settings, if you cannot update right away

The PHP team and CERT-EU are clear: these settings reduce exposure, but do not make the server safe. Put them in the php.ini that serves the site, or in the PHP-FPM pool configuration, never through ini_set() or a .user.ini file. On Debian and Ubuntu, the PHP-FPM php.ini is in /etc/php/<branch>/fpm/, and the one for Apache with mod_php in /etc/php/<branch>/apache2/. Then restart every PHP process.

Content of /etc/php/8.2/fpm/php.ini
  1. session.upload_progress.enabled = 0
  2. post_max_size = 32M
  3. upload_max_filesize = 16M

What each line means:

  • session.upload_progress.enabled Turns off session upload progress, one of the confirmed attack paths. It is on by default. The PHP team advises keeping it off even after the update if you do not use it.
  • post_max_size 8M if the site receives no files, 32M otherwise. Check that image uploads in the admin panel still work.
  • upload_max_filesize Always smaller than post_max_size.

On PHP 8.5, also add fatal_error_backtraces = 0.

The official advisories also mention memory_limit = -1. On a Magento store, removing the memory limit can overload the server: only apply it if you know what you are doing. Do not use the RLIMIT_AS or RLIMIT_DATA limits instead, as they trigger the very flaw.

Tocsin24 shows the PHP version of each of your sites

On each site’s Vulnerabilities page, Tocsin24 shows the PHP version that serves the site: the Magento module and the WordPress plugin read it from the PHP that answers web requests (PHP-FPM or Apache), not from the command line. It is recorded at every site check, hourly by default, along with the status of its branch and the latest release when yours is behind. After the update, the new version shows up at the next check.

Tocsin24 does not yet track PHP vulnerabilities one by one: it does not say “exposed to CVE-2026-109618”. Compare the version shown with the table in this article. The list of latest PHP releases is refreshed once a week, and on Ubuntu the number stays the same even when the package is fixed: in that case, rely on the package version. Tocsin24 also watches for new admin accounts and file integrity, the first signs of an intrusion.

Try it for free See Magento 2 monitoring

PHP

8.2.35

Correctifs de sécurité seulement, jusqu’au 31 décembre 2026

Version corrigée

PHP

8.3.30

Correctifs de sécurité seulement, jusqu’au 31 décembre 2027

Mise à jour disponible : PHP 8.3.36

À mettre à jour

PHP

8.1.34

Plus maintenue depuis le 31 décembre 2025 : aucune faille n’est plus corrigée

Branche à changer

Carte PHP de la page Failles, pour trois serveurs d’exemple. Les étiquettes de couleur sont ajoutées pour l’article.

Application screens with example values.

Frequently asked questions

Will my hosting provider update PHP on its own?

On shared or managed hosting, often yes, but not always on the same day, and the restart is not always done. Ask them to confirm the version now running. On a server you manage, it is up to you.

Does my firewall or security extension protect me?

A Magento or WordPress security extension does not: the flaw triggers before it runs. A firewall in front of the server can reduce the risk if it limits the size and shape of requests, but only updating PHP fixes the flaw.

Can the PHP update break my store?

Staying within the same branch (for example from 8.3.30 to 8.3.36) only brings fixes, and the risk is low. Changing branch (from 8.1 to 8.2) requires testing and, for Magento, a compatible version.

After updating on Ubuntu, php -v still says 8.3.6. Is that normal?

Yes. Ubuntu patches its packages without changing the PHP version number. Check the package version instead with apt-cache policy php8.3-fpm: on Ubuntu 24.04 it must be 8.3.6-0ubuntu0.24.04.13 or newer.

How do I know whether someone has already exploited the flaw?

Look for the usual signs of intrusion: unknown admin accounts, PHP files you did not create, changed site files, unknown scheduled tasks. If in doubt, call in a specialist before deleting anything.

Portrait of Cédric Michel

Cédric Michel

Cédric has been building Magento stores for 18 years and holds the Adobe Commerce Developer Expert certification. He created Tocsin24 to monitor the security and health of Magento 2 stores and WordPress sites.

Adobe Commerce Developer Expert badge Adobe Commerce Developer Expert
Verify the certification on Adobe’s website

Sources

  1. PHP: announcements of 20 and 21 October 2026
  2. PHP: advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
  3. PHP: advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
  4. CERT-EU: security advisory 2026-018 (version 1.1)
  5. NVD: CVE-2026-109618
  6. NVD: CVE-2026-109619
  7. Debian: security tracker for CVE-2026-109618
  8. Ubuntu: notice USN-8948-1
  9. Ubuntu: notice USN-8948-2 (Ubuntu 20.04 and older)
  10. Adobe Commerce: system requirements