Chat on WhatsApp
Release notes · May 2026

Magento 2.4.9 Release Notes

Magento Open Source 2.4.9 shipped on 12 May 2026. It’s the biggest infrastructure jump since 2.4.0 — Adobe added PHP 8.5 support, swapped Redis for Valkey, moved to OpenSearch 3, and fixed 581 bugs. Here’s what changed and what it means for your store.

TL;DR

Should you upgrade to 2.4.9?

Four common situations, four honest verdicts. Find the card that matches your store.

  • Yes — if you’re on 2.4.8

    Smooth upgrade. Mostly point-release changes layered on top of three infra swaps (PHP, search, cache). Plan a 1–2 week sprint for QA. Most extensions work as-is. Get the staging build green, run Lighthouse on your top 10 URLs, smoke-test checkout, then ship.

  • Plan ahead — if you’re on 2.4.6 or 2.4.7

    You’re skipping multiple PHP versions and big infra jumps in one go: Redis → Valkey, OpenSearch 2 → 3, Symfony 6 → 7.4. 4–8 week project minimum. Don’t rush. Audit every custom module for PHP 8.5 compat first; then plan a hosting migration window; then run the Magento upgrade.

  • Hyvä stores — mostly fine

    Hyvä Themes + Hyvä Checkout work with 2.4.9. Tailwind + Alpine are untouched by the Symfony bump. One thing to retest: your Hyvä Checkout adapter for Braintree, because Adobe added 12+ payment changes including Google Pay vaulting, Apple Pay on Chrome and Firefox, and BLIK. Budget 1 extra week for Hyvä QA.

  • Adobe Commerce B2B — schedule a long window

    Schedule a longer testing window. Companies module, quotes, requisition lists, shared catalogues, negotiable quotes — test every single flow. New GraphQL mutations make headless B2B much easier, but they need full integration testing. 4–8 weeks for enterprise B2B. Don’t skip MFTF regression.

What changed

The 6 big changes in Magento 2.4.9

Plain English next to every technical term. If you only have 5 minutes, read these six.

  1. 01

    PHP 8.5 support · PHP 8.4 is now the minimum

    Adobe added PHP 8.5 runtime compatibility. PHP 8.3 is dropped. The Braintree extension and repo.magento.com now both run on PHP 8.5. Plain English: PHP is the programming language Magento is written in. If your server is on PHP 8.2 or 8.3 today, you upgrade PHP first (separate change, ~1 day), then upgrade Magento. Don’t bundle the two changes.

  2. 02

    OpenSearch 3 only · Elasticsearch is gone

    2.4.9 supports OpenSearch 3 only. Elasticsearch is removed as a search backend. If you still run Elasticsearch on 2.4.8, you must migrate to OpenSearch before the Magento upgrade. Plain English: OpenSearch is the AWS-maintained fork of Elasticsearch. They’re basically the same engine but with different licences. Adobe picked OpenSearch. Your category filters, product search, and admin grids all run through this.

  3. 03

    Valkey 9 replaces Redis

    Redis is deprecated. Adobe migrated to Valkey, an open-source Redis fork maintained by the Linux Foundation. Same wire protocol, same client API, but a different project (Redis changed its licence in 2024; Valkey stayed BSD). Most Magento Redis config keys (cache-backend-redis-server, etc.) work unchanged. Plain English: your cache + sessions + full-page-cache configuration stays the same — only the binary on the server changes.

  4. 04

    Symfony 7.4 LTS framework upgrade

    Magento’s underlying PHP framework jumped from Symfony 6.x to 7.4 LTS. Big change for custom modules that extend Symfony classes directly with strict type declarations. Plain English: Symfony is a PHP toolkit Magento uses under the hood (HTTP request handling, dependency injection, console commands). Most extensions never touch it directly, so most stores see zero impact. If your dev team extended Symfony classes (rare), expect to update method signatures.

  5. 05

    GraphQL mutations now in Open Source

    clearCart and clearWishlist mutations moved from Adobe Commerce-only to Open Source. Also new: exchangeExternalCustomerToken (auth bridge for headless storefronts using Auth0/Okta/Cognito), cart-merge config for guest→customer transitions, OOS product details visible in historical orders, and queries for applied customer groups / segments / cart rule IDs. Plain English: headless storefronts get real cart control without paying for Adobe Commerce.

  6. 06

    12+ Braintree payment enhancements

    Google Pay vaulting, Real Time Account Updater (auto-refresh expired cards), ELO card type, “Pay Upon Invoice” BNPL for German buyers, promo codes in Google/Apple Pay sheets, Apple Pay on Chrome + Firefox (not just Safari), server-side PayPal Express shipping callback, PayPal Contact Module (US), BLIK (Polish local method), and an updated CSP for 3-D Secure (Cardinal). Plain English: payments now work in more browsers, support more local methods, and renew expired cards automatically.

