Magento security patches: how to install and verify them

On the second Tuesday of every month Adobe ships security fixes for Adobe Commerce and Magento Open Source. In October 2026 they included BlockStrap, a vulnerability rated 10.0 that allows code execution on the store server without authentication. This time you could not update "as usual" with a single Composer command: monthly fixes now come as separate patch files, and they have their own rules. Here is what kinds of fixes exist, how to read a bulletin, how to install the patches and, most importantly, how to make sure they actually took effect.

The kinds of fixes

Adobe currently ships three kinds of security fixes, and mixing them up is dangerous.

• Security-only -pN releases (for example 2.4.8-p5). Under Adobe's policy they ship once a year for every supported release line and are installed through Composer. Each one includes every security fix released before it.
• Monthly isolated patches. They ship on the second Tuesday of the month (Patch Tuesday), between -pN releases. They are not Composer packages but code-diff files containing only the fixes for specific vulnerabilities. Bulletins label the fixed versions by month, for example 2.4.9-2026-oct.
• Out-of-band hotfixes. When a vulnerability is being attacked, or is about to be, Adobe releases a separate hotfix without waiting for the monthly cycle. That is what happened in September 2026 with CVE-2026-75650 (StyleSmuggler, bulletin APSB26-146).

One important detail: a hotfix is not part of the monthly patch. The October bulletin says explicitly that the CVE-2026-75650 hotfix has to be applied separately, in addition to the October fixes.

How to read an APSB bulletin

Adobe bulletins are named APSBYY-NNN and published in the Adobe Trust Center. Four things matter.

1. Priority. Priority 1 means act as soon as possible, within 72 hours; Priority 2 means within 30 days; Priority 3 is at the administrator's discretion. Priority is Adobe's assessment, not a guarantee: BlockStrap was rated Priority 2, yet Sansec researchers found four attack paths within a day.
2. CVSS. A score from 0 to 10. Anything above 9 is a reason not to wait until the end of the month.
3. "Authentication required to exploit?" If this column says "No", any visitor can attack the site without logging into the admin. These are the most dangerous vulnerabilities.
4. Affected and fixed versions, plus the notes: whether the B2B module is involved, and whether a hotfix from an earlier bulletin is required.

Step 0: staging and a backup

Adobe strongly advises installing patches on a staging environment first and having a recent backup. In practice that means:

• a copy of the store running the same Magento, PHP and module versions as production;
• a backup of the database and code before installing, on staging and on production;
• the store code in Git, so the patch is a separate commit you can roll back;
• a clear maintenance window and maintenance mode: bin/magento maintenance:enable before the changes and bin/magento maintenance:disable after.

Step 1: move to the latest -pN release

Isolated patches are tested only against the latest security-only release of their line. If the store runs 2.4.8-p2 and the latest is 2.4.8-p5, first update to p5 through Composer: change the Magento package version in composer.json, run composer update, then bin/magento setup:upgrade, bin/magento setup:di:compile and bin/magento setup:static-content:deploy. Check third-party modules for compatibility too: they are what usually breaks an update.

Step 2: apply isolated patches in order

Monthly patches are not cumulative: each one contains only its own fixes. If you skipped August and September, those go on first, then October. A new -pN release resets the chain, because it already includes all earlier patches.

• Download the files from repo.magento.com for your version; 2.4.6 and older require Composer access keys.
• The archive contains separate files per component: Community Edition, Adobe Commerce, B2B, Page Builder. Apply only the ones you have installed. The order for Adobe Commerce is CE and EE from the previous month, then CE and EE from the current month; B2B files come after CE and EE.
• On your own server and for Magento Open Source, put the file in the project root and apply it with patch -p1 < patch_name.patch (or -p2 if that fails), then flush the cache.
• On Adobe Commerce Cloud, put the files in the m2-hotfixes folder in the project root, commit and push, and the patch is applied during deployment. But if the fix has already arrived in a Cloud Patches update, do not apply the isolated patch: Adobe warns that this can cause installation failures.

We apply patches through the repository rather than directly on the server, for example with cweagans/composer-patches or a patches folder in the project. That way the patch survives the next composer install and shows up in the history.

Step 3: check that the patch actually took effect

This is the step people skip most often. A command that finished without errors does not mean the store is protected: the patch may have applied partially, a deployment may have overwritten it, or the wrong commit may have reached production.

• Commerce Version Tool. Adobe's tool for checking patches: php vendor/bin/patch-status from the project root. It lists applied_patches, missing_patches and a per-CVE status under vulnerability_status: PROTECTED, VULNERABLE or UNKNOWN. If php vendor/bin/patch-status --version cannot find the tool, the July 2026 patch that introduced it is missing.
• Quality Patches Tool on Cloud. Check an individual patch with vendor/bin/magento-patches -n status, filtered by the patch name; the status you want is "Applied".
• Check production. Run the check where the store actually runs, not only on staging, and compare the results.

An example of why this matters: on October 16 Adobe revised the October patch for 2.4.8-p5 but kept the same file name. For stores with the first version of the patch, the Commerce Version Tool may report UNKNOWN, and 248p5-2026-10-002-CE appears under missing_patches. According to Adobe, the first version already fixed the vulnerability itself, but the recommendation is to reverse the old file and apply the new one.

Step 4: test the store after installing

Security patches change the core, and BlockStrap, for example, was fixed in the email template engine. After installing, test what makes money:

1. The whole checkout: cart, shipping, payment with every connected method, the thank-you page.
2. Emails: order confirmation, registration, password reset. If emails stop arriving or arrive with empty blocks, the problem is in the templates.
3. Admin login, saving a product, custom modules and integrations (ERP, warehouse, CRM).
4. The var/log logs and web server logs in the first hours after the rollout.

If the store may have been compromised

If a vulnerability rated 9–10 was open while it was being attacked, a patch alone is not enough: it shuts the door but does not remove anyone who already got in. In that case we check the server for signs of compromise (new PHP files, changed templates, unknown admin users, JavaScript injected into checkout), and rotate the Magento encryption key and every related credential: integration tokens, payment gateway keys, admin passwords and server access.

Checklist

• Subscribe to Adobe bulletins and check them on the second Tuesday of every month.
• Keep the store on the latest -pN release of its line.
• Apply monthly patches and hotfixes in order, through the repository, on staging first.
• Verify the result with patch-status on production.
• After the rollout, place a test order and check the emails.

More on BlockStrap and the October bulletin in our news post.

We have been working with Magento for more than ten years and install security patches on our clients' stores every month. We can take this off your hands: find out which patches are missing, apply them on staging, test checkout and emails, roll out to production with a rollback plan and confirm the result with the Commerce Version Tool.

Sources: Adobe monthly isolated security patch policy, Adobe guide to applying an isolated patch, Adobe article on the APSB26-153 fixes, updated 2.4.8-p5 patch, APSB26-153 bulletin.