Magento Security Patch: APSB26-146 Zero-Day Checklist

· magento 2

Table of contents

If you run Magento or Adobe Commerce, last month's bulletin should have interrupted your week. Adobe's APSB26-146 fixes CVE-2026-75650, a flaw rated Priority 1 with a CVSS base score of 10.0 that can be exploited remotely without authentication and lead to arbitrary code execution. Adobe reports active exploitation in the wild. Here is what I would do about this Magento security patch, in order.

What happened

The facts I could verify:

  • The flaw is classified as CWE-1336, template engine injection, according to the Rave Digital write-up of the bulletin.
  • Affected (versions "2026-aug and earlier"): Adobe Commerce 2.4.4 through 2.4.9, Adobe Commerce B2B 1.3.3, 1.3.4, 1.4.2, 1.5.2 and 1.5.3, and Magento Open Source 2.4.6 through 2.4.9.
  • Search coverage of The Hacker News report says the fix is the VULN-39341 patch, that Adobe also asks you to rotate your encryption keys, and that Sansec saw zero-day exploitation start on September 4, 2026. I could not open that article myself, so confirm those details in Adobe's bulletin.

The authoritative source is Adobe's own bulletin: APSB26-146. Read it before acting on anything here.

Patch first, in staging then production

A zero-day that is already exploited changes the usual calendar. I would still test the hotfix in staging, but in hours rather than a sprint. Roughly:

# 1. Confirm your exact version
bin/magento --version
composer show magento/product-community-edition | grep versions

# 2. Apply the patch exactly as described in the Adobe bulletin
#    (patch file or composer-based, depending on your setup)

# 3. Rebuild and smoke test
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush

Then run through checkout, customer login and the admin. If you use the cloud or a managed host, ask them for written confirmation that the patch is applied rather than assuming.

Assume you may already be compromised

Because exploitation started before the patch existed, patching alone is not enough. Check for what an attacker with code execution would leave behind:

  • Files changed recently outside your deployments, especially under pub/, app/ and generated/.
  • New admin users, new integration tokens and unexpected cron jobs.
  • Injected JavaScript in CMS blocks, the core_config_data table (design head and footer scripts) and checkout templates, the classic place for payment skimmers.
  • Web server logs: unusual POST requests to unauthenticated endpoints around and after early September.
# Files modified in the last 45 days, excluding the usual noise
find . -type f -mtime -45 \
  -not -path "./var/*" -not -path "./generated/*" \
  -not -path "./pub/static/*" -not -path "./.git/*"

Compare against a clean copy from Composer or your Git history rather than trusting timestamps alone.

Rotate the secrets

Adobe asks for encryption keys to be rotated according to the coverage I found. Even if it did not, I would treat these as exposed after a possible code execution: the encryption key in app/etc/env.php, database and admin passwords, API and integration tokens, and payment gateway and SMTP credentials. Rotating the Magento encryption key also means re-encrypting stored values, so follow Adobe's documented procedure and take a backup first.

Plan for the new patch rhythm

Search results about the July bulletin (APSB26-73) say Adobe moved to a twice-monthly security schedule from July 14, 2026, with fixes on the second and fourth Tuesdays. If that holds, security work becomes a routine, not an event. What helps:

  • Keep a staging environment that matches production, with an automated smoke test.
  • Subscribe to Adobe's security bulletins and review them on the day they appear.
  • Keep your own customisations on supported extension points, so patches apply cleanly.
  • Know who can approve an emergency deployment, before you need one.

Harden the basics

None of this replaces patching, but it limits the damage when the next flaw arrives: restrict the admin URL by IP or VPN, run PHP-FPM as a non-privileged user, make the code directories read-only in production, use a WAF, and monitor file integrity. I covered more in my older post on Magento 2 security best practices.

Conclusion

The order is simple: patch, check for compromise, rotate secrets, then improve your process. A CVSS 10.0 flaw under active exploitation is not something to schedule for next quarter.

Sources: Rave Digital: APSB26-146, The Hacker News: Adobe patches Magento zero-day, OnTap Group: APSB26-73.

© 2026 Addeos