PHP security release, October 21, 2026: what Magento and WooCommerce stores should do

The October 21, 2026 PHP security release fixes CVE-2026-109618 and CVE-2026-109619 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; php.net rates both CVSS v4.0 9.2 and says they can allow unauthenticated remote code execution. PHP 8.1, 8.0 and 7.4 get no php.net release, only a source patch from PHP's security team that you build or a vendor packages, and Magento 2.4.4 and 2.4.5, which Adobe lists for PHP 8.1 only, are in that group. The one job: get every server onto the fixed version for its branch, or onto a patched build of its end-of-life branch.

This guide is for stores on PHP: Magento and Adobe Commerce first, WooCommerce and WordPress second, every other PHP store third. The catch php.net doesn't spell out is the version map: Adobe lists Magento 2.4.4 and 2.4.5 for PHP 8.1 only, and 8.1 reached end of life on December 31, 2025. Being current on Adobe's security patches doesn't change that: Adobe's lifecycle policy says it doesn't provide security fixes for PHP that reaches end of life, and Adobe had posted nothing on this release when we checked on October 21.

By the end you'll know which PHP every part of your store runs, which fix that branch got, who delivers it to you (php.net, your Linux distribution, your Docker image or your host), what to do in the first hour, and php.net's interim settings if you cannot update today.

Release status: CVE ids and fixed PHP versions#

Before the release: PHP's security team announced the release on October 20, 2026, first on the php.announce list, then in a php.net news item. What PHP confirmed:

• The release was scheduled for Wednesday, October 21, 2026 at 14:00 UTC (10:00 EDT, 07:00 PDT, 16:00 CEST).
• It addresses two vulnerabilities, both rated CVSS v4.0 9.2, Critical.
• PHP reserved the right to release earlier "should details of either vulnerability become public, or should evidence of active exploitation appear in the wild."
• "Full details, affected versions, and the fixed versions will be published with the release."

Updated with the release details, October 21: php.net published the release on October 21, 2026, with a security advisory titled "Critical remote code execution vulnerabilities, update now".

• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The release items say "There are no complete mitigations, updating is the only safe choice."
• The two CVEs: CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w), and CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp). php.net scores both CVSS v4.0 9.2 (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) and says they "can allow unauthenticated remote code execution". At NVD, NIST's own score for each is CVSS 3.1 9.8.
• Who is at risk: "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed". php.net considers the risk "highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."
• Exploitation: reported, not confirmed by us. watchTowr says its honeypots saw exploitation in the wild on October 21, and Sansec cites a Cloudflare report of attacks the same day. Neither CVE was in CISA's Known Exploited Vulnerabilities catalog at version 2026.10.21. More in what the release confirmed.
• Vendors: "Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages." Each channel's status is under where your PHP comes from.
• PHP 8.1, 8.0 and 7.4: no release. For each, the PHP security team pushed one commit to php-src, on the branch's final state, that its own message calls a "Minimal mitigation for EOL version": 17 to 23 files, against 389 in the full fix that went into 8.2.35, most of them tests. The branches are PHP-8.1-CVE-2026-109618-109619 (php-src) and the matching 8.0 and 7.4 ones, to build yourself or for a vendor to package. 7.3 and older get nothing from the PHP project.
• The Remi repository: php.net urges users of the volunteer-maintained rpms.remirepo.net to switch to distribution packages or build from source, and says "The repo will not have updates today."
• PHP 8.6: RC4 "also contains the fixes", and php.net still says "Please DO NOT use this version in production" (php.net).
• Adobe: nothing posted on the release when we checked on October 21; its newest Commerce bulletin was still APSB26-153.

What the PHP vulnerability notice said, and what it didn't#

We found no earlier advance notice of PHP vulnerabilities in php.net's news archive or on the php.announce list. PHP usually just ships: under its release process, branches in active support get a release every four weeks, and security-only branches get one "only when there is a security issue or regression issue to address."

Two details in the notice reward a slow read:

• "Critical" is the CVSS scale talking. PHP's own security classification policy has no Critical tier; it stops at High, Medium and Low. The label comes from CVSS v4.0, where FIRST's rating scale puts Critical at 9.0 to 10.0. The notice gave the base score only, with no vector; the GitHub advisories published the vector with the release.
• By PHP's own process, the CVE ids and the distributions come first. PHP's release process says "Each security flaw must have a CVE id before the final release" and "Be sure that the security team of each major distributions have access to the security reports, before public release". The release confirmed both: the ids came with it, and php.net says distributions and LTS vendors had the patches in advance.