System requirements

2.4.8 → 2.4.9 stack comparison

What you run now (left) vs what you need (right). The rose pills are breaking changes.

Component Magento 2.4.8 Magento 2.4.9 Change
PHP 8.3 · 8.4 8.4 · 8.5 8.3 dropped
MariaDB 10.6 · 11.4 11.8 · 12.3 10.6 dropped
MySQL 8.0 8.4 8.0 dropped
Search engine OpenSearch 2 · Elasticsearch 8 OpenSearch 3 only Elasticsearch removed
Cache layer Redis 7 Valkey 9 Redis → Valkey
Message broker RabbitMQ 3.13 RabbitMQ 4.2 minor bump
Web server Nginx 1.24 Nginx 1.28 minor bump
Composer 2.7+ 2.9.3+ minor bump
Framework Symfony 6 Symfony 7.4 LTS BC change for type hints
New Relic agent 11.x 12.5.0+ minor bump
GraphQL

GraphQL improvements for headless storefronts

Four meaningful additions. clearCart and clearWishlist alone make 2.4.9 a real headless release.

  • clearCart mutation

    Bulk-remove every item from a cart in one call. Was Adobe Commerce-only; now in Open Source. Huge for headless storefronts that need to rebuild cart state on logout, payment error, or session expiry without looping over removeItemFromCart one item at a time.

  • clearWishlist mutation

    Bulk-empty a customer’s wishlist in one call. Same code path as clearCart. Useful for “clear all” UI on a wishlist page, and for B2B flows that move wishlist items into a quote.

  • exchangeExternalCustomerToken

    Bridge authentication from an external identity provider (Auth0, Okta, AWS Cognito) to a Magento customer token in one call. Removes the JWT roundtrip workaround most agencies have to write today. Plain English: if a customer logs in to your headless storefront with Okta, you can now hand the Okta token to Magento and get a Magento session back. One request instead of three.

  • Cart-merge config + B2B extras

    New admin toggle for guest→customer cart merging, historical orders now include out-of-stock product details, a new OrderTotal.grand_total_excl_tax field, and queries for the applied customer groups, customer segments, and cart-rule IDs on an order (handy for B2B headless apps that need to show why a customer got a price).

Security

Security improvements

Subresource Integrity, two-factor auth, and CAPTCHA all get useful upgrades. Nothing exotic — just less friction for the right people and more friction for bots.

  • SRI hash storage per area/theme/locale

    Subresource Integrity hashes (cryptographic fingerprints of every JS/CSS file Magento serves) are now stored in separate files per admin/storefront × theme × locale. Faster page loads (fewer hashes parsed per request), less memory, easier rollback when a single locale’s asset changes. Plain English: SRI is what stops a hacked CDN from injecting malicious JS into your store — this change makes that protection faster.

  • 2FA flexibility for admin

    Admin users now only need one enabled 2FA provider instead of every available provider. Smaller agencies finally get a workable 2FA flow without forcing every admin to enable Google Authenticator + Duo + U2F simultaneously. Plain English: you can now pick the 2FA method that fits your team and stop fighting Magento about it.

  • CAPTCHA / reCAPTCHA on more APIs

    Both REST and GraphQL account-creation endpoints now enforce CAPTCHA. Closes a fraud-bot vector that was scraping customer accounts via the API while the storefront form was protected. Plain English: bot signups via API are now blocked the same way bot signups via the website are blocked.

  • reCAPTCHA on more GraphQL mutations

    updateCustomer, updateCustomerV2, and contactUs mutations now validate reCAPTCHA. Spam-form mitigation for contact forms and a small but useful improvement against account-takeover scripts that try to update customer email or password.

Performance

Performance improvements

Smaller wins than the big infra swaps, but they add up — especially in admin.

  • Media Gallery on-demand tree

    The admin Media Gallery no longer loads the full folder tree at boot. Folders expand on click. Stores with 10k+ media assets save many seconds on every admin page that opens the gallery (product edit, CMS page edit, category edit, email template edit).

  • SRI per-area files

    Only the SRI hash file relevant to the current area/theme/locale is loaded per page. Less JavaScript parsing on every storefront request — small win per page, large win across a session.

  • Analytics cron jobs optimised

    Fewer queries, less DB lock contention on the cron group that fires hourly. Stores running Adobe Commerce Intelligence (formerly MBI) see noticeably less “background DB pressure” on busy hours.

  • File export uses temp files

    Partial downloads no longer leave a half-written export visible in the admin. Plain English: if a CSV export crashes halfway, customer-service staff don’t accidentally download the broken file and email a partial customer list. Cleaner CI/CD audit logs too.

