Adobe Commerce (Magento) 2.4.6 Released

Only for a few more weeks. Adobe's release lifecycle lists regular support for the 2.4.6 line ending on 11 August 2026, with 2.4.6-p15 released on 12 May 2026 as its latest patch. After that date, no further security patches are published for 2.4.6, so any newly disclosed vulnerability stays open on your store permanently. If you are reading this on a 2.4.6 installation, upgrade planning is not a next-quarter item, it is the current priority.

Either 2.4.8, released 8 April 2025 with regular support to 11 April 2028, or 2.4.9, released 12 May 2026 with support into May 2029. Going to 2.4.9 buys the longest runway but requires the biggest infrastructure jump. Going to 2.4.8 is a smaller step that still gets you supported for nearly two more years. Skipping to the newest release is usually right if you are already rebuilding the environment, since you only want to do the extension compatibility work once.

Substantial ones compared with 2.4.6. Adobe's supported stack for 2.4.9 is PHP 8.5, Composer 2.10, MySQL 8.4 or MariaDB 12.3, OpenSearch 3, Valkey 9, RabbitMQ 4.3, Varnish 8 and nginx 1.30. Since 2.4.6 shipped with PHP 8.1 and 8.2, Elasticsearch and Redis, that means moving several major versions across the whole stack at once. Budget for server work and extension testing, not just a Composer command.

Adobe moved the platform to OpenSearch, which began as a fork of Elasticsearch. The 2.4.8 line is the last one whose supported matrix still lists Elasticsearch 8, and the 2.4.9 matrix lists OpenSearch 3 with no Elasticsearch entry at all. Existing Elasticsearch installations keep functioning today, but they are on a path with no future support. Any upgrade or new build should move to OpenSearch, which in Magento terms is mainly a configuration and infrastructure change rather than a code one.

In the supported matrix, yes. Magento 2.4.9 lists Valkey 9 as the cache and session backend, where earlier releases listed Redis. Valkey is the community fork that continued from Redis's last open source release and speaks the same protocol, so Magento's cache, session and page cache backends work against it without code changes. In practice it is an image or package change rather than a rewrite, which makes it one of the easier parts of a 2.4.9 upgrade to get out of the way early.

The store keeps running and quietly accumulates unpatched vulnerabilities. That is not theoretical for Magento: Sansec found around 75 percent of Magento and Adobe Commerce stores were still unpatched a week after the fix for CosmicSting, tracked as CVE-2024-34102, and thousands were subsequently breached. On an unsupported version there is no patch to apply at all. You also lose compatibility with new PHP releases and gradually with extension updates, so the upgrade only gets harder and more expensive.

For a typical mid-market store, plan in weeks rather than days, and expect extension compatibility to consume most of it. The core upgrade itself is often straightforward. What takes time is auditing every third-party module for a compatible release, reworking customisations that touched changed core code, updating the server stack, regression testing checkout and payments, and rehearsing the deployment. Stores that skipped several releases take longer, which is the practical argument for upgrading regularly rather than in one large jump.

Yes, Magento upgrades do not require passing through each intermediate release, and going directly is usually more efficient than staging through 2.4.7 and 2.4.8. The work that scales with the size of the jump is testing and extension compatibility, not the upgrade command. Do it on a clone of production with real data, run the full purchase path end to end, and keep a rehearsed rollback plan. The one thing to avoid is upgrading the application and the server stack in separate uncontrolled steps.

Only if you need the licensed features. Live Search, Product Recommendations, several B2B capabilities such as company accounts and negotiated quotes, and Adobe's hosted services require an Adobe Commerce licence and are not part of Magento Open Source. If you need those, the licence can be cheaper than building equivalents. If you do not, Open Source on well-run infrastructure remains a legitimate long-term choice, and upgrading it is exactly the same technical exercise described here.

Watch Adobe's security bulletins and the release lifecycle page rather than waiting to hear about a problem. Adobe publishes patches on a scheduled cadence, with security-only patches issued between quality releases when needed. Build a routine: review each bulletin, decide within days rather than months, test on a staging clone, and deploy. The gap between a patch being published and being applied is precisely the window attackers use, and the CosmicSting figures show how wide that window usually is.

They shipped in 2.4.6 in March 2023 and have been carried forward in every later release, so they are long since standard rather than news. Reading an old release announcement is useful for understanding what changed when, not for deciding what to install. The current questions are which supported version you are moving to and what your infrastructure needs to become. Treat this page as a historical record with an upgrade warning attached rather than as current guidance.

Clone production, including a sanitised copy of the database, and upgrade that first. Sanitise before the data leaves production, since a raw dump contains customer names, addresses and order history and should not be sitting on laptops. Then run the real journeys: search, add to cart, checkout with your live payment method in sandbox, order emails, admin imports and any integration with an ERP or shipping provider. Containerised environments make this rehearsal cheap enough to repeat until the deployment is boring.