Magento 2.4.6 End of Life

Let's start with what doesn't happen, because this is where end-of-life dates get misunderstood in both directions. On 12 August 2026, a Magento 2.4.6 store looked exactly as it did the day before. Pages load, checkout works, orders come in. Nothing switches off. Anyone telling you your store will "stop working" is scaremongering.

What actually happens is quieter and, over time, worse. Under Adobe's published released-versions schedule, regular support for the 2.4.6 line, which originally shipped in March 2023, ended on 11 August 2026. From that date, routine security patches and quality fixes for Magento Open Source 2.4.6 stopped, while Adobe Commerce customers moved into extended support. Vulnerabilities found from then on are fixed for supported lines; on Open Source 2.4.6 you can no longer rely on a fix.

That has two practical consequences beyond the obvious hacking risk. First, the gap between your store and a patched store doesn't stay constant: it widens with every routine security bulletin Adobe releases for newer lines. Adobe can still choose to issue an emergency fix, as it did for CVE-2026-75650 in September 2026, but you cannot plan around that. Second, unsupported software that handles cardholder data can create PCI DSS compliance concerns. It's the kind of thing acquirers and assessors ask about, so assess it with your PCI assessor or QSA rather than assuming either way.

So the honest framing is this: 11 August 2026 was not the day your store broke. It was the day your store started accruing risk that routine patches no longer cover. The decision in front of you is not whether to upgrade. It is which version to upgrade to, and whether you do it on your own schedule or after an incident picks the date for you.

This is the part most coverage of the deadline gets wrong, and it decides how urgent your situation actually is.

Adobe offers an extended support window on the 2.4.6 line, running to 31 August 2027, followed by a security-only transitional period to 31 May 2028. If you read that and relaxed, check which product you are running first, because Adobe's lifecycle policy describes extended support for licensed Adobe Commerce customers. Nothing Adobe has published extends it to Magento Open Source.

If you run Open Source, the extended support headlines are not about your store. Routine patches for your line have stopped, so the gap between your store and a patched one widens with every bulletin Adobe publishes for newer lines.

There is a timing problem on top of that if you trade a November peak. Most stores freeze code at the end of October, so an upgrade that cannot land before the freeze usually waits until January, which means trading Black Friday and Christmas on an unsupported platform. We covered how that freeze works in the peak season security guide.

Before planning anything, confirm your exact version. Plenty of store owners are surprised by the answer. Either check the footer of your Magento admin panel, or run this from the Magento root directory on your server:

bin/magento --version

Note the patch level as well as the version, for example 2.4.6-p11 rather than plain 2.4.6. Being on a recent patch level is good news for your current security posture, but it doesn't change anything: every 2.4.6 patch level reached end of life together on 11 August 2026, including the last one.

And if the command comes back with 2.4.4 or 2.4.5: those lines are already past regular support. Everything in this article applies to you with the urgency turned up. You're not approaching the cliff edge, you're past it. On Magento Open Source, routine Adobe security bulletins since your line ended have gone to newer lines; Adobe Commerce customers on 2.4.4 and 2.4.5 are in a security-only period that ends on 31 May 2027.

From 2.4.6 there are two sensible destinations, and they suit different situations.

Option A: Magento 2.4.8 is the recommended default. It's the current stable long-term line, supported to 31 May 2028, which buys you well over a year of patched running before the next forced decision. Extension vendors have had time to confirm compatibility, which matters more than any other factor for upgrade speed. It is not a stack-free move from 2.4.6, though: per Adobe's system requirements, the latest 2.4.8 patch needs PHP 8.3 or 8.4, MySQL 8.4 or MariaDB 11.4 or later, and OpenSearch 3 or Elasticsearch 8. Every week you wait is another week unpatched, so the useful question is no longer whether you beat a deadline. It is how short you can make the exposure.

Option B: Magento 2.4.9 reached general availability on 12 May 2026 and is the biggest architectural shift in the 2.4.x line since 2.4.4: Valkey replaces Redis as the official cache backend, OpenSearch 3 is required, PHP moves to 8.5, the database to MySQL 8.4 or MariaDB 12.3, and over 560 issues were fixed. It offers the best longevity, supported to 31 May 2029, but check that every extension you run has a 2.4.9 and PHP 8.5 compatible release first. As of 14 October 2026 Adobe's released-versions page lists no 2.4.9-p1: its September and October 2026 security fixes came as isolated patch files (2.4.9-2026-sep and 2.4.9-2026-oct), alongside the VULN-39341 hotfix. If you're curious about what the new stack involves, we've covered the Magento 2.4.9 hosting requirements and published a full Magento 2.4.9 upgrade guide.

Our honest advice for most 2.4.6 stores now past the deadline: go to 2.4.8, and plan 2.4.9 as a considered move later, once the extension ecosystem has settled and the first patch rounds have landed. Jumping an already-late store straight onto a brand-new architectural line is how a short exposure quietly becomes a long one.

If there's one thing to internalise from this article, it's this: the single biggest variable in a Magento upgrade timeline is your third-party extensions. Not the core upgrade itself. Magento's own upgrade tooling is well-trodden. It's the payment modules, shipping integrations, search enhancements, page builders and the extension somebody installed in 2023 whose vendor has since disappeared.

