How to Apply Magento Security Patches in 2026: Isolated Patches, QPT and -p Releases

Adobe changed how Magento security fixes ship in 2026, and “apply the patch” now means one of three jobs, depending on what Adobe released. This guide covers each for Magento Open Source and Adobe Commerce, on-premises and on Cloud, checked against Adobe’s documentation as of 3 October 2026. For the bulletins themselves, see our Magento security bulletin tracker.

The three ways a fix arrives

Security patch releases (2.4.x-pN). Adobe appends “-pN” to a release, “where N is the incremental patch version”. Each one “contains quality and security fixes from prior patch release and security fixes created between the prior full patch release and the security patch release.” You install it with Composer, like any version change.

Isolated security patches. Since the July 2026 bulletin, APSB26-73, Adobe has shipped its scheduled monthly fixes as patch files rather than new Composer versions. Adobe calls them “non-cumulative, standalone patch files that include fixes for one or more security vulnerabilities only”. There is one zip per line from 2.4.4 to 2.4.9, built for the latest -p of that line. The September 2026 files target 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 and 2.4.4-p18.

Two rules catch people out. You must be on the latest -p release for your line, “as isolated security patch files are tested exclusively against that version.” And you must already have applied every earlier monthly patch for that line, because each one builds on the last and “must be applied cumulatively, in release order”. A store that skipped July cannot go straight to September.

Out-of-band hotfixes. When something is being exploited, Adobe does not wait for the monthly cycle. StyleSmuggler (CVE-2026-75650) was fixed by hotfix VULN-39341 under bulletin APSB26-146. Adobe says that hotfix is “not included in the September Isolated patch file” and “can be applied either before or after” it. A hotfix needs its own step. Our StyleSmuggler write-up covers what to check beyond the patch.

The Quality Patches Tool is not one of the three. Adobe says: “QPT is for quality patches only. Security patches are available in the Magento Security Center.”

Before you touch production

The process matters more than the command:

1. Staging first. Adobe “strongly recommend[s] applying and testing the patch on the Staging/Integration environment before applying it to Production.” Use the same extensions and a recent copy of production data.
2. Back up. Adobe also recommends “a recent backup before any manipulations.” Take a database dump and a snapshot of the code, including composer.json and composer.lock.
3. Keep your logs. If the hole was already being exploited, a redeploy can rotate away the evidence of whether you were hit. Copy them first.
4. Book a window. A -p release runs setup:upgrade and a full recompile, so plan for maintenance mode. We compile and flush caches after patch files too, so they get a short window as well.
5. Know the way back before you start. See rollback, below.

Applying a -p release with Composer

Adobe’s upgrade guide says you “must install a new version of the magento/composer-root-update-plugin package” first, and that the command changed from composer require to composer require-commerce. Follow that step in Adobe’s guide before the commands below. For Adobe Commerce:

bin/magento maintenance:enable
cp composer.json composer.json.bak
cp composer.lock composer.lock.bak
# Replace 2.4.7-pN with the latest -p release for your line (Magento Open Source: magento/product-community-edition)
composer require-commerce magento/product-enterprise-edition 2.4.7-pN --no-update
composer update
bin/magento setup:upgrade

For Magento Open Source, the package is magento/product-community-edition. Swap in the latest -p for your line, listed on Adobe’s released versions page. In production mode, compile and deploy static content:

bin/magento setup:di:compile
bin/magento setup:static-content:deploy

Then, in any mode, flush the cache and take the store out of maintenance:

bin/magento cache:flush
bin/magento maintenance:disable

Adobe Commerce customers can also run the Upgrade Compatibility Tool against the target version. Adobe says it “returns a list of critical issues, errors, and warnings that must be addressed before upgrading”:

bin/uct upgrade:check <dir> -c <target-version>

It is Adobe Commerce only, and earns its place on a jump between minor versions, where extensions usually break. That is a bigger job: see Magento upgrades.

Applying an isolated patch or hotfix file on-premises

Adobe’s instructions for its patch files (the APSB26-146 hotfix links to them, and so did the first isolated patch bulletin) are to upload the file to the Magento root and run:

patch -p1 < %patch_name%.composer.patch

If that does not work, Adobe says to try -p2 instead of -p1. Then refresh the cache under System > Cache Management, or with bin/magento cache:flush.

An isolated patch zip can hold several files. Adobe’s example is an Adobe Commerce store on 2.4.6-p15 with B2B 1.5.2-p5, which applies the CE patch, then the EE patch, then the B2B patch. For each component you have installed, apply the one file that matches your installed version of it.

Composer patches plugin or git apply? Many teams manage patches with cweagans/composer-patches. Adobe documents the plugin for custom patches, but says: “Adobe does not support applying official, Adobe-provided patches using this method.” Its own instructions use patch, not git apply. We follow Adobe for Adobe’s files and keep the plugin for custom and community fixes.

The catch with a hand-applied patch is that Composer does not know about it. If your build runs a fresh composer install, the change to vendor/ is gone unless the deploy puts it back. We commit patch files to the repository and apply them as a build step after composer install. Adobe’s patching guide does the same with its own tooling, which “must run after composer install operations”, and puts security patches before quality and custom ones.

Adobe Commerce on Cloud

Cloud works differently. The magento/magento-cloud-patches package “is a dependency for the ECE-Tools package and is installed and updated when you install or update the ECE-Tools package.” Its 2026 release notes list v1.1.18 with the APSB26-92 fixes and v1.1.21 with the APSB26-146 fixes. So start by updating ECE-Tools on a branch:

