Magento 2.4.9 needs PHP 8.5, OpenSearch 3 and, for MariaDB users, version 12.3, and Adobe's own pages disagree on four of its requirements. This covers the upgrade order that 2.4.8-p5 makes possible, the commands Adobe documents, the library changes that break extensions, and the security patches a fresh 2.4.9 install still lacks.
Magento Open Source and Adobe Commerce 2.4.9 became generally available on May 12, 2026. Adobe supports it until May 31, 2029, a year longer than 2.4.8, whose standard support ends on May 31, 2028. Nothing forces the move this month, but the upgrade is bigger than the version number suggests. It moves the platform to PHP 8.5, lists OpenSearch 3 as the only search engine, asks MariaDB users for 12.3, and replaces several libraries that extensions are built on.
What follows is an order that keeps every step small, the commands Adobe documents, the changes people notice after the upgrade, and the security patches a fresh 2.4.9 install still needs.
What 2.4.9 Requires
Adobe's system requirements page, last updated on September 18, 2026, lists these versions for on-premises installations:
| Dependency | 2.4.8 at release | 2.4.8-p5 | 2.4.9 |
|---|---|---|---|
| PHP | 8.4, 8.3 | 8.4, 8.3 | 8.5 |
| Composer | 2.9.3+ | 2.10 | 2.10 |
| MySQL | 8.4 | 8.4 | 8.4 |
| MariaDB | 11.4 | 11.4, 11.8 | 12.3 |
| OpenSearch | 2.19 | 3 | 3 |
| Elasticsearch | 8.17 | 8 | not listed |
| RabbitMQ | 4.1 | 4.3 | 4.3 |
| ActiveMQ Artemis | not listed | 2 | 2 |
| Valkey | 8 | 8.1 | 9 |
| Varnish | 7.6 | 8 | 8 |
| nginx | 1.26 | 1.30 | 1.30 |
Redis does not appear in any of the three columns. Valkey does, and 2.4.9 adds a dedicated setting for it, bin/magento setup:config:set --cache-backend=valkey.
The middle column is the useful one. 2.4.8-p5, the latest 2.4.8 security release, already runs on the same Composer, MySQL, OpenSearch, RabbitMQ, ActiveMQ Artemis, Varnish and nginx versions as 2.4.9. Most services can therefore move while the code is still on 2.4.8, one at a time, which leaves only PHP, MariaDB and Valkey for the upgrade itself.
Where Adobe's Own Pages Disagree
Four requirements read differently depending on which Adobe page you open.
- PHP. The requirements table lists only PHP 8.5. The release notes say PHP 8.4 is allowed for upgrade purposes only and is not recommended for production, and that PHP 8.2 and 8.3 are no longer supported. Magento's own
composer.jsonat the 2.4.9 tag still accepts~8.3.0||~8.4.0||~8.5.0, so Composer will install 2.4.9 on PHP 8.3 without a word. A cleancomposer updateis not proof that your PHP version is supported. - Composer. The table says 2.10. The release notes describe 2.4.9 as compatible with Composer 2.x, including 2.9.
- RabbitMQ. The release notes add support for RabbitMQ 4.2 and call it a short-term path, while the table lists 4.3. For the long term Adobe recommends Apache ActiveMQ Artemis, which it supports on every release line from 2.4.6 to 2.4.9.
- Elasticsearch. The upgrade prerequisites page says 2.4.8 and later no longer support Elasticsearch. The OpenSearch migration page says on-premises installations continue to support it. The 2.4.8-p5 column still lists Elasticsearch 8, the 2.4.9 column does not, and 2.4.9 still ships an Elasticsearch 8 module.
This guide follows the requirements table, the most recently updated of these four pages, and plans on OpenSearch 3.
The Order That Keeps Each Step Small
- Get to 2.4.8-p5 first, together with the monthly isolated security patches released since. Adobe tests isolated patches only against the latest -p release, so this is also where you need to be to stay patched until the upgrade is done.
- Move the services both versions list. OpenSearch 3, Composer 2.10, RabbitMQ 4.3 or ActiveMQ Artemis 2, Varnish 8 and nginx 1.30 are supported on 2.4.8-p5 and on 2.4.9. If you still run Elasticsearch, switch to OpenSearch now and reindex while nothing else is changing.
- Switch PHP to 8.4. 2.4.8-p5 supports it, and it is the version Adobe allows for the upgrade itself.
- Handle the database. Adobe's requirements page tells MariaDB users to upgrade to 12.3 before upgrading to 2.4.9, yet the 2.4.8-p5 column lists only 11.4 and 11.8, so for a short while you run a combination the table does not cover. Rehearse that step on staging with a full checkout test. MySQL needs nothing, because both versions require 8.4. If your MySQL is still 8.0 on Amazon RDS, move it to 8.4 with a blue/green switch before anything else.
- Upgrade the code with the commands below.
- Move PHP to 8.5 and Valkey to 9, the two versions that only the 2.4.9 column lists.
Check Extensions Against the Libraries That Changed
Upgrades usually break in extensions rather than in Magento itself, and 2.4.9 changes more of the ground they stand on than a typical minor release. From the release notes and Adobe's list of backward-incompatible changes:
- Laminas MVC is removed and replaced by a native MVC implementation.
- The deprecated Zend_Cache component is replaced by Symfony Cache. Extensions that depend on Zend_Cache classes or interfaces have to move to the Symfony cache APIs.
- Symfony moves to 7.4 LTS, so custom classes that extend Symfony classes need matching type declarations and method signatures.
- The WYSIWYG editor moves from TinyMCE to HugeRTE, because TinyMCE 5 and 6 reached end of support and the license of TinyMCE 7 is incompatible.
web-token/jwt-frameworkmoves from version 3 to 4, a third-party OAuth library is replaced with native PHP code, and PHPUnit moves to 12.
One change appears in neither document. Magento 2.4.8 installs magento/magento-zf-db, which provides the Laminas\Db namespace. 2.4.9 no longer installs it and pulls in php-db/phpdb instead, which uses the PhpDb namespace and declares a conflict with laminas/laminas-db. An extension that requires laminas/laminas-db will stop composer update, and one that uses Laminas\Db classes without declaring them will fail when that code runs. The older Zend_Db classes that Magento's own MySQL adapter extends are still installed.
A few searches before the upgrade show how exposed your own code and third-party modules are:
# run from the Magento root while still on 2.4.8
grep -rlE 'Laminas\\(Mvc|Db)|Zend_Cache' app/code app/design
grep -rliE 'tinymce' app/code app/design
grep -rlE 'Laminas\\(Mvc|Db)|Zend_Cache' vendor --include=*.php | grep -vE '^vendor/(magento|laminas)/'
grep -lE 'laminas/laminas-db|magento/magento-zf-db' vendor/*/*/composer.json | grep -vE '^vendor/(magento|laminas)/'
Every file those commands list is a question for the extension's vendor or your developer, and it is far cheaper to ask it before the upgrade than after. Adobe Commerce licensees can also run Adobe's Upgrade Compatibility Tool, which is not offered for Magento Open Source.
Run the Upgrade
These are Adobe's steps for an on-premises Composer installation, with the build steps from its deployment guide placed where they belong. Take a real backup first. The built-in backup commands are deprecated, and Adobe points to binary backup tools such as Percona XtraBackup instead.
# once, if the plugin is not installed yet
composer require magento/composer-root-update-plugin ~2.0 --no-update
composer update
bin/magento maintenance:enable
# stop cron so no queue consumer runs during the upgrade
bin/magento cron:remove
# let the consumers work through what is already queued
bin/magento cron:run --group=consumers
# repeat until no 'bin/magento queue' process is left
ps aux | grep 'bin/magento queue'
cp composer.json composer.json.bak
# Adobe Commerce uses magento/product-enterprise-edition here
composer require-commerce magento/product-community-edition 2.4.9 --no-update
composer update
rm -rf var/cache/* var/page_cache/* generated/code/*
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush
bin/magento maintenance:disable
# Adobe's upgrade page ends before this, so put cron back yourself
bin/magento cron:install
The cron step is not optional. Adobe warns that starting the upgrade while asynchronous processes such as message queue consumers are running may corrupt data, which is why cron comes out before Composer runs.
What Changes for the Store
Most of the release is invisible, fixes to 666 issues in the core code. A few changes reach people directly.
- Headless storefronts and integrations. GraphQL now rejects, by default, requests with more than 10 aliases and queries longer than 1,048,576 characters. Both limits can be raised, and the alias limit sits under Stores > Configuration > Services > Magento Web API > GraphQL Input Limits. Run your PWA or mobile app against staging before you switch.
- CAPTCHA on the API. When CAPTCHA or reCAPTCHA is enabled for the Create Account form, creating an account through REST or GraphQL now has to pass the same check. reCAPTCHA also covers the
applyCouponsToCart,updateCustomer,updateCustomerV2andcontactUsmutations when it is enabled for the matching storefront forms. An app that creates accounts or applies coupons through the API has to send a token. - Admin sign-in. Admin users now configure only one of the store's enabled two-factor providers, and a new setting,
admin/security/minimum_password_length, enforces a minimum length for admin passwords. - Content editors get HugeRTE in place of TinyMCE. Check any custom editor plugins on staging.
- Carts at sign-in. A new Cart Merge Preference under Stores > Configuration > Sales > Checkout decides how a guest cart combines with a customer's saved cart. The default, Merge Quantities, adds the two together.
A Fresh 2.4.9 Is Not a Patched 2.4.9
The 2.4.9 package that Composer installs is the May release, and Adobe has changed how it ships security fixes since then. Between the -p releases it now publishes monthly isolated patch files, with no Composer packages alongside them. Each one builds on the ones before it, so they are applied in release order, and only on top of the latest -p release for your line. Security bulletins now describe the fixed state with a date, such as 2.4.9-2026-aug.
For a store upgrading now, that means the isolated patches from July onwards, applied in order, plus the hotfix for CVE-2026-75650 from bulletin APSB26-146. Adobe says that vulnerability has been exploited in the wild, lists 2.4.9-2026-aug and earlier as affected, and requires rotating the encryption keys as well as applying the patch. We walked through that hotfix and the key rotation when it came out.
On a Composer installation an isolated patch is applied from the Magento root with patch -p1 < file.patch, followed by a cache refresh. Each monthly patch also carries Adobe's Commerce Version Tool, which reports which patches are in place.
An upgrade changes the search engine, the cache backend and PHP underneath the store, which makes the week after it a good time to measure speed again. Magento 2 Speed Optimization starts with exactly that kind of audit.
Or read how we handle it in Magento 2 Speed Optimization.
Related Articles
How to Upgrade Magento 2 from 2.4.7 to 2.4.8
Keeping Magento current is critical for security, performance, and compatibility. This step-by-step guide walks developers through upgrading from Magento 2.4.7 to 2.4.8, covering system requirements, pre-upgrade checks, Git workflow, Composer commands, and post-upgrade validation.
MagentoHow to Disable OpenSearch Security in Magento 2 While Keeping It Private on Ubuntu
OpenSearch ships with SSL and authentication enabled by default, which can complicate Magento 2 integration in development or internal environments. This guide explains how to safely turn off OpenSearch security while restricting access to localhost using Ubuntu's firewall.
MagentoHow to Configure Varnish for Magento So It Stops Caching the Wrong Thing
Varnish in front of Magento serves anonymous pages without touching PHP. The wrong Varnish in front of Magento serves one shopper's cart to everybody, which is worse than having no cache at all. Magento generates its own configuration and most of the work is using that rather than something copied from a forum. This covers what the generated file refuses to cache and why, how invalidation actually works as a ban rather than a purge, the two ways it silently fails, and how to prove a page came from cache.