So before you book a single day of development time, audit every extension on the store. For each one, establish: is there a version compatible with your target Magento release? Is the vendor still active? Is the extension actually still used, or is it dead weight that can simply be removed? Every unmaintained extension is a fork in the road: replace it, pay for custom compatibility work, or drop the functionality. Each fork adds days or weeks.

This is why the honest answer to "how long will our upgrade take?" is always "show me your extension list first." A store with eight well-maintained extensions is a very different project from a store with forty of mixed provenance. It's also why starting the audit this week costs you nothing and tells you almost everything about whether you can be supported again before the peak trading freeze. If the audit reveals a problem extension, you want to know now, not in the week before your code freeze.

A Magento version upgrade is never just application code. Each release line has its own system requirements: PHP version, search engine, cache backend, database. Moving up a line usually means moving the stack too. Per Adobe's system requirements, the latest 2.4.6 patch runs on PHP 8.1 or 8.2 with MariaDB 10.11; the latest 2.4.8 patch needs PHP 8.3 or 8.4, MySQL 8.4 or MariaDB 11.4 or 11.8, and OpenSearch 3 or Elasticsearch 8; 2.4.9 needs PHP 8.5, MySQL 8.4 or MariaDB 12.3, OpenSearch 3 and Valkey 9. We keep a current reference of the Magento 2 server prerequisites for each version if you want to check your target against your current server.

This is where upgrades quietly stall. The application work finishes on staging, and then it turns out the production host can't provide the required PHP version, or doesn't offer OpenSearch, or won't touch the cache backend. If your host can't run the target stack, no amount of application work gets you over the line. Confirm this before the project starts, not at deployment time.

The cleanest pattern we see is upgrading onto fresh infrastructure: build the target stack (correct PHP, search, cache, Varnish) on a new server, deploy and test the upgraded store there as staging, then cut over. You get a known-good environment, a genuine rollback path (the old server keeps running untouched), and no risky in-place stack surgery on a live store. That's exactly how our free Magento migration service works when it's paired with an upgrade, and it's the approach our managed Magento 2 hosting is built around: the stack is prepared for your target version before your code ever lands on it.

There's a twist of timing that makes this particular EOL date sting more than previous ones. Adobe published six Adobe Commerce security bulletins in 2025, and seven so far in 2026 including one out-of-band emergency fix (7 September). Most fall on the second Tuesday of a month: since July that has meant APSB26-73 on 14 July, APSB26-92 on 11 August, APSB26-138 on 8 September and APSB26-153 on 13 October, with the emergency APSB26-146 on 7 September. For supported Magento versions, that means security fixes arrive on a broadly predictable rhythm.

But that rhythm only reaches supported lines. Magento Open Source 2.4.6 is outside it: Adobe's September and October 2026 patch notes say Open Source merchants can only download patches for version 2.4.7 or later. October showed what that means. Adobe's October bulletin, APSB26-153, lists Open Source 2.4.6 as affected by an update whose most serious fix is rated critical, with a CVSS score of 10.0, yet the October patches for Open Source start at 2.4.7. Adobe says it is not aware of any exploits in the wild, but it is one more reason to plan the upgrade now. Attackers read security bulletins too. Every published fix is also a public description of a hole that may still exist on unpatched and unsupported stores.

Put simply: staying supported became more valuable at exactly the moment 2.4.6 stopped being supported.

You are past the deadline, so this is no longer a countdown. It is a plan to cut the exposure as short as you reasonably can, and to get it done before the peak trading freeze closes the window until January:

• This week: confirm your exact version (bin/magento --version). Start the extension audit: list every third-party extension, its vendor status, and its compatibility with 2.4.8. Pick your target version.
• This month: confirm your hosting stack meets the target version's requirements (PHP, search engine, cache backend), or arrange infrastructure that does. Run the upgrade on staging first, never directly on production. Resolve extension incompatibilities as the audit surfaces them, and put the store through real testing: checkout, payment methods, shipping rates, order emails, admin workflows.
• Before the freeze: plan and execute the production window, ideally a quiet trading period, with a tested rollback path. Most stores stop deploying at the end of October. Landing the upgrade before that is the difference between trading peak supported and trading it unpatched.

If the audit tells you the timeline doesn't work (too many problem extensions, no development resource available), then the fallback is to compress risk, not ignore it: harden the store, restrict admin access, put monitoring on the file system so an injection is caught in hours rather than months, and book the upgrade for the first realistic slot after peak. An upgrade in January that you have actually scheduled beats one you keep intending to do.

Honest framing first: a Magento upgrade is application work as well as hosting work. The extension audit, code compatibility and theme testing are Magento development tasks, done by your developer or agency, with our engineers working alongside them. What we take care of is the infrastructure half of the problem.

EveryHost provides UK Magento hosting where the stack (PHP, OpenSearch or Valkey, Varnish) is prepared for your target Magento version before your code arrives, with UK-based engineers who do this work every week. Our Magento migration service is free and carried out with minimum downtime, which makes the upgrade-onto-fresh-infrastructure pattern described above genuinely practical: we prepare the new environment and a staging copy, your developer or agency upgrades the store there with our engineers alongside, and the cutover happens with minimum downtime. Have a look at our Magento hosting plans to see what's included, or just call and describe your store. We'll tell you honestly what the upgrade involves.