JS / npm

JavaScript / npm upgrades

The JavaScript libraries Magento ships in package.json for the Luma admin + storefront.

  • Uppy 4.13.4 File upload
  • jQuery Validate 1.21.0 Form validation
  • jQuery UI 1.14.1 Admin widgets
  • Less.js 4.2.2 LESS compilation
  • Moment Timezone 0.5.43 Date / timezone
  • Underscore.js 1.13.7 JS utility lib
  • Chart.js 4.5.0 Admin dashboards
  • Allure PHPUnit 3.x Test reporting

These are deps Magento ships in package.json for the Luma admin + storefront. Hyvä uses Tailwind + Alpine so most of these are unused on Hyvä storefronts.

Watch out

Backward-incompatible changes

Three things that can break a 2.4.9 upgrade if you skip the prep work. Read these before you start.

  • Symfony 7.4 type declarations

    Custom modules that extend Symfony core classes (rare but real for big agencies) need updated : string / : void / : array return-type hints. Check var/log/exception.log after staging deploy for must be compatible with errors. Plain English: Symfony 7.4 enforces stricter type rules — if your custom code told Symfony “trust me” before, you now have to spell out the types.

  • Redis → Valkey migration

    Old config keys (cache-backend-redis-server) still work because Valkey speaks the Redis wire protocol, but the underlying binary, monitoring tools, and managed cloud offerings change. AWS still ships ElastiCache Redis; GCP MemoryStore has Valkey in preview; Azure Cache for Redis is unaffected. Plain English: plan your hosting carefully. Your app code probably doesn’t change at all, but your infra ticket might.

  • OpenSearch 2 → 3 reindex

    OpenSearch 3 changed the index mappings for analyzers; you must reindex catalogsearch_fulltext after the upgrade. Plain English: budget the indexer-run time during your deploy window. A 50k-SKU store reindexes in 5–15 minutes; a 1M-SKU store can take an hour. Run it during low-traffic hours.

By the numbers

Bug fix counts

581 issues fixed across the codebase. Where the work went, in eight buckets.

  • 581 Issues fixed (total)
  • 45+ Admin UI
  • 35+ Cart & Checkout
  • 30+ Catalog
  • 20+ APIs
  • 16+ Account
  • 6+ Analytics
  • 4+ Security

Counts are rounded from Adobe’s release notes. Full diff: 581 total commits.

Upgrade path

How to upgrade to 2.4.9 — 5 steps

Same five-step pattern I run for every paid upgrade. Audit first, plan second, build third. No surprises.

  1. 01

    Audit

    Run bin/magento module:status for the full extension list. Check each vendor’s 2.4.9 compat statement. Run composer why-not php 8.5 to find any module pinned to an older PHP. List every custom module that extends a Symfony class. Note the current Redis and OpenSearch versions. Ship the audit as a written doc — it’s your project brief.

  2. 02

    Plan

    Map the PHP upgrade path (8.2 → 8.4 → 8.5, or 8.3 → 8.4 → 8.5). Plan the Valkey migration window (most cloud providers swap with zero downtime). Plan the OpenSearch 3 reindex window. Stand up a staging environment that mirrors production hosting (same PHP, same DB, same cache binary). Get sign-off before touching production.

  3. 03

    Staging build

    On staging: composer require magento/product-community-edition 2.4.9 --no-update, then composer update. Run setup:upgrade --keep-generated first to spot DB issues fast, then a clean setup:di:compile and setup:static-content:deploy -f en_US. Tail var/log/exception.log the whole time.

  4. 04

    QA + performance benchmark

    Run Lighthouse on your top 10 URLs (homepage, top 3 categories, top 5 PDPs, checkout). Run MFTF regression. Manually test the full checkout flow on every payment method. Test the admin daily-driver flow (product edit, order ship, customer edit). For B2B: test companies, quotes, requisition lists end-to-end.

  5. 05

    Production cutover

    Blue-green deploy ideally (two environments, traffic-switch). If not: short maintenance window (DB indexes, OpenSearch reindex, Valkey cutover), then post-deploy smoke test. Watch var/log/exception.log for 24 hours. Roll back at the first sign of trouble — never “debug live” under load.

Hyvä compatibility

