September and October 2026 brought three Adobe Commerce security releases, an actively exploited zero-day and a critical PHP update. If you look after several stores, the hard part isn’t understanding each advisory; it’s making sure every store gets the right fixes in the right order. Here’s the summary I’d work from.
Key takeaways
- Four security releases in six weeks: APSB26-146, APSB26-138, APSB26-153 and PHP 8.x.
- Order: StyleSmuggler hotfix, then the scheduled releases, then PHP.
- Keep an inventory, patch through Composer, fail loudly, verify the deployed code.
- Put a WAF in front of every store; it is the only protection during a zero-day.
The releases
| Date | Release | Priority | What it fixes |
|---|---|---|---|
| 7 Sep 2026 | APSB26-146, hotfix VULN-39341 | 1 (exploited in the wild) | StyleSmuggler, CVE-2026-75650: unauthenticated code execution, CVSS 10.0. |
| 8 Sep 2026 | APSB26-138, September security release | Scheduled | Critical, important and moderate issues across 2.4.4–2.4.9. Isolated patches for 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 and 2.4.4-p18. |
| 13 Oct 2026 | APSB26-153, October security release | 2 | 11 CVEs, 5 critical, including BlockStrap (CVE-2026-103849, CVSS 10.0), a B2B authorisation flaw (CVE-2026-92909, 9.8) and stored XSS issues. |
| 21 Oct 2026 | PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 | Security | Two remote code execution flaws in PHP itself (CVE-2026-109618, CVE-2026-109619), CVSS 9.2. |
The order I’d apply them
- StyleSmuggler hotfix first, because it was exploited in the wild. Then check the store for compromise; the hotfix doesn’t remove an existing infection.
- The scheduled September and October releases (APSB26-138 and APSB26-153). If you move straight to a
2026-octbuild, confirm in Adobe’s release notes that it includes September’s fixes. KeepVULN-39341applied alongside them. - PHP, on every runtime the store uses, and restart PHP-FPM, Apache and long-running workers.
Doing it across many stores
- Keep an inventory. Every store’s Magento version, patch level, PHP version and hosting type, in one place. When an advisory lands, you should know within minutes which stores are affected.
- One patch process for all of them. Patches applied through Composer, committed to Git, deployed through the normal pipeline, never by hand on a server.
- Fail loudly. A patch that doesn’t apply must break the build, not print a warning.
- Verify the deployed code, not the configuration: check for the actual changed lines after deployment.
- Put a WAF in front of every store. During a zero-day, edge rules are the only protection available.
- Harden the runtime so the next bug does less damage: restricted PHP functions,
noexectemporary directories, least-privilege file ownership. - Plan upgrades, not just patches. Older release lines need licences or third-party backports for fixes, and PHP 8.2 ends on 31 December 2026. Staying current is what keeps patching simple.
Security patching is unglamorous, repetitive work. That’s exactly why it should be a process with checks at every step, rather than something that depends on someone remembering.
