Magento 2.4.6 End of Life: August 11, 2026 Is 24 Days Away. Here Are Your Options

What actually happens on August 11, 2026

Magento 2.4.6 reaches end of support on August 11, 2026, together with the extended support window for 2.4.5. For context, 2.4.4 extended support already ended on April 14, 2026, so after August there is exactly one generation of “old” versions left in support: none. Adobe publishes the schedule on its release planning page and the version list on the available versions page; endoflife.date/magento tracks the same dates in one table.

Nothing breaks at runtime on August 12. Your store loads, orders come in, cron runs. What changes is upstream. Since January 2026, Adobe ships security fixes on a new cadence: monthly isolated security patches plus one cumulative release every May, but only for supported lines. The final cumulative for 2.4.6 was 2.4.6-p15, released May 12, 2026 under bulletin APSB26-49. The July 14 isolated patch (bulletin APSB26-73, file 2-4-6-p15-jul-2026.zip) is very likely the last security fix the line will ever get. If you will still be on 2.4.6 for a few more weeks while you upgrade, apply that one now; I wrote a step-by-step guide in how to apply the APSB26-73 isolated patch.

Why “we will just risk it” does not survive contact with the CVE list

This is not a theoretical risk with a scary name. Look at what the final bulletin actually fixed. APSB26-73 (July 14, 2026) addressed 5 headline CVEs, including CVE-2026-48358: arbitrary code execution in the Webhooks component, scored 10.0 by NVD (9.1 by Adobe), and CVE-2026-48356, an unrestricted file upload rated 9.6. In merchant terms: the first lets an attacker run their own code on your server, the second lets them plant a script they can call later. Either one ends with your checkout skimmed or your database exfiltrated.

Vulnerabilities of this severity keep being found in Magento roughly monthly under the new cadence. And there is recent precedent for how fast disclosure turns into attacks: SessionReaper (CVE-2025-54236) went from security bulletin to mass exploitation in about six weeks. Bulletins are patch notes for defenders and roadmaps for attackers. A supported store closes the door the same day. An unsupported store leaves every future door open, permanently.

There is also the payments angle. PCI DSS requires you to install vendor security patches. Once the vendor no longer publishes patches for your version, that requirement has no clean answer, and the conversation with your QSA or acquirer gets uncomfortable. Running 2.4.6 past August 11 is not an automatic compliance failure, but it is a compliance risk you would have to explain, and after a breach it is a very bad look in writing.

Your four real options, compared

From 2.4.6 you have four realistic destinations. Here is the honest comparison:

A note on 2.4.9, which shipped as GA on May 12, 2026. It swaps out a lot of internals: Laminas MVC replaced with native PHP, Zend_Cache replaced by Symfony Cache, TinyMCE replaced by HugeRTE. Those swaps are good long-term, but each one is a surface where an extension can break, so a 2.4.6 to 2.4.9 move carries meaningfully more extension risk than landing on 2.4.8. If you go that route, read my write-up of the 5 universal 2.4.9 upgrade traps before you start.

And 2.4.7: do not land there. It was tempting a year ago; today it buys you eight months before its own end of support in April 2027, at nearly the same upgrade cost as 2.4.8. It is the worst deal on the table.

The recommended path: 2.4.6 to 2.4.8-p5, step by step

For most stores on 2.4.6 with a limited budget, 2.4.8-p5 is the answer. Regular support to April 11, 2028 means you will not think about this again for almost two years. Here is the shape of the work.

1. Audit before touching anything. List every extension and check whether the vendor ships a release compatible with 2.4.8 and PHP 8.3. This is where upgrade budgets are won or lost, so do it first, on paper, not mid-upgrade.

2. Plan the PHP move. 2.4.6 ran on PHP 8.1/8.2. 2.4.8 targets 8.3/8.4 (8.2 technically works, but plan for 8.3 or newer so you are not doing a second PHP migration in a year). In practice that means a new PHP-FPM pool or container, new opcache settings, and a compatibility pass over your custom code.

3. Run the upgrade on staging. The composer side is short:

# Pin the new version without resolving yet, then resolve everything at once
composer require-commerce magento/product-community-edition=2.4.8-p5 --no-update
composer update

# Take the site offline, run schema/data upgrades, recompile generated code
bin/magento maintenance:enable
bin/magento setup:upgrade
bin/magento setup:di:compile

# Rebuild frontend assets for your locale, then reopen
bin/magento setup:static-content:deploy -f en_US
bin/magento maintenance:disable

One line each: composer update pulls the new core and every compatible dependency; setup:upgrade applies database schema and data changes; setup:di:compile regenerates the dependency injection code the new version needs; static-content:deploy rebuilds CSS and JS for your theme.

4. Patch on top. 2.4.8-p5 is the May cumulative. The July isolated fix from APSB26-73 still goes on top of it; the procedure is the same one I documented in the isolated patch guide.

5. QA like you mean it. Full checkout with your payment sandbox, order emails, cron jobs, admin grids, any ERP or feed integrations, and a visual pass over the theme. Most post-upgrade incidents I get called into were catchable on staging.

6. Cut over. Repeat on production inside a maintenance window, with a database backup taken immediately before setup:upgrade.

What this actually costs

My rate is $25/hr and I quote real ranges, not “contact us”. From 2.4.6 to 2.4.8-p5:

For heavy builds I do a fixed $499 upgrade audit first: full extension and customization inventory, a firm quote, and a risk list you keep even if you hire someone else. For stores that want the whole thing handled, the $2,499 sprint covers audit, staging upgrade, extension fixes, QA, and cutover. You can sanity-check any quote you have received against my upgrade cost calculator, and the full scope of what I include is on the Magento upgrade service page.

The timeline math: why “this week” is literal

Today is July 18. The deadline is August 11. That is 24 days. A typical 2.4.6 to 2.4.8 upgrade takes 2 to 4 weeks elapsed, because staging QA and a scheduled cutover window dominate the calendar even when the billable hours are modest. Run the numbers backwards: staging upgrade this week, QA the following two weeks, production cutover in the first week of August, and you land with a few days of buffer before support ends. Start on August 1 instead, and your production cutover happens after the deadline, on an unpatched store, during whatever bulletin lands that month.

The Mage-OS escape hatch

There is a fourth door, for Magento Open Source stores only. Mage-OS 3.2.0, released July 14, 2026, is the community fork of Magento. It keeps an upgrade path that is friendlier to older-Magento codebases and actively backports security fixes, which makes it a real option when the blocker is Adobe’s upgrade treadmill or licensing pressure rather than the work itself. To be clear: moving to Mage-OS is still an upgrade project, not a free pass, and it is not available to Adobe Commerce license holders. If the idea appeals, I covered the mechanics in my Mage-OS upgrade guide.

What I would do

If it were my store on 2.4.6 today, the decision tree is short. Limited budget and a working store: go to 2.4.8-p5 now, it buys support until April 2028 for the least pain per hour. Due for a bigger refresh, or you need PHP 8.5: go to 2.4.9 with eyes open about extension breakage. Open Source and tired of the treadmill: Mage-OS. Under no circumstances 2.4.7, and under no circumstances nothing.

Sources: Adobe release versions, Adobe release schedule, APSB26-73 bulletin, Mage-OS 3.2.0 release notes, endoflife.date.