Magento 2.4.6 Support Ends August 11. Here's What That Actually Means for You.

On August 11, 2026, Magento 2.4.6 reaches the end of its regular support window. Depending on when you're reading this, that's a matter of days.

Most of the advice being published about this date says the same thing: support ends, upgrade now. That's correct as far as it goes, and completely unhelpful if you're eight days out with a heavily customized store and no staging environment. Nobody is completing a safe Magento upgrade in a week.

So this post covers two things that most of the coverage skips. First, the deadline does not mean the same thing for every store — and the difference is significant enough that some readers can stop worrying. Second, what to actually do if you're going to miss it, because "upgrade faster" is not a plan.

Adobe Commerce and Magento Open Source are not in the same position

This is the single most important distinction, and it's the one most commonly collapsed.

If you run Magento Open Source (self-hosted, no Adobe license): August 11 is a hard stop. After that date there are no further security patches, no bug fixes, and no vendor safety net for the 2.4.6 code base. Every vulnerability disclosed after that point is yours to assess and fix yourself.

If you're a licensed Adobe Commerce customer: you have an extended support period beyond the standard window that continues to deliver quality and security patches — running roughly another year for the 2.4.6 line, followed by a limited security-only transitional period. Extended support is not available for the Open Source code base.

So two stores running byte-identical Magento 2.4.6 can be in genuinely different risk positions on August 12, purely on the basis of licensing. Before you escalate this internally, confirm which one you are. We've seen teams burn two weeks of panic on an upgrade that had another twelve months of headroom — and, more often, the reverse: an Open Source store assuming it was covered because someone read an Adobe Commerce lifecycle page.

Check your license, not the version number.

What actually happens on August 12

Nothing. That's worth saying plainly, because the messaging around EOL dates sometimes implies a cliff edge that doesn't exist.

Your store does not stop working. It doesn't get slower. Nothing phones home and disables anything. If you'd told your customers nothing, they'd notice nothing.

What changes is your risk trajectory, and it changes gradually. Magento vulnerabilities are disclosed on a regular cadence — Adobe now ships isolated security fixes monthly as needed, plus aggregated bundles twice a year. Each of those cycles after August is a list of known, published vulnerabilities for which you receive no fix. Published is the operative word: disclosure tells attackers exactly where to look, and Magento stores are actively scanned for known CVEs. Historically, exploitation of publicly disclosed Magento vulnerabilities follows disclosure by days, not months.

The first month is a modest increase in exposure. Six months of accumulated unpatched CVEs is a materially different store.

There's also a compliance dimension that's easy to overlook. PCI DSS requires that critical security patches be installed within a defined window. Running a version for which patches are no longer issued makes that requirement structurally impossible to satisfy. If you take card payments and someone asks how you're meeting it, "we're on an unsupported platform" is not an answer that survives an audit — and if you have cyber insurance, it's worth reading how your policy treats unsupported software before you need to.

Your realistic targets

If you're upgrading, the version landscape as of now:

2.4.8 is the sensible target for most stores on 2.4.6. Adobe supports a direct upgrade — you don't need to install 2.4.7 as an intermediate step — and it buys you until April 2028. It's a mature line now on its fifth patch release, meaning the post-GA edge cases have largely been found by other people.

2.4.9 is a bigger jump than the version number suggests. It's a platform modernization rather than a stability release: native PHP MVC replacing Laminas MVC, Symfony Cache, HugeRTE replacing TinyMCE as the admin editor, and 560+ fixes. It also raises the infrastructure floor — PHP 8.4 or 8.5 (8.2 support is gone), MySQL 8.4 LTS or MariaDB 11.4. Those framework replacements are the most disruptive changes to Magento's internals since the Magento 2 launch, and extension compatibility is still catching up.

If you're already stretched by the deadline, go to 2.4.8. Take 2.4.9 as a planned project in 2027 when your extension vendors have caught up. Skipping a line is fine; running past your line's end-of-support date is not.

Don't forget the infrastructure that comes with it. A 2.4.6 → 2.4.8 upgrade isn't just a Composer command. Elasticsearch support was removed in 2.4.8 in favor of OpenSearch, PHP needs to be on 8.3 or 8.4, and both of those are server-side work that has to be scheduled alongside the code.

If you're not going to make it

Let's be realistic. A 2.4.6 to 2.4.8 upgrade on a store with a customized theme and fifteen extensions is typically a two-to-six week engagement including extension testing and a staged deployment. If you're reading this in the first week of August, you are not finishing before the 11th, and rushing it is how stores end up with a broken checkout during an unplanned Saturday deploy.

Missing the deadline is recoverable. Missing it without a plan is what turns into an incident. So:

1. Apply 2.4.6-p15 now, if you haven't. It's the final patch level for the line. Being fully patched up to the last available release is the cheapest thing on this list and a surprising number of stores aren't.

2. Get a written date in the calendar. Not "Q4," not "after peak." A start date, a target go-live, and a named owner. The stores that end up two years past EOL are almost never the ones that made a decision to defer — they're the ones that never made a decision at all.

3. Harden the perimeter while you're exposed. A WAF with Magento-specific rulesets in front of the store meaningfully raises the cost of opportunistic attacks against known CVEs. Cloudflare, Sucuri, or your existing CDN's ruleset — this is a days-not-weeks piece of work and it's genuine mitigation, not theatre.

4. Lock down the admin. Restrict /admin by IP where operationally possible, enforce 2FA on every account, rotate the admin path, and audit the user list for accounts belonging to people who left. A large share of real-world Magento compromises come through admin access rather than an exotic exploit.

5. Get monitoring on file integrity. If you're going to run unpatched, you need to know quickly when something changes. File integrity monitoring on app/, pub/, and vendor/, plus alerting on new admin users and modified payment configuration. Card skimmers on Magento typically inject into checkout templates or the database — catching that in hours instead of months is the difference between a bad week and a breach notification.

6. Verify your backups actually restore. Not that they run. That they restore, into a working environment, within a time you could tolerate. Test it before you need it.

7. Subscribe to Adobe's security bulletins anyway. You won't get patches, but you'll know what's been disclosed against your version — which tells you what to watch for and, sometimes, what to mitigate at the WAF layer.

None of this substitutes for upgrading. All of it substantially reduces the risk of the gap between now and when you do.

The decision worth making properly

There's a third option that gets skipped in most EOL coverage, and for some stores it's the right one: if your Magento build is old enough that the upgrade is effectively a rebuild, the honest question isn't "2.4.8 or 2.4.9" — it's whether Magento is still the right platform for the next five years.

That's not a case for leaving. Magento remains an excellent fit for large catalogs, complex B2B pricing, deep ERP integration, and businesses that need real control over their commerce logic. But a store on 2.4.6 with an unmaintained theme and abandoned extensions is going to face this same conversation again in 2028, and it's worth making that decision deliberately rather than by default.

Either way, the version you're on determines whether Adobe still ships you security patches. That's the whole of it. Everything else is scheduling.

If you're on 2.4.6 and unsure what your upgrade actually involves — how many extensions will break, whether your customizations survive, what the infrastructure work looks like — an audit takes days, not weeks, and it turns an open-ended worry into a scoped project with a number attached.

Emyrix handles Magento and Adobe Commerce upgrades, security hardening, and the emergency response for when things go wrong at the worst possible time. If you're on 2.4.6 and need a plan before the 11th, get in touch — or use our emergency support line if it's already urgent.

Support dates are drawn from Adobe's software lifecycle policy, which is the authoritative source and worth checking directly for your specific version and license type.