Summarize with AI

Google AI ChatGPT Perplexity Claude.ai Grok

Adobe Commerce 2.4.6 End of Support: What to Do Before 11 August

Key Takeaways:

• Adobe Commerce and Magento Open Source 2.4.5 and 2.4.6 both reach the end of support on 11 August 2026. The no-cost extended window for 2.4.5 ends then, and 2.4.6 regular support ends the same day with no extension available.
• Nothing breaks on 12 August. Stores keep trading. What stops is security patches, and that is the entire risk.
• The precedent is documented. When Magento 1 support ended in June 2020, more than 7,500 stores were compromised in a single coordinated campaign targeting known-unpatched versions.
• Adobe supports a direct upgrade from 2.4.5 or 2.4.6 to 2.4.8, skipping 2.4.7. Version 2.4.8 is supported through April 2028.
• With days remaining, an upgrade cannot be completed safely. The correct move this week is compensating controls plus a scheduled upgrade, not a rushed deployment over a weekend.

Introduction

Adobe Commerce and Magento Open Source 2.4.5 and 2.4.6 stop receiving security patches on 11 August 2026, and no store can complete a safe upgrade in the days that remain. That is the honest position.

Anyone promising a compliant upgrade inside this week is proposing to skip the extension audit and the regression testing that make an upgrade survivable.

The deadline is not a switch-off, though. Stores on unsupported versions carry on exactly as before. The problem is narrower than a shutdown and worse: from 12 August, any newly disclosed vulnerability affecting those versions stays public and stays unpatched.

This post covers what actually changes and what the realistic options are with days left. It also covers how to protect a store in the gap before a properly executed upgrade.

What Exactly Happens on 11 August 2026?

Three distinct things end, and it helps to separate them.

• Security patches stop: This is the material change. Adobe will no longer issue security fixes for 2.4.5 or 2.4.6. Any vulnerability disclosed after that date remains open on those versions permanently.
• Quality and bug fixes stop: Functional defects will not be addressed.
• Support entitlement changes: Adobe Commerce customers lose the entitlement to support for the platform version itself, although the underlying license does not expire.

What does not happen is equally worth stating plainly. The store does not stop working. Payments continue processing. Admin access continues. There is no license enforcement event and no forced shutdown.

The version landscape

Adobe supports upgrading directly from 2.4.5 or 2.4.6 to 2.4.8 without passing through 2.4.7. That direct path is what makes the work tractable rather than sequential.

Why Does an Unpatched Store Actually Get Attacked?

The reasoning is uncomfortable, but it is not complicated.

Security advisories are public. When Adobe patches a vulnerability in supported versions, the advisory describes what was fixed and which versions were affected. That advisory is a map.

It tells anyone who reads it precisely which weakness exists in every store still running an unsupported version and that those stores will never be fixed.

So an unsupported eCommerce platform is not vaguely riskier than a patched one. It sits on a list, and the list is public.

The Magento 1 end-of-life provides the documented case. Support ended in June 2020, and over 7,500 stores were compromised in one coordinated campaign.

Attackers did not need novel research. They needed known vulnerabilities on systems that would never be patched.

What Should Be Done This Week?

Five compensating controls, ordered by protection gained per hour spent. None of these replaces the upgrade. All of them reduce exposure during the gap.

1. Confirm the actual version, precisely
   Run bin/magento --version rather than trusting documentation or memory. Patch level matters, not just the minor version. A surprising number of stores discover they are on a different release than assumed.
2. Get a web application firewall in front of the store
   A managed WAF with commercial Magento rule sets blocks a meaningful share of opportunistic exploitation at the edge, and it can be deployed in hours rather than weeks. This is the single highest-value action available this week.
3. Lock down the admin surface
   Move the admin path off any predictable URL, enforce two-factor authentication for every account, restrict admin access by IP where operationally possible, and delete dormant accounts. Compromise frequently arrives through admin credentials rather than through platform code.
4. Verify backups by restoring one
   A backup nobody has restored is a guess. Restore one into staging and confirm the store actually comes up.
5. Turn on file integrity monitoring
   The characteristic Magento attack outcome is skimmer code injected into checkout templates or JavaScript. Integrity monitoring on the codebase and database triggers detects that class of change early, which limits how long card data is exposed.

