Adobe Commerce October 2026 Security Patch (APSB26-153): What It Fixes and How to Apply It

On October 13, 2026, Adobe released APSB26-153, the October security update for Adobe Commerce, Adobe Commerce B2B and Magento Open Source. It fixes 11 vulnerabilities. One of them, CVE-2026-103849, has a CVSS score of 10.0 and needs no login: a template injection that leads to arbitrary code execution.

Adobe rates the bulletin priority 2 and says it knows of no exploits in the wild. I would still treat it as urgent. Five weeks ago, StyleSmuggler (CVE-2026-75650) was also a template-engine bug, also unauthenticated, also CVSS 10.0, and attackers were using it for three days before a hotfix existed. This post covers what October fixes, who is affected, and the exact steps I follow to apply it on Magento Open Source, Adobe Commerce on-premises and Adobe Commerce on Cloud.

The short version

• What: APSB26-153, 11 CVEs: 5 critical, 5 high, 1 medium. Five of them need no authentication.
• Affected: every 2.4.4 to 2.4.9 build up to the -2026-sep release, plus B2B 1.3.3 to 1.5.3.
• How it ships: as Isolated patch files only. There are no Composer packages for this release.
• Prerequisites: you must be on the latest -p release of your line and have every earlier monthly Isolated patch applied.
• Also required: the StyleSmuggler hotfix (VULN-39341) from September, plus rotating your encryption key and the credentials it protects.
• Cloud: the fix is already in magento/magento-cloud-patches 1.1.22. Update ece-tools and don’t apply the Isolated file on top of it.

What APSB26-153 fixes

This is the full list from Adobe’s bulletin. “No” in the last column means an attacker doesn’t need any account. The three marked B2B affect only stores with Adobe Commerce B2B installed.

Why I wouldn’t wait because it says “priority 2”

Adobe’s priority rating is about the risk of attacks happening now, not about how bad the bug is. Priority 2 means Adobe has seen no exploit yet. The CVSS 10.0 score means that if someone builds one, it works over the network, needs no account and no clicks, and gives them the server.

The bug class is what worries me. CVE-2026-103849 is a template-engine flaw. StyleSmuggler, which Sansec disclosed on September 5, was a template-engine flaw too: attackers planted PHP code and Magento ran it while rendering the “Payment Transaction Failed Reminder” email. Sansec saw a Linux backdoor disguised as NTP traffic and a second, unrelated attacker dropping a web shell. Template injection in Magento is a well-studied attack surface, and a patch diff is a good map for anyone looking for the next one.

So my rule for clients is simple: a no-auth code execution bug gets patched this week, whatever the priority label says.

Which versions are affected, and which ZIP you need

Since 2026, Adobe ships monthly dated builds, such as 2.4.8-2026-sep. Every build up to and including September is affected. For each release line, Adobe publishes one ZIP, and it only applies on top of the latest security release of that line:

Two things to note for Magento Open Source. Adobe only publishes October fixes for Open Source 2.4.7, 2.4.8 and 2.4.9, and Open Source merchants can only download patches for 2.4.7 or later. If you run Open Source 2.4.6 or older, there is no official October patch for you. Your real fix is an upgrade.

For B2B, the fixed builds are 1.3.3, 1.3.4, 1.4.2, 1.5.2 and 1.5.3 with the -2026-oct suffix. The B2B patch files come inside the same ZIP as the core files. The 2.4.10-alpha1 and B2B 1.5.4-alpha1 pre-releases already include the fixes.

Before you start

Most failed patch runs I see come from skipping this part. Check these four things first:

1. Know your exact version and components. Isolated patches are built per component (CE, EE, B2B, Page Builder and others) and per version, so you need both.
2. Be on the latest -p release of your line. Adobe only tests Isolated patches against that version. If you’re on 2.4.7-p8, upgrade to 2.4.7-p10 first.
3. Have every earlier monthly Isolated patch applied. Each month builds on the previous one, so they go in release order. If you skipped July or September, apply those first.
4. Have the StyleSmuggler hotfix applied. Adobe’s October notes ask for the CVE-2026-75650 hotfix (VULN-39341) in addition to this month’s files.

These commands show the version and the components installed:

bin/magento --version
composer show magento/product-community-edition | grep versions
composer show magento/product-enterprise-edition | grep versions    # Adobe Commerce
composer show magento/extension-b2b | grep versions                # B2B

And, as always: take a backup of the code and the database, and run all of this on a staging copy before production.

Step by step: Magento Open Source and Adobe Commerce on-premises

1. Check that the Commerce Version Tool is installed

The Commerce Version Tool (CVT) reports which monthly patches are applied, which are missing, and which CVEs you’re protected against. It arrived with the July 2026 Isolated patch, so if you have July applied, it’s already there:

php vendor/bin/patch-status --version

If the command isn’t found, you are missing July, and that’s the first patch to apply. Run php vendor/bin/patch-status once now, too. Its missing_patches list tells you whether anything older than October is still pending.