Hyvä Themes + Hyvä Checkout work with 2.4.9

Hyvä Themes (storefront) and Hyvä Checkout are both confirmed compatible with Magento 2.4.9. The Tailwind + Alpine stack is untouched by Symfony 7.4 or the Valkey swap because Hyvä runs in PHP-rendering land, not the admin or JavaScript chain. One thing to retest: your Hyvä Checkout adapter for Braintree if you accept Google Pay or Apple Pay — Adobe added 12+ Braintree changes including Apple Pay on Chrome and Firefox. Hyvä Compatibility Module 9.x+ is the recommended baseline.

FAQ

Magento 2.4.9 — frequently asked questions

  • When was Magento 2.4.9 released?
    Adobe released Magento Open Source 2.4.9 on 12 May 2026.
  • Should I upgrade from 2.4.8 to 2.4.9?
    Yes if you're on 2.4.8 and have around 1 to 2 weeks for QA. The change list is mostly point-release improvements plus three infrastructure jumps (PHP, search engine, cache backend) that need a hosting plan. Most actively-maintained extensions will have 2.4.9 builds within 2 to 4 weeks of release.
  • Does Magento 2.4.9 still support PHP 8.3?
    No. PHP 8.4 is the minimum and PHP 8.5 is supported. PHP 8.3 is dropped. Upgrade PHP first (separate change, around 1 day of work), then upgrade Magento.
  • Do I still need Redis or do I need Valkey?
    Valkey 9 is the officially supported cache backend in 2.4.9. Redis 7 may keep working in practice because Valkey speaks the Redis wire protocol, but Adobe's test matrix targets Valkey now. Long-term, plan a migration. Most cloud providers can swap with zero downtime.
  • Can I skip from 2.4.7 straight to 2.4.9?
    Technically yes, via composer require magento/product-community-edition 2.4.9. Practically, only if your custom modules and extensions cleanly support PHP 8.5 plus Symfony 7.4. Most 2.4.7-era extensions need updates. Budget 4 to 8 weeks for a clean skip-version upgrade.
  • Are my extensions compatible with 2.4.9?
    Check each vendor's release notes. The Magento Marketplace listing shows the minimum Magento version. Most actively-maintained extensions have 2.4.9 builds within 2 to 4 weeks of release. Abandoned extensions need either a replacement or a custom patch.
  • Does Hyva Themes work with 2.4.9?
    Yes. Hyva storefront and Hyva Checkout are both 2.4.9-compatible. The Tailwind + Alpine stack is untouched by the Symfony 7.4 framework bump or the Valkey swap. Re-test the Braintree adapter if you accept Google Pay or Apple Pay, because Adobe added 12+ Braintree changes including Apple Pay on Chrome and Firefox. Hyva Compatibility Module 9.x or higher is the recommended baseline.
  • What about Elasticsearch — can I keep it?
    No. Elasticsearch is fully removed in 2.4.9 as a supported search backend. You must migrate to OpenSearch 3 before you can run the Magento upgrade. OpenSearch is the AWS-maintained fork of Elasticsearch with the same query API, so the migration is usually a data copy plus a config change, not an application rewrite.
  • How many bug fixes are in 2.4.9?
    581 issues are fixed across APIs, admin UI, cart, catalog, B2B, analytics, security, and account management. The biggest categories are Admin UI (45+), Cart and Checkout (35+), and Catalog (30+).
  • What's the cost and timeline to upgrade to 2.4.9?
    Typical: $2k to $15k and 2 to 6 weeks for a mid-complexity store on 2.4.8. Bigger stores (20+ extensions, custom checkout, B2B flows) run $20k to $80k and 6 to 12 weeks. Use the upgrade-cost calculator at /magento-upgrade-cost-calculator for a fast estimate based on your actual store profile.
  • What's deprecated in 2.4.9?
    The legacy escaper class (replaced with constructor injection in the modern code path), the carlos-mg89/oauth library (replaced with native PHP OAuth functions), and Allure PHPUnit's native dependency. None of these affect a typical store at runtime, but they affect custom modules that reference the deprecated classes directly.
  • What's next after 2.4.9?
    Adobe has not announced a public roadmap for 2.5.x at the time of writing. Expect security-patch releases (2.4.9-p1, -p2, etc.) roughly every 3 months. Quarterly patches matter for PCI compliance — sign up for Adobe's security advisories so you don't miss them.
Upgrade quote

Planning a 2.4.9 upgrade?

Get a no-pressure quote in 24 hours. I’ve shipped 200+ Magento upgrades. Audit first, plan second, build third — no surprises.