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

What APSB26-153 is

APSB26-153 is Adobe's fourth monthly bulletin under the isolated patch model that started with APSB26-73 in July. Same deal as before: no 2.4.9-p2, no new Composer release. Adobe ships a zip per release line, you apply the patch file inside it on top of your current code, and Adobe calls the patched state a dated label such as 2.4.9-2026-oct.

The fixed labels in the bulletin are 2.4.9-2026-oct, 2.4.8-2026-oct and 2.4.7-2026-oct for both editions, plus 2.4.6, 2.4.5 and 2.4.4 -2026-oct for Adobe Commerce only. 2.4.10-alpha1, the first alpha of the next line, also carries the fixes. Adobe says it is not aware of any exploits in the wild for these issues as of publication.

The 11 CVEs in APSB26-153

Straight from the bulletin. "Auth" means the attacker needs some kind of login first.

Three of the eleven (92909, 92908, 92910) are B2B only. If you run plain Open Source, eight apply to you, and the 10.0 is one of them. Its vector is AV:N/AC:L/PR:N/UI:N/S:C: over the network, low complexity, no privileges, no clicks, and the damage can cross out of the vulnerable component. That is the profile that gets mass-scanned within weeks of a public diff.

Adobe does not publish which file fixes which CVE, and I am not going to guess. What I can tell you is what the 2.4.9 CE patch touches, because I read all 1,224 lines of it before applying it:

• Email and CMS template processing: Framework/Filter/Template.php, two new classes (DeferredDirectiveRegistry, SignatureProvider), the email template Filter and Validator, and the admin template Preview block, which now validates raw template text before rendering it. Given the CWE-1336 headline, this is the area I would watch.
• UI component sanitizer: the ${ } template check in Sanitizer.php is replaced with a stricter syntax check.
• Customer data over APIs: a new RestrictedFieldsPlugin on the customer repository, wired in for REST, SOAP and GraphQL, plus a change in how a customer is loaded by forgot-password token.
• Admin mass attribute update: the Product/Action/Attribute/Save controller sanitizes attribute values differently.
• Smaller changes in Escaper, the email address validator, the WYSIWYG HTML validator, the file lock backend and the persistent cart plugin.

Who is affected, and which zip you need

Open Source 2.4.6 is listed as affected but gets no October fix, because Open Source downloads stop at 2.4.7. Its support ended on August 11, which I covered in the 2.4.6 end of life post. If you are still there, the answer is an upgrade, not a patch.

On Adobe Commerce Cloud, do not apply the isolated file by hand. Adobe says the latest cloud-patches update already covers it, and applying the isolated patch on top of that can break installation.

Before you apply: three checks

These take two minutes and save an evening.

cd /var/www/html

# 1. exact base version
composer show magento/product-community-edition | grep ^versions
# versions : * 2.4.9

# 2. is Adobe's patch-status tool there at all?
php vendor/bin/patch-status --version
# patch-status 1.0.2

# 3. any leftovers from older patch runs or hand edits?
find vendor -name '*.rej' -o -name '*.orig' | head

If step 2 says the file does not exist, you are missing the July patch, because July is what installs vendor/bin/patch-status. Stop there and catch up first. I wrote a full checklist for finding missing Magento security patches for exactly this case.

Also confirm the September emergency hotfix is in. APSB26-146 (CVE-2026-75650, the zero-day behind the StyleSmuggler attacks) ships as VULN-39341 and is not part of the October zip. Adobe's October notes tell you to apply it separately.

How to apply APSB26-153 on Magento 2.4.9 Open Source

Download and unpack the zip outside the docroot:

mkdir -p ~/patches/2026-10 && cd ~/patches/2026-10
curl -fsSLO https://repo.magento.com/patch/2-4-9-oct-2026.zip
unzip 2-4-9-oct-2026.zip

The 2.4.9 zip holds three patch files: 249-2026-10-001-CE.patch, an EE patch and a B2B patch. Open Source stores apply the CE file and nothing else. Commerce applies CE, then EE, then B2B if installed, in that order.

Dry run first, against the real codebase, on staging:

cd /var/www/html
patch -p1 --dry-run < ~/patches/2026-10/249-2026-10-001-CE.patch

Every line should read checking file ... with no FAILED. A clean dry run means your files match what Adobe built against. If anything fails, do not force it. Two failed hunks on Sanitizer.php and Preview.php is exactly what I hit tonight, and the fix for an isolated patch that will not apply is in its own post.

Then apply for real:

bin/magento maintenance:enable
patch -p1 --no-backup-if-mismatch < ~/patches/2026-10/249-2026-10-001-CE.patch
bin/magento setup:di:compile
bin/magento cache:flush
bin/magento maintenance:disable

Why setup:di:compile when most guides skip it: the October CE patch changes constructors and adds plugins in several di.xml files. In production mode the compiled DI config and generated interceptors must be rebuilt or the new plugin never runs. October does not touch JS or LESS, so no static content deploy is needed for it alone. (August patches a JavaScript library under lib/web, so if you are catching up, run the static deploy too.)

--no-backup-if-mismatch stops GNU patch from dropping .orig files into vendor when a hunk lands with fuzz. Those leftovers confuse every later check.

Make it survive the next composer install

A patch applied by hand vanishes the next time CI runs composer install. I keep the patch files in the repo under patches/ and reapply them from a Composer hook:

"scripts": {
    "post-install-cmd": ["sh patches/apply-hotfixes.sh"],
    "post-update-cmd": ["sh patches/apply-hotfixes.sh"]
}

Adobe's patches touch many packages and even root files like nginx.conf.sample, so they do not fit the one-package-per-patch model of cweagans/composer-patches. A small shell hook is simpler. It must be idempotent once patches stack, which is harder than it sounds; the not-applying post has the version I run.

Verify the patch landed

bin/magento --version still says 2.4.9 after this, and it always will. Use Adobe's tool instead:

php vendor/bin/patch-status

This is trimmed output from this store after tonight's work:

{
    "base_version": "2.4.9",
    "applied_patches": [
        "249-2026-07-001-CE",
        "249-2026-08-001-CE",
        "249-2026-09-001-CE",
        "249-2026-10-001-CE",
        "249-VULN-39341-CE"
    ],
    "missing_patches": [],
    "vulnerability_status": {
        "CVE-2026-103849": { "status": "PROTECTED" },
        "CVE-2026-91013": { "status": "PROTECTED" },
        "CVE-2026-100133": { "status": "PROTECTED" },
        ...
    }
}

Then test the areas the patch touched, not just the homepage: admin email template preview, a customer account save, forgot password, a mass attribute update in the product grid, and a guest checkout. If something breaks, reverse with patch -R -p1 on the same file and follow my patch rollback recipe, but treat that as a short stop, not a place to stay.