2. Download the ZIP for your line

For 2.4.7 and later, download it from the link in Adobe’s knowledge base article. For Commerce 2.4.6 and earlier, the browser asks for credentials: use your Composer public key as the username and your private key as the password. The same keys work with curl, which is handy on a server. Keep the -L: the link first redirects to the login endpoint.

mkdir -p ~/patches/2026-10 && cd ~/patches/2026-10
# 2.4.7 and later: public download
curl -fSLO https://repo.magento.com/patch/2-4-9-oct-2026.zip
# Adobe Commerce 2.4.6 and older: same, with your Composer keys
# curl -fSL -u "$COMPOSER_PUBLIC_KEY:$COMPOSER_PRIVATE_KEY" \
#   -O https://repo.magento.com/patch/2-4-6-p15-oct-2026.zip
unzip 2-4-9-oct-2026.zip -x '__MACOSX/*'
ls -1 2.4.9_oct_2026/*.patch

3. Pick the files that match your installation

The ZIP can contain one file per component, and sometimes more than one file per component for different component versions. File names follow the pattern <version>-<YYYY>-<MM>-<seq>-<COMPONENT>. For example, the 2.4.9 ZIP contains three files: 249-2026-10-001-CE.patch (22 files changed, including Magento’s template filter), 249-2026-10-001-EE.patch (one file) and 153-2026-10-001-B2B.patch (for B2B 1.5.3). Apply only the files for components you actually have, in this order:

• Magento Open Source: the CE file.
• Adobe Commerce: the CE file, then the EE file.
• With B2B: after CE and EE, the B2B file that matches your B2B version (for example, the 152p5 file for B2B 1.5.2-p5).
• Other components (Page Builder and others): their file, if the ZIP includes one and you have that component.

Not every month’s ZIP includes a file for every component. If there’s no B2B file this month, there’s nothing to apply for B2B.

4. Dry run, then apply

Do a dry run first. It changes nothing and tells you whether every part of the patch would apply cleanly. If it fails, stop: it usually means a missing earlier patch or a core file someone edited by hand.

cd /var/www/magento    # your Magento root
bin/magento maintenance:enable
# Example for Adobe Commerce 2.4.9 with B2B. Order matters: CE, then EE, then B2B.
# Magento Open Source: keep only the CE file.
PATCHES="249-2026-10-001-CE.patch 249-2026-10-001-EE.patch 153-2026-10-001-B2B.patch"
for p in $PATCHES; do
  patch -p1 --dry-run < ~/patches/2026-10/2.4.9_oct_2026/$p || { echo "Dry run failed: $p"; exit 1; }
done
for p in $PATCHES; do
  patch -p1 < ~/patches/2026-10/2.4.9_oct_2026/$p
done

Every path inside these files starts with vendor/magento/, so -p1 from the Magento root is right for a normal Composer installation. If your project keeps the core in app/code/Magento instead of vendor/, the paths won’t match and the dry run will tell you. Adobe’s instructions mention -p2 as the alternative when -p1 fails.

5. Rebuild and bring the store back

Adobe’s minimum is a cache refresh. In production mode, I also rebuild generated code and static files, because a security patch can touch PHP classes, templates and JavaScript:

bin/magento setup:di:compile
bin/magento setup:static-content:deploy    # add your locales and themes
bin/magento cache:flush
bin/magento maintenance:disable

6. Verify

php vendor/bin/patch-status

You want October in applied_patches, nothing in missing_patches or unknown_patches, and every CVE in vulnerability_status showing PROTECTED (or NOT_APPLICABLE, for a component you don’t have). UNKNOWN deserves a closer look before you call it done. If you manage several stores, --format=csv gives one line per CVE, which is easy to collect in a spreadsheet.

7. Make it survive the next deploy

This is the step that bites Composer-based projects. These patches change files under vendor/. If your pipeline runs composer install on a clean checkout, the patch disappears on the next deploy, and the store is vulnerable again without anyone noticing.

What I do: commit the patch files to a patches/ folder in the repository, and apply them in the build step right after composer install, with the same dry-run guard. Then run patch-status in the pipeline, so a missing patch fails the build instead of reaching production. Some teams use cweagans/composer-patches for this. It works, but Adobe states it doesn’t support applying its official patches that way, so you are on your own if something breaks.

Step by step: Adobe Commerce on Cloud

On Cloud, you don’t have to handle the ZIP at all. magento/magento-cloud-patches 1.1.22, released on October 13, applies the APSB26-153 fixes. Cloud Patches comes in as a dependency of ece-tools, so updating ece-tools brings it in.

Option A (recommended): update ece-tools

git checkout -b security/apsb26-153
composer update magento/ece-tools --with-dependencies
composer show magento/magento-cloud-patches | grep versions    # expect 1.1.22 or later
git add composer.lock
git commit -m "Security: APSB26-153 via magento-cloud-patches 1.1.22"
git push origin security/apsb26-153

To check that the patches apply before you push, run php ./vendor/bin/ece-patches apply and then php ./bin/magento cache:clean on your local copy. Deploy to an Integration environment first, then Staging, then Production. Important: don’t also add the October Isolated files to m2-hotfixes. Adobe warns that applying the Isolated patch when Cloud Patches already includes the fix can make the deployment fail.

Option B: the Isolated files in m2-hotfixes

Use this only if you can’t update ece-tools right now. Put the matching files in m2-hotfixes at the project root; the build applies them on deploy. One trap: ece-tools applies custom patches in alphabetical order by file name. A B2B file starts with the B2B version (in the 2.4.9 ZIP, 153-2026-10-001-B2B.patch), so it sorts before the core files (249-…) and would be applied first. If you have B2B, add a numeric prefix to the names so the order matches Adobe’s: CE, then EE, then B2B.

mkdir -p m2-hotfixes
Z=~/patches/2026-10/2.4.9_oct_2026
# Numeric prefixes keep Adobe's order: CE, then EE, then B2B
cp $Z/249-2026-10-001-CE.patch  m2-hotfixes/01-249-2026-10-001-CE.patch
cp $Z/249-2026-10-001-EE.patch  m2-hotfixes/02-249-2026-10-001-EE.patch
cp $Z/153-2026-10-001-B2B.patch m2-hotfixes/03-153-2026-10-001-B2B.patch
git add -A
git commit -m "Security: APSB26-153 Isolated patches"
git push origin

Option C: Adobe Commerce Patching Automation

Adobe introduced a new service with this release, inside the Site-Wide Analysis Tool. It lists the available patches per project and environment, applies them to an Integration environment first, runs health checks, and lets you revert with one click. I haven’t used it on a client project yet, so I’d still check the result with CVT.

Verify on Cloud

CVT works on Cloud too (php vendor/bin/patch-status). If it isn’t available, the Quality Patches Tool can confirm a specific file. Adobe’s example uses a July file name; swap in this month’s:

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

Don’t skip: the StyleSmuggler hotfix and key rotation

Adobe’s October notes repeat two requests from September, and both matter more than the October files themselves if you haven’t done them yet.

The CVE-2026-75650 hotfix. It ships as VULN-39341-composer-patches.zip for the recent builds, with separate files for older -p releases (listed in Adobe’s APSB26-146 knowledge base article). On-premises, apply it like the files above with patch -p1. On Cloud, magento-cloud-patches 1.1.21 applied the APSB26-146 fixes; confirm it with vendor/bin/magento-patches -n status | grep "39341\|Status" or CVT. And remember that a patch closes the hole but doesn’t clean a store that was already hit. Stores were attacked before the hotfix existed, so scan for backdoors, especially unexpected PHP files under pub/media.

Rotate the encryption key and what it protects. Rotating the key alone isn’t enough: anything already stolen stays valid until you change it at the source. Adobe’s sequence, shortened:

1. Apply the hotfix, enable maintenance mode and disable cron (on Cloud: vendor/bin/ece-tools cron:disable).
2. Rotate the encryption key.
3. Reset all Admin passwords.
4. Regenerate REST, SOAP and GraphQL integration tokens, and OAuth client secrets for connected apps.
5. Rotate payment gateway credentials at the provider (Stripe, Braintree, Adyen, PayPal and others), plus shipping, tax and other extension API keys.
6. Rotate database credentials, SSH and deploy keys, and service account credentials. On Cloud, database and Fastly credentials go through a support ticket.
7. Flush the cache, enable cron (vendor/bin/ece-tools cron:enable on Cloud), disable maintenance mode. On Cloud, redeploy to pick up the new database credentials.

My checklist for this month

• List every instance by full version, including staging, QA and secondary storefronts. Staging servers get forgotten and are often public.
• Run php vendor/bin/patch-status everywhere and write down what’s missing.
• Close the gaps in order: latest -p, earlier monthly patches, the StyleSmuggler hotfix, then October.
• Make the patches part of the build, so the next composer install can’t undo them.
• Rotate the encryption key and credentials if you haven’t since September.
• Open Source 2.4.6 or older: plan the upgrade now. There is no October fix for you.

Monthly Isolated patches are faster than waiting for a full release, but they move the responsibility to you: the right file, the right order, and proof that it’s applied. If you work on several Magento projects, make patch-status part of the routine. It’s the cheapest way I know to answer the question every client asks after a bulletin: “Are we safe?”

Sources

• Adobe Security Bulletin APSB26-153 (October 13, 2026)
• Adobe KB: Security update available for Adobe Commerce, APSB26-153 (updated October 14, 2026)
• Adobe KB: Hotfix for CVE-2026-75650 (APSB26-146)
• Adobe: How to apply an Isolated security patch file
• Adobe: Commerce Version Tool
• Adobe: Cloud Patches release notes
• Adobe: Commerce Patching Automation
• Sansec: StyleSmuggler, Magento and Adobe Commerce 0-day RCE (CVE-2026-75650)