What the release confirmed, and what is still only reported#

Before the release, security vendors and the press filled the gap within hours. Here is where each claim landed. Every claim is credited to its source, and we haven't verified exploitation ourselves.

• Confirmed by php.net: the ids, the score and the impact. The ids that BleepingComputer (citing watchTowr and an unsourced post on Y Combinator's Hacker News forum), Sansec and watchTowr's own FAQ circulated, CVE-2026-109618 and CVE-2026-109619, are the ones php.net published, and CVE.org lists both under php.net's CNA. The score is the notice's CVSS v4.0 9.2, and "unauthenticated remote code execution" is php.net's own phrase. watchTowr's post on X had called them "zero-day embargoed RCE vulns in PHP".
• Contradicted: CVSS 10.0. An unsourced post on Y Combinator's Hacker News forum and BleepingComputer's quote from watchTowr gave 10.0, which matches neither published score: php.net's CVSS v4.0 9.2 or NIST's CVSS 3.1 9.8 at NVD.
• Below 7.4: not addressed by php.net, so treat it as affected. BleepingComputer quotes watchTowr as saying both bugs "are understood to affect PHP versions 5, 6, 7, and 8", though PHP 6 never reached general availability; watchTowr's own FAQ said "The report claims the vulnerability affects every PHP version from PHP 5 onward, though this scope has not been confirmed by an official vendor advisory." Sansec wrote "PHP 5.4 or later", resting that on a leaked screenshot of an exploit tool's banner, and Huntress wrote "Reporting suggests PHP versions 5 through 8 may be affected." php.net's source patches stop at 7.4 and it says nothing about older branches, but Ubuntu shipped fixes for php7.2, php7.0 and php5 on its ESM releases (USN-8948-2), and deb.sury.org rebuilt 7.3 with both CVEs backported.
• Reported, not confirmed by us: exploitation. watchTowr's FAQ, updated October 21: "Exploitation has been observed in the wild as of the 21st of October through watchTowr's Attacker Eye global honeypot network." Sansec, which had forecast mass attacks within 15 minutes of the release, now cites a Cloudflare report of attacks on October 21, says public write-ups and an exploit tool exist, and expects mass exploitation. Neither CVE was in CISA's Known Exploited Vulnerabilities catalog at the version we read, 2026.10.21. CISA's own enrichment on both CVE records, added on October 21, rated exploitation "none".
• Reported: a slipped embargo. watchTowr on X: "We were all supposed to wait until Thursday at 11am ET." PHP's notice gave no reason for its date.

Which PHP branches get the fix: the PHP end-of-life map#

The table reads php.net's supported versions and end-of-life pages and its October 21 advisory; the status column is our reading of php.net's dates and definitions.

All four supported branches got the fix. PHP 8.2 end of life for security fixes is December 31, 2026, 71 days after this release, and php.net's 8.2.35 announcement says 8.2 "will receive no further security fixes after that date." A PHP EOL branch gets no php.net release: for 8.1, 8.0 and 7.4 the security team published source patches instead, and php.net's end-of-life page warns that older versions "may expose you to security vulnerabilities and bugs that have been fixed in more recent versions of PHP."

PHP 8.1 end of life: options for stores still on it#

PHP 8.1 reached end of life on December 31, 2025, with 8.1.34 as its last php.net release, and this release adds no 8.1 version. What it adds is a source patch: the PHP security team "provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor" (php.net). The options, from quickest to longest-lasting:

1. A vendor's patched 8.1 package. Ubuntu's own php8.1 on 22.04 got the fix in USN-8948-1 (8.1.2-1ubuntu2.28), and deb.sury.org rebuilt its 8.1 (8.1.34-9) on October 21, with 8.0, 7.4 and 7.3; its changelog adds September 24's fixes too, but still not July 30's. The Remi repository calls its end-of-life builds a "best effort action" that "can only be temporary", and php.net said on October 21 that it "will not have updates today". Debian's own security tracker lists this fix only for php8.4 on Debian 13 and php8.2 on Debian 12; no Debian release it covers ships php8.1. None of them promises the next fix.
2. Your own build of the patch. The branch PHP-8.1-CVE-2026-109618-109619 (php-src) is that one minimal-mitigation commit on the PHP-8.1 branch as it stood at end of life. A build from it still reports 8.1.34, the same as the unpatched release, so record the commit you built (1d7dec1). You build it, deploy it and own it.
3. Commercial extended-support PHP. Paid builds of end-of-life branches exist. Get it in writing that yours covers CVE-2026-109618 and CVE-2026-109619 on your exact branch.
4. A supported branch. The fix that lasts. When the application itself runs only on 8.1, as Magento 2.4.4 and 2.4.5 do, the application moves first.

Magento PHP version by release: which Adobe Commerce lines get the fix#

Adobe's system requirements (page last updated October 13, 2026, with no mention of these CVEs or the new PHP versions when we checked on October 21) list these PHP branches for each line's newest patch: 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 and 2.4.4-p18.

Adobe "supports only the system requirement combinations listed," and its list is narrower than what Composer accepts: 2.4.8's composer.json also allows PHP 8.2, and the 2.4.4-p13 and 2.4.5-p14 tags, the newest public ones on October 20, still allow 7.4. Composer installing a combination isn't Adobe supporting it. Our Magento upgrade page carries the support dates for every line.

Magento 2.4.4 and 2.4.5: no php.net release for PHP 8.1#

Both lines sit in Adobe's security-only transitional period until May 31, 2027, which "provides limited isolated security fixes only (no quality fixes)", and those fixes are for Magento's code. On PHP, Adobe's lifecycle policy is blunt: Adobe "does not provide security and quality fixes for third-party services and software dependencies (such as PHP and MySQL)" that reach end of life during support, and "You are responsible for monitoring the support status of PHP versions used in your environments." It marks PHP 8.1 on 2.4.4, 2.4.5 and 2.4.6 "PCI compliance at risk".

Adobe's knowledge base says something different. Its lifecycle FAQ says Adobe would apply "lifetime support PHP 8.1 security fixes" to 2.4.4 and 2.4.5 on Cloud "during the extended support", and that on-premises customers "will need to contact Adobe support" for them. Extended support ended on April 14, 2026 for 2.4.4 and on August 11, 2026 for 2.4.5, and Adobe doesn't say whether the arrangement outlived it or covers these two CVEs; it had posted nothing on the release when we checked on October 21. On Adobe Commerce, open a ticket and ask. On Magento Open Source there's no one to ask: Adobe's extended-support security patches "are available to Adobe Commerce customers only" (Adobe).

A patched PHP 8.1 exists anyway: Ubuntu 22.04's php8.1 from USN-8948-1, deb.sury.org's 8.1 rebuild of October 21, or your own build of the PHP security team's 8.1 branch, whose commit calls itself a minimal mitigation. None of them is a php.net release, and none comes with a promise for the next fix.

The fix that lasts is a release line whose PHP php.net still patches: 2.4.6 on PHP 8.2 buys time to December 31, 2026, and 2.4.7 or later runs 8.3. That's a project, not a patch, and what a Magento upgrade costs follows the version gap, your extensions, theme and integrations, and your test coverage.

Stuck on an old version? We'll patch you now and upgrade you when you're ready: our Magento upgrade service backports the Magento security fixes Adobe no longer ships for your release (Magento's code, not PHP), then moves you to a line whose PHP php.net still patches.

Adobe Commerce on Cloud#

On Adobe Commerce on Cloud, Adobe runs the container and you choose the branch. The PHP version is a line in .magento.app.yaml, type: php:8.3 for example (Adobe), and a version change is self-service and takes effect on deploy. Adobe's shared-responsibility table gives Adobe "Availability of PHP" and "Ongoing quality and patching of operating system", gives you the YAML that aligns PHP with your Commerce version, and has no row for patching PHP itself.

We found no Adobe page that says how a patch-level PHP release like this one reaches a Cloud project: automatically, on your next redeploy, or through an infrastructure rollout, and Adobe had posted no Cloud guidance on this release when we checked on October 21. Open a support ticket and ask, including whether the redeploy is yours to run. The runbook below has the commands to check and redeploy.

The PHP fix is not the Magento fix#

Two jobs, two layers. Adobe's bulletins patch Magento's code; this release patches the PHP interpreter underneath it. A store fully current on Adobe's patches is just as exposed to an interpreter bug as one that isn't, and a store on the patched PHP still needs Adobe's bulletins, APSB26-153 included. Do both, and don't let one ticket close the other.

WooCommerce, WordPress and other PHP stores#

WordPress recommends "PHP version 8.3 or greater" and says it "also works with PHP 7.4+", though "these versions have reached their official End Of Life and may expose your site to security vulnerabilities." WooCommerce's server requirements for version 10.8 and later recommend "PHP version 8.3 or greater (tested up to PHP 8.4)", with the same warning for 7.4. So the WooCommerce PHP version floor sits on a branch php.net stopped patching on November 28, 2022.

WordPress.org's own post on the release says "Due to the critical severity of the issues, site owners are encouraged to immediately update their installations of PHP," and "No WordPress update is required or planned for these issues." It tells site owners to check with their host and, for self-managed servers older than PHP 8.2, to consider taking the server offline until it's upgraded. WooCommerce had posted nothing of its own when we checked on October 21.

The WordPress PHP version mix, from WordPress.org's stats as read on October 20, 2026: 64.87% of reporting WordPress sites run a branch php.net still patches (8.2 to 8.5), and 35.11% run an end-of-life branch, including 16.46% on PHP 7.4 and 10.95% on 8.1. Another 24.31% run 8.2, whose security support ends December 31, 2026. These are WordPress sites, not WooCommerce stores; the page shows no snapshot date, and its figures leave out PHP 5.x.

Shopware, PrestaShop, OpenMage, Laravel and custom PHP stores follow the same map: find every PHP binary, check its branch against the table above, and check the application's own supported list before any branch move. Hosted SaaS platforms such as Shopify and BigCommerce run their own servers, so there's no PHP of yours to patch there; middleware you host yourself still counts.

Where your PHP comes from decides when you get the fix#

The php.net release is where the fix starts, not where it reaches you. If PHP came from a package, the fix comes from that package's maintainer, under its version number. php.net says distributions and LTS vendors had the patches in advance, and several shipped on October 21, the day php.net published. Each channel's status as we recorded it that day:

• Debian 13 (trixie), php8.4: DSA 6574-1, fixed in 8.4.27-1~deb13u1.
• Debian 12 (bookworm), php8.2, through Debian LTS: DLA 4848-1, fixed in 8.2.35-1~deb12u1.
• Ubuntu: USN-8948-1 for 22.04, 24.04, 26.04 and 26.10, including php8.1 (8.1.2-1ubuntu2.28) on 22.04 and php8.3 (8.3.6-0ubuntu0.24.04.13) on 24.04, and USN-8948-2 for the ESM releases, including php7.4 (7.4.3-4ubuntu2.29+esm5) on 20.04, plus php7.2, php7.0 and php5 on older ESM releases.
• RHEL 8, 9 and 10: Red Hat had no CVE page and no RHSA for either id when we checked on October 21. For September's batch, it still listed every RHEL php stream "Affected" on October 20.
• The Remi repository (RHEL family and Fedora): php.net's advice comes first: "If you rely on the volunteer-maintained rpms.remirepo.net, we urge you to switch to distribution packages or build from source, so you can immediately apply updates. The repo will not have updates today." Remi calls its end-of-life builds a "best effort action".
• deb.sury.org (ppa:ondrej/php and packages.sury.org), PHP 5.6 to 8.x side by side: rebuilt every branch from 7.3 to 8.5 on October 21: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, plus end-of-life builds of 8.1, 8.0, 7.4 and 7.3 with both CVEs backported (8.1.34-9 on 8.1). Those end-of-life builds had been two releases behind since July, and the rebuild closed only half the gap: by their changelogs, the 8.1, 8.0 and 7.4 builds add the September 24 batch but not the July 30 one, and the 7.3 build adds July 30's but not September's. Neither its site nor its Launchpad page makes a security promise.
• The Docker official php image: php:8.2.35-fpm, php:8.3.36-fpm, php:8.4.27-fpm and php:8.5.12-fpm went live on Docker Hub on October 21, after the image definitions took the new versions, and the floating php:8.3-fpm moved with them. There is still no 8.1 image.

That's why php -v alone can't prove a server is patched. Ubuntu 24.04's fixed package for this release is 8.3.6-0ubuntu0.24.04.13, so a fully patched server still reports 8.3.6; Debian keeps php.net's number with a suffix (8.4.27-1~deb13u1), and deb.sury.org's end-of-life builds report their last upstream number (8.1.34 on 8.1), patched or not. Compare the installed package version with your vendor's advisory (the USN, DSA or RHSA), not with php.net's number. It cuts both ways: a scanner that reads 8.3.6 flags a patched Ubuntu server as vulnerable.

Managed hosts. When we checked on October 21, Hypernode was the only host on our list with a statement on these CVEs; Adobe Commerce on Cloud, Nexcess, Cloudways, Kinsta and WP Engine had posted nothing.

• Hypernode says it "will handle the required PHP security updates at platform level", set session.upload_progress.enabled = 0 and session.use_strict_mode = 1 platform-wide as temporary measures, and told customers "You do not need to make changes yourself at this time." For its paid extended support on end-of-life versions, it expects backports through a partner, possibly slower than official updates.
• Kinsta: "If you select a Long-Term Support (LTS) PHP version, automatic updates are disabled."
• WP Engine offers "a temporary period of extended support for PHP 7.4", and "Automatic PHP upgrades cannot be deferred."
• Cloudways supports PHP 7.4, 8.0, 8.1, 8.2, 8.3 and 8.4. "Supported" on a host's PHP menu isn't "patched": php.net released nothing for the first three.

Ask your host three questions in writing. Have you applied 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's package for it, and restarted PHP? Is the PHP-FPM restart or the redeploy ours to do? What happens to sites on PHP 8.1?

What CVE-2024-4577, the June 2024 PHP-CGI bug, says about timing#

CVE-2024-4577 is the PHP vulnerability behind our rule that a critical PHP release is an hours job, not a days job. PHP fixed it on June 6, 2024, in 8.1.29, 8.2.20 and 8.3.8. It hit PHP-CGI on Windows, with Traditional Chinese, Simplified Chinese and Japanese locales verified as exploitable, and DEVCORE, which reported it, found that "all versions of XAMPP installations on Windows are vulnerable by default." On June 7, Imperva wrote "At present, we've seen several thousands of attacks", and Akamai later reported: "As early as one day after disclosure, the SIRT observed numerous exploit attempts". NVD published the record on June 9 at CVSS 3.1 9.8, and CISA added it to its Known Exploited Vulnerabilities catalog on June 12, with ransomware use "Known".

This time the packages kept pace: Debian's DSA 6574-1, Ubuntu's USN-8948-1 and deb.sury.org's rebuilds shipped on October 21, the day php.net published, and the official Docker images followed the same day. php.net says distributions and LTS vendors had the patches in advance.

Keep it in proportion. From October 2023 until this release, NVD published seven CVEs that php.net itself scored critical, and only CVE-2024-4577 is in CISA's catalog, the only PHP runtime entry added in those three years. Critical doesn't guarantee mass exploitation. When it came, it came the next day.

The first hour after the release: a runbook for stores#

This is how to update PHP on a store without leaving a server behind: every step with an owner, in the order to run them, with the evidence that closes it. The target is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's package for this release. If you cannot update today, the table's third group lists php.net's interim settings and their limits; none of them makes a server safe. The commands follow the table, each from the vendor's own documentation, and every one runs on staging first.

Check which PHP version every part of the store runs#

The PHP in your shell isn't necessarily the PHP serving checkout. In a shell, php -v and php -i report the CLI, which runs cron and Magento's queue consumers; a PHP-FPM pool reports the server API fpm-fcgi (PHP manual). Debian and Ubuntu packages let several PHP versions sit side by side, and on Ubuntu /usr/bin/php is an update-alternatives link, so the CLI can be a different branch from the pool. Check both, on every node: web, admin, cron, consumers, workers and staging.

# Run it on staging first.
# The CLI: what cron and queue consumers run
php -v
php -i | grep -i 'Server API'

# The PHP-FPM pools: what serves the store
systemctl list-units --type=service 'php*'   # Debian, Ubuntu: one unit per version
/usr/sbin/php-fpm8.3 -v                      # repeat for each version the list shows
php-fpm -v                                   # RHEL, AlmaLinux, Rocky

# The packages, to compare with your vendor's advisory
dpkg -l 'php*'                               # Debian, Ubuntu
rpm -qa 'php*'                               # RHEL family

# Magento: run it with the PHP binary that matches the store's pool
php8.3 bin/magento --version                 # Debian, Ubuntu; php bin/magento --version on RHEL

In a shell, the second line prints "Server API => Command Line Interface". Sources: php-fpm(8), systemctl, Red Hat's PHP guide, dpkg, rpm and Adobe.

Then check that each server runs the newest build its repository offers, and read what that build fixed. A repository can hold the fix while the server still runs the old build.

# Run it on staging first.
# Debian, Ubuntu (swap in your branch's package names)
sudo apt update                          # refresh package information first
apt policy php8.1-fpm                    # "Installed:" against "Candidate:"
apt list --upgradable 'php*'             # which php packages have a newer candidate
apt-get changelog php8.1-fpm             # changelog of the installed version

# RHEL, AlmaLinux, Rocky
dnf check-update 'php*'                  # exit code 100 means updates are available
dnf check-update --changelogs 'php*'     # also prints the changelog of each pending update
rpm -q --changelog php-fpm | head -40    # changelog of the installed package

Sources: apt, apt-cache for policy, apt-get, dnf and rpm. For deb.sury.org packages, apt-get changelog reads the installed build's changelog from the server's own copy in /usr/share/doc, if the system keeps one, but can't download any other build's, because neither repository's Release file says where changelogs live; each published build's changelog is on Launchpad instead.

Update PHP and restart every pool#

A patch-level PHP update inside your branch needs no Composer change: Magento's require.php uses tilde constraints such as ~8.3.0, which Composer reads as >=8.3.0 <8.4.0 (Composer). Upgrade only the PHP packages already installed, then restart, because installing the package isn't the fix. A running PHP-FPM master keeps its binary until it's restarted or reloaded (php-fpm(8)).

# Run it on staging first.
# Debian, Ubuntu: upgrade only what is installed
sudo apt update
sudo apt-get install --only-upgrade php8.3-fpm php8.3-cli   # plus every other php8.3-* package dpkg listed
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # only if PHP runs inside Apache (mod_php)
sudo needrestart -r l            # lists daemons still using old libraries (package: needrestart)

# RHEL family (AppStream or the Remi module stream)
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
sudo dnf needs-restarting -s     # services that still need a restart (dnf-plugins-core)
sudo dnf needs-restarting        # every process still on old files, queue consumers included

# Any Linux: queue consumers and other long-running PHP workers
ps -eo pid,lstart,args | grep '[q]ueue:consumers:start'   # each Magento consumer and when it started

Sources: apt, apt-get, dnf, needrestart and needs-restarting, ps, Ubuntu's php8.3 packaging for the package names, its PHP guide for the Apache restart, and Red Hat's guide for the service name. Ubuntu's packaging restarts FPM after an upgrade. We found nothing in Red Hat's documentation on whether dnf does, so restart anyway.

Queue consumers and other long-running PHP CLI workers keep the binary they started with, the same as an FPM master. Cron starts Magento's consumers, and each one runs until it has processed its message limit, 10,000 by default, then exits so the next cron run can start it again (Adobe). Stop every consumer that started before the update so cron restarts it on the patched PHP, and restart Supervisor- or systemd-managed workers the way you restart the pool.

OPcache needs no extra step: its shared-memory cache starts over when PHP-FPM restarts (PHP manual). Don't run opcache_reset() from a shell, since the CLI has its own OPcache setting, off by default, and Magento's cache flush clears Magento's own cache types, not OPcache (Adobe). If you need to update the PHP version itself, from one branch to the next, that's a different job: change the pin, re-resolve, test, and stay on Adobe's list.

Containers: bump pinned tags such as php:8.3.36-fpm in the Dockerfile or compose file, or re-pull floating tags such as php:8.3-fpm, then rebuild and recreate. A running container keeps its old image until it's recreated, and docker compose up rebuilds an image from a Dockerfile only when told to.

# Run it on staging first.
docker compose build --pull              # services built from a Dockerfile: rebuild on the newest base image
docker compose pull --ignore-buildable   # services that run an image tag directly
docker compose up -d                     # recreates every container whose image changed
docker compose exec <php-service> php -v
docker compose exec <php-service> php-fpm -v

Sources: Docker's compose build, compose pull, compose up and compose exec references, and the official image's Dockerfile for the tags.

On Adobe Commerce on Cloud, once Adobe support has said how the patched PHP reaches your project:

# Run it on staging first.
magento-cloud ssh -p <project-ID> -e <environment-ID> -- php -v
magento-cloud redeploy -p <project-ID> -e <environment-ID>

The syntax is from Adobe's Cloud CLI reference.

Verify, then prove the store still sells#

Run the first two blocks again on every node until the PHP-FPM pools and the CLI show the fixed package version (8.5.12, 8.4.27, 8.3.36 or 8.2.35 from php.net, or your vendor's package for this release), the installed build matches the repository's candidate, needrestart or needs-restarting lists no PHP process, and ps shows every queue consumer started after the update. Then the store: a test order per payment method, an Admin login, one REST or GraphQL call, cron, and Magento's queue consumers or WooCommerce's scheduled actions. Watch the PHP-FPM and web server error logs for an hour; that last step is our practice, not a vendor rule.

If you have to roll back, roll back PHP on the web and app nodes, not the database: restoring a full snapshot of a server that also holds the database loses every order placed since it was taken.

If nobody on your side can run this, or the store looks wrong after the patch, we can take it from here: every server updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor's package for this release; PHP 8.1 built from the PHP security team's source patch as a stop-gap before the upgrade, where your Magento version pins the store there; and php.net's interim settings in place while that work runs, which in php.net's words "reduce exposure to specific attack paths but do not make an installation safe." The priority form at the end of this page is the one on our Magento emergency support page, and a senior engineer replies in writing within one business day.

PHP patch gotchas: how stores stay exposed after the update#

What makes us wince in a patch window isn't the bug. It's the ticket that says "we're on the latest Adobe security patch, so we're covered." It's "PHP updated" because php -v changed in an SSH session, while the FPM pool serving every checkout still runs the binary it started with. It's the Ubuntu server flagged as unpatched because it reports 8.3.6. It's "Flush Magento Cache" offered as a fix for anything below the application. None of it is exotic. Each one is how a store stays exposed after everyone has signed off. Seven more:

• The repository has it; the server doesn't. Enabling a repository changes what apt or dnf can install, not what is installed. A fixed build reaches the server only after the package index refreshes and the package upgrades, and takes effect only after PHP-FPM restarts. On October 20, "Installed" matching "Candidate" still meant unpatched on deb.sury.org's end-of-life branches, whose candidate was a July build; it rebuilt them on October 21, so read the changelog, not just the match.
• Composer pins don't patch anything. config.platform.php "Lets you fake platform packages (PHP and extensions)" for dependency resolution (Composer); it never changes the binary production runs.
• Varnish hides the header, and that isn't protection. Magento's Varnish configuration strips X-Powered-By and Server (2.4.8's VCL), so an outside scan can't see your PHP version, and neither can you: check on the host. PHP's expose_php is on by default (PHP manual); turning it off changes what scanners see, not what can be exploited.
• PHP-FPM must never face the internet. From the PHP manual: "php-fpm must not be reachable from an untrusted network. A client that can open a FastCGI connection controls the configuration used for the request, including auto_prepend_file, and can therefore execute arbitrary code." That's standing hardening, not a fix for these bugs.
• A build from before October 21, 2026 lacks both fixes, and maybe more. The September 24 release had already fixed 12 advisories on 8.3 alone, across Filter, FPM, MySQLnd, OpenSSL, Phar, SOAP, Standard and Windows (ChangeLog), so a server that skipped it is two releases behind.
• Don't wait for a scanner. This time the GitHub advisories, CVE.org and NVD all published on October 21, but CVE-2024-4577's GitHub advisory came out on September 28, 2024, more than three months after the fix. The detection Qualys pointed customers to before the release, QID 45110, "is a discovery check and does not confirm vulnerability to these issues" (Qualys). Check the package version on the host.
• Developer laptops count. Adobe doesn't support Magento on Windows, but the 2024 bug hit PHP-CGI on Windows and every XAMPP install there by default. Local stacks sit outside most patch runbooks, and Windows builds come from php.net's Windows downloads.

PHP security release questions

Sources