A sixth item is worth adding for anyone processing cards directly: talk to the acquirer. PCI DSS obligations do not pause because a vendor ended support, and running unsupported software with known vulnerabilities is a compliance question as much as a security one.

The extension audit is the one step that decides whether this is a three-week or three-month project. We run it as a fixed scope before you commit to the upgrade.

Book a Call

What Does the Upgrade to 2.4.8 Actually Involve?

Realistic duration for a typical store is two to six weeks, driven almost entirely by extension count and customization depth rather than by catalogue size. The phases are well understood.

The pattern mirrors ERP upgrades closely, and so does the failure mode. As with the Odoo 18 to 19 upgrade, the work is set by custom code rather than by data volume. The cheapest phase is the inventory that most teams skip.

The extension audit deserves emphasis. A single abandoned extension with no compatible release forces a real decision: replace it, fork and port it, or rebuild the functionality. Discovering that in the staging phase rather than the audit phase is what turns a three-week project into a three-month one. Stores without in-house Magento capacity usually bring in Magento development services for the audit and the regression testing, because that is where the hours actually go.

Is This the Moment to Replatform Instead?

For some merchants, yes. A forced upgrade is a legitimate trigger to ask whether Magento is still the right platform, and answering honestly is more useful than defaulting either way.

Stay on Magento and upgrade when the catalogue is large and complex, when B2B features such as company accounts, quotes, and shared catalogues are in use, when heavy customisation reflects genuine competitive advantage, or when an in-house or partner team already knows the platform.

Consider replatforming when the store is comparatively simple and the customisation was largely incidental, when the extension estate has become unmaintainable, when operating cost is disproportionate to revenue, or when no team with Magento depth is available at all.

One caution against deciding under deadline pressure: replatforming is slower than upgrading, not faster. A migration to another platform is a multi-month project involving data migration, SEO preservation, and integration rebuild. It is a reasonable strategy and a bad emergency response. Merchants weighing it should close the security gap with an upgrade first, then replatform on their own schedule.

Stores that already run Odoo for inventory, fulfilment, or accounting have a further option worth scoping: tightening that integration rather than changing commerce platform. The Magento to Odoo integration patterns matter more to total operating cost than the storefront version does.

What Happens if Nothing Is Done?

Not an immediate incident, in most cases. That is precisely what makes inaction attractive and dangerous.

The realistic sequence is gradual. Week one passes without event. Then a vulnerability is disclosed and patched in supported versions, and the advisory tells attackers exactly what is available on unsupported ones. Automated scanning identifies vulnerable stores. Weeks or months later, a skimmer appears in checkout, or an admin account is used to place fraudulent orders, or customer data leaves quietly.

The cost then arrives in a bundle: incident response, forensics, card-brand penalties, notification obligations, and the reputational damage that follows a payment-data disclosure. Recovery costs more than the upgrade every time, and it turns up on the attacker’s schedule rather than yours.

The active Magento store count has already fallen substantially from its peak of roughly 162,000 in late 2021. Some of that decline is deliberate replatforming. Some store owners stopped maintaining their stores until something happened.

Conclusion

Adobe Commerce and Magento Open Source 2.4.5 and 2.4.6 lose security support on 11 August 2026. Stores keep trading afterward, so nothing appears to change. That appearance is the hazard, because published advisories turn unsupported versions into a list anyone can work through.

With days remaining, the honest advice is a two-track response. This week, deploy a WAF, lock down the admin surface, verify a real restore, and enable file integrity monitoring. Then schedule a properly tested upgrade to 2.4.8, which is supported through April 2028 and reachable directly from either version.

Do not attempt the whole upgrade before Tuesday. An untested upgrade that breaks checkout costs more in a single trading day than the scheduled project costs in total. Close the exposure this week. Do the upgrade properly after that.

Close the exposure this week. Upgrade to 2.4.8 when it can be tested properly. We do both, and we will tell you which comes first.

Contact Us

FAQs

Author

Chand Prakash

Chand Prakash founded CodeTrade India and continues to lead it as CTO, shaping the technical direction of the company since its early days. He has spent his career solving hard engineering problems and building teams that ship reliable software, with a focus on ERP, e-commerce, and custom enterprise platforms.