Magento security patches: which ones you are missing, and how to install them without breaking the store

Adobe now ships Magento security fixes every month, in more than one format, and an emergency hotfix in September was already being exploited when it came out. Here is how the patches arrive in 2026, how to find out which ones your store is missing, and the routine I use to install them without taking checkout down with them.

How Adobe ships security fixes in 2026

Every fix starts as an Adobe security bulletin with an ID such as APSB26-153: Adobe Product Security Bulletin, year 2026, number 153. Regular bulletins come out on Adobe’s monthly patch day, the second Tuesday of the month. The bulletin tells you which versions are affected, how severe the issues are and which versions contain the fix. The fix itself reaches you in one of three ways.

1. Security patch releases: the -p versions

Versions like 2.4.8-p5 or 2.4.7-p10 are full Composer releases that bundle the security fixes for a release line. You install them with Composer like any other upgrade. They are cumulative, so the latest -p of your line contains everything before it.

2. Monthly isolated patches

Between -p releases, Adobe publishes isolated patches: zip files with patch files for the latest -p of each supported line, named like 2-4-8-p5-oct-2026.zip. In some months, the fixes for several lines were published only this way, not as Composer packages. Three rules matter:

  • They apply only on top of the latest -p release of your line. If you are on an older -p, you update first.
  • They build on each other. Adobe asks you to apply the earlier monthly patches first, in release order.
  • The zip can contain separate files for Open Source, Adobe Commerce and B2B. You apply only the ones that match what you have installed, Open Source first, then Commerce, then B2B.

That is also why the bulletins now name fixed versions like 2.4.8-2026-oct: release 2.4.8 with the October 2026 fixes on top.

3. Emergency hotfixes

When something is serious enough, Adobe does not wait for patch day. On 7 September 2026 it published APSB26-146, a hotfix for CVE-2026-75650: remote code execution without authentication, rated 10.0 out of 10, and, in Adobe’s words, already being exploited in the wild. That hotfix is not included in the October isolated patch. Adobe’s October bulletin asks you to apply it separately, in addition to the October fixes. If your store got the October patch and nothing else, it is still exposed.

The bulletins that matter right now

BulletinPublishedWhat it means for you
APSB26-15313 Oct 202611 vulnerabilities, 5 rated critical. No known exploits when published. Isolated patch for each supported line.
APSB26-1467 Sep 2026Emergency hotfix for CVE-2026-75650, exploited in the wild. Apply separately, it is not in the October patch.
Earlier 2026MonthlyRegular bulletins on patch day. The July isolated patch also ships Adobe’s Commerce Version Tool, used below.

Adobe’s remediation guidance for October also recommends rotating your encryption keys and the credentials encrypted with them, such as integration tokens and payment gateway keys. That step is easy to forget, because it is not a patch file.

Which patches is your store missing?

Step 1: find your exact version

Run this on the server, or ask whoever hosts the store:

bin/magento --version
composer show magento/product-community-edition   # Open Source
composer show magento/product-enterprise-edition  # Adobe Commerce

You need the full version, including the -p part. “2.4.7” and “2.4.7-p10” are very different answers.

Step 2: see what has been applied on top

If the July 2026 isolated patch or anything later is installed, Adobe’s Commerce Version Tool reports installed and missing patches, per CVE:

php vendor/bin/patch-status

If that command does not exist, you already know something: the July 2026 isolated patch, and so everything after it, is most likely missing. Then look for patch files in the repository, usually in a patches/ folder or listed in composer.json, and check the deployment history. Stores that changed agencies often have patches applied by hand on the server and recorded nowhere, which is exactly what the next deployment overwrites.

Step 3: compare with the bulletins

Open the latest bulletin and find your line in the affected versions table. Then check two things: that your -p level is the latest for your line, and that every monthly isolated patch and hotfix since that -p release is applied. In October 2026 the latest levels were 2.4.9 itself for the newest line, then 2.4.8-p5, 2.4.7-p10 and 2.4.6-p15, plus the October isolated patch and the September hotfix on top.

If you run Open Source 2.4.6 or older

The October bulletin lists Magento Open Source 2.4.6 as affected, but the fixed Open Source versions start at 2.4.7, and Adobe’s patch article says Open Source merchants can only download patches for 2.4.7 or later. There is no official patch for you. Your options are an upgrade to a supported release, or a move to the current Mage-OS release, which ports Adobe’s fixes within days. Adapting the 2.4.7 patch files to 2.4.6 by hand is possible as a stopgap for a few weeks, but it is unsupported, and every month adds to the debt. I explain the support dates in more detail in Is Magento end of life?

How I install a security patch without breaking the store

The patch itself is rarely the problem. The problems come from what sits around it: custom code, overridden templates, extensions and the deployment process. This is the routine I follow on every store.

  1. Read Adobe’s bulletin and knowledge base article for your line, not a summary, this one included. Note the prerequisites: the required -p level, earlier monthly patches and separate hotfixes.
  2. Make a staging copy of production: the same code, a recent database with customer data anonymised, and the same PHP, MySQL or MariaDB, OpenSearch, Redis and Varnish versions. A patch tested on a different stack is not tested.
  3. Bring the base up to date. If the store is not on the latest -p of its line, that is a Composer update first, with its own round of testing.
  4. Commit the patch files to the repository and apply them through Composer, for example with a patches plugin, in the order Adobe gives. Never apply a patch by hand inside vendor/ on the server: the next composer install silently removes it.
  5. Run the usual deployment steps on staging: setup:upgrade, setup:di:compile, static content deploy and a cache flush.
  6. Verify the fix, with patch-status where available, and then test what earns money: home, category, search, product pages, add to cart, checkout with every payment and shipping method in test mode, customer login and registration, admin login, order export to your ERP, cron and queue consumers.
  7. Release to production through your normal pipeline, in a maintenance window you have agreed, with a database backup taken just before and the previous release ready to switch back to.
  8. Finish the guidance: rotate keys and credentials if the bulletin asks for it, and watch the exception and server logs and the order flow for the next day or two.

What usually breaks, and how to avoid it

  • Theme overrides of patched templates. Many security fixes are escaping fixes in .phtml templates. If your theme overrides that template, the fix never reaches the page. I compare every template the patch touches with the overrides in the theme and port the fix by hand.
  • Custom modules that rewrite core classes. Preferences and plugins around the patched code can undo the fix or break when its signature changes. A search of the codebase for the patched classes takes minutes and saves a bad evening.
  • Extensions that relied on the hole. Some fixes tighten authorisation, and an extension that called an API in a way that was never meant to work stops working. Better to find that on staging than in your checkout.
  • Existing patches that no longer apply. Stores with years of history carry their own patches. When one fails to apply after an update, the deployment stops, which is the good outcome; the bad one is a pipeline that ignores the failure.
  • Adobe Commerce on Cloud. The cloud patches package may already contain the fix, and applying the isolated patch on top can fail. Check that first.

How often to do this

Monthly. Book a slot for the days after patch day and treat it like any other release. When Adobe marks a vulnerability as exploited in the wild, the timeline is a day or two, not the next sprint: those are the weeks when automated attacks scan every Magento store they can find. On a store that is current, applying a month’s fixes is a short, routine job. The cost and the risk sit in stores that are a year behind and then have to catch up under pressure.

Sources