composer update magento/ece-tools --with-dependencies
git add -A
git commit -m "Update magento/ece-tools"
git push origin <branch-name>

Check what is already in place before adding anything:

php ./vendor/bin/ece-patches status

Adobe warns that applying an isolated patch “when the fix is already in place from the cloud-patches update can cause installation failures.”

For a patch file you still need, create an m2-hotfixes directory in the project root, copy the .patch file into it, then commit and push. Files there apply during deployment in alphabetical order by name, so name them in the order they must go on.

Quality patches on Cloud go in .magento.env.yaml:

stage:
  build:
    QUALITY_PATCHES:
      - MCTEST-1002
      - MCTEST-1003

To try them locally, run php ./vendor/bin/ece-patches apply, then php ./bin/magento cache:clean. Adobe recommends testing every patch in an Integration or Staging environment before Production.

The Quality Patches Tool

QPT, the magento/quality-patches package, delivers quality fixes from Adobe and the community for both Adobe Commerce and Magento Open Source. On-premises:

composer require magento/quality-patches
./vendor/bin/magento-patches status
./vendor/bin/magento-patches apply MAGETWO-XXXX
./bin/magento cache:clean

status lists the patches for your version as Applied, Not applied or N/A (status “cannot be defined due to conflicts”). Separate several IDs with spaces. To pick up newly released patches, run composer update magento/quality-patches. Everything is logged in var/log/patch.log.

Adobe says to use it “on a case-by-case basis only and not as a long-term approach”. If you are carrying more than a handful, the upgrade is overdue.

How to confirm a patch is applied

The version number only tells part of the story.

• -p release: bin/magento --version, or the bottom right corner of any Admin page.
• Isolated patches: each monthly patch installs Adobe’s Commerce Version Tool at vendor/bin/patch-status. It reports which monthly patches are applied, missing or unknown, and marks each CVE as protected or vulnerable. The CSV output makes useful compliance evidence.

php vendor/bin/patch-status --version
php vendor/bin/patch-status
php vendor/bin/patch-status --format=csv

• Hotfix VULN-39341 on Cloud: Adobe’s check is below. On-premises, check your deploy record for the file by name.

vendor/bin/magento-patches -n status | grep "39341\|Status"

• Quality patches: magento-patches status, or ece-patches status on Cloud.

Then test the store: place a test order, log in to the Admin, confirm cron is running, and watch the exception log.

Rolling back

• A QPT patch: ./vendor/bin/magento-patches revert MAGETWO-XXXX, or revert --all.
• On Cloud: remove the entry from .magento.env.yaml or the file from m2-hotfixes, then commit and push. Locally, php ./vendor/bin/ece-patches revert reverts everything.
• A -p release: restore composer.json.bak and composer.lock.bak, run composer install, then setup:upgrade, or redeploy the previous release. If setup:upgrade changed the database, restore the backup as well, which is why the backup comes first.
• A patch file applied by hand: reverse it with patch -R -p1 < %patch_name%.composer.patch from the Magento root, then flush the cache.

Rolling back a security patch reopens the hole, so treat it as time to fix the conflict, not the end state. An edge rule helps meanwhile; our Cloudflare WAF post explains what one can and cannot cover.

Magento Open Source versus Adobe Commerce

• Packages: the Composer steps are the same, with product-community-edition for Open Source and product-enterprise-edition for Adobe Commerce.
• Extended support: Adobe says extended support security patches “are available to Adobe Commerce customers only.” It has listed Open Source on some isolated fixes for older lines, but that is not a commitment. Our Magento 2.4 end of life dates post has the dates for each line.
• Patch files: Adobe Commerce stores apply the CE file, then EE, then B2B if installed. Open Source applies the CE file only.
• Tools: the Upgrade Compatibility Tool is Adobe Commerce only. QPT and the Commerce Version Tool work on both. ECE-Tools, m2-hotfixes and QUALITY_PATCHES are for Adobe Commerce on Cloud.

How fast you need to be: PCI DSS 6.3.3

If your store takes card payments, requirement 6.3.3 of PCI DSS v4.0.1 expects critical security patches to be installed within one month of release. With Adobe shipping monthly, and each month’s file depending on the last, each patch has to clear staging and reach production before the next one lands. An exploited hotfix like VULN-39341 should go on within days.

The month only helps if a patch exists. On a version Adobe no longer patches, there is nothing to install, which is the point of the end of life post.

How we handle it

We have run Aelia Duty Free’s Adobe Commerce platform since 2021. Our Adobe Commerce-certified developers read each bulletin the day it lands, apply it to staging, and take it live with the rollback ready. Same-day patching, out-of-band hotfixes included, is part of our Magento support, and we take over stores other agencies built.

---

Sources: Security patch release notes, Perform an upgrade, Apply patches, How to apply a composer patch provided by Adobe, Best practices for distributing patches at scale, Quality Patches Tool usage, Check patch for Adobe Commerce issue with QPT, Commerce Version Tool, Run the Upgrade Compatibility Tool, Apply patches on Cloud, Update the ECE-Tools package, Cloud Patches for Commerce release notes, APSB26-73, APSB26-138 and APSB26-146 (Adobe), magento/quality-patches (GitHub), and Just Published: PCI DSS v4.0.1 (PCI Security Standards Council).