Adobe shipped APSB26-92, its regularly scheduled Adobe Commerce and Magento Open Source security update, on August 11, 2026. The date is the sharp part. That is the same day Magento 2.4.6 reaches end of standard support, and one day before 2.4.5 loses its last cover, so for stores on those lines this bulletin is very likely the last security patch they will ever be handed. Adobe still listed 2.4.5 and 2.4.6 among the patched versions this round. Next month it almost certainly will not.
What APSB26-92 patches
APSB26-92 resolves critical, important and moderate vulnerabilities that could lead to code execution, security feature bypass and privilege escalation across Adobe Commerce and Magento Open Source. Adobe classes it a regularly scheduled update rather than an out-of-band emergency, and states it is not aware of any exploits in the wild for the issues it closes, per the Adobe security bulletin. The affected range is wide: every supported line from 2.4.4 through 2.4.9, each listed as the 2026-jul build and earlier, per Adobe's Commerce knowledge-base article. "No known exploit" is not "no urgency." Magento's attacker economy reverse-engineers these patches quickly, so the gap between a public bulletin and a working exploit has historically been short. The safe read is that the clock starts the day the diff goes public, which was August 11.
Isolated patch vs full Composer upgrade
APSB26-92 ships as isolated patch files only, with no Composer packages published alongside, so you apply the fix as a standalone patch instead of bumping your whole platform version. Adobe frames the isolated format as a lightweight way to apply critical fixes fast, without a full Composer-based update, per the knowledge-base article. For a Hyvä storefront, that distinction is the whole game. A full Composer upgrade drags in dependency changes that can break a customized theme, a third-party module or a payment integration, and each of those needs regression testing before it reaches production. An isolated security patch is a much smaller surface. It changes the vulnerable code and little else, so it is faster to test and faster to ship. The catch is that isolated patches must be applied sequentially and cumulatively per release line, so skipping months leaves gaps the next patch assumes are already closed. The discipline this rewards is applying every bulletin as it lands, not batching a quarter of them into one nervous deploy.
Which stores this bulletin leaves behind
Magento Open Source and Mage-OS stores on 2.4.5 or 2.4.6 can apply APSB26-92, but it is almost certainly the final bulletin that will cover them. 2.4.6 reaches end of standard support on August 11, 2026 and 2.4.5 reaches end of extended support on August 12, 2026, and Open Source has no extended-support tier to fall back on, as we laid out when those two lines hit their support cliff. Adobe Commerce customers on the same versions keep a cushion through paid extended support and the Quality Patches Tool. Open Source does not. So the next bulletin will patch 2.4.7, 2.4.8 and 2.4.9, and an Open Source store still sitting on 2.4.6 will read that release and find nothing addressed to it. Applying APSB26-92 is worth doing today, but on 2.4.5 or 2.4.6 it buys weeks, not safety. The real fix is the version jump underneath it.
What we would change this quarter
Apply APSB26-92 this week, then confirm you are actually covered rather than assuming the patch took. Three concrete moves follow. First, verify your instance has complete patch coverage instead of trusting that this one bulletin closed everything, using the coverage-check tooling Adobe points to in the bulletin's knowledge-base article. On a store that has applied patches unevenly across a year, that report is usually more honest than the team's memory of what shipped. Second, apply the isolated patch in staging and click through checkout, because even a small security diff can catch on a customized cart or a payment module, and an isolated patch is exactly the low-risk case where a fast staging pass costs almost nothing. Third, if you are on Open Source 2.4.5 or 2.4.6, book the upgrade to 2.4.9 now instead of treating this patch as the resolution, because the next bulletin will not include you. We fold patch cadence and version upgrades into our Magento and Hyvä builds, and we treat the coverage-verification step as systems and automation rather than a manual chore, since a store that patches by hand every month eventually misses one. Deferring is the expensive option. An unpatched, unsupported core is not a maintenance backlog item. It is a live security exposure with your customers' checkout data behind it.