Magento 2.4.9 : PHP 8.5, Symfony 7.4 et 580 bugs corrigés

Magento Open Source 2.4.9 est sorti le 12 mai 2026, en même temps que les patchs de sécurité 2.4.8-p5, 2.4.7-p10 et 2.4.6-p15.
C’est une version mineure mais elle embarque des changements d’infrastructure importants notamment sur PHP et Symfony et qui méritent d’y jeter un œil avant d’envisager une migration.

Ce qui change côté plateforme

C’est probablement le point le plus important pour les developpeurs. Magento 2.4.9 monte d’un cran sur toute la stack :

PHP 8.5 — c’est la version recommandée
Symfony 7.4 LTS — mise à jour majeure des dépendances Symfony du package magento/composer. Toutes les classes qui étendent des classes Symfony core ont été mises à jour (déclarations de types, signatures de méthodes). À surveiller si vous avez des extensions custom qui touchent à ces couches.
MariaDB 11.8 et 12.3 — c’est la combinaison testée et recommandée pour 2.4.9
OpenSearch 3, Valkey 9, RabbitMQ 4.2, nginx 1.28

Vérifiez vos classes qui héritent de composants Symfony (console).

Dépendances JS mises à jour

Pas mal de mises à jour de librairies front qui traînaient depuis longtemps :

jQuery UI → 1.14.1
jQuery Validate → 1.21.0
Uppy (upload fichiers) → 4.13.4
Less.js → 4.2.2
Moment Timezone → 0.5.43
chart.js → 4.5.0

Rien de révolutionnaire mais c’est toujours bon à prendre pour les corrections de sécurité embarquées.

La migration du cache : de Laminas vers symfony/cache

C’est le changement architectural le plus discret mais peut-être le plus impactant sur le long terme. Magento 2.4.9 introduit symfony/cache: ^7.4 comme nouvelle dépendance — et ce n’est pas anodin.

Pourquoi ce changement

Depuis la migration Zend Framework → Laminas, Magento utilisait laminas/laminas-mvc comme couche MVC et s’appuyait historiquement sur magento/zend-cache (un fork interne des anciennes classes Zend_Cache). Le problème : le projet Laminas MVC a été officiellement mis en retraite. Adobe a d’abord réagi dans les patchs 2.4.8-p5 / 2.4.7-p10 / 2.4.6-p15 en créant un fork Magento de laminas-mvc (magento/magento-zf-mvc) pour assurer la continuité.
Dans 2.4.9, la suite logique c’est d’adopter symfony/cache comme backend de cache moderne, en parallèle du passage à Symfony 7.4 LTS.

Ce que ça change concrètement

Pour la plupart des modules, pas grand-chose si vous passez par les abstractions Magento standard. Les classes \Magento\Framework\Cache\* continuent à exister et font le pont. Le magento/zend-cache est toujours là dans le composer.json de 2.4.9 pour la rétrocompatibilité.

En revanche, si votre code utilise directement les namespaces \Zend\Cache ou les classes Laminas cache, c’est le moment de migrer. Ces couches ne seront pas maintenues indéfiniment. La bonne pratique à adopter maintenant c’est d’injecter \Magento\Framework\Cache\FrontendInterface plutôt que d’instancier directement des backends de cache.

Pour les modules qui définissent leurs propres types de cache dans cache.xml, le fonctionnement ne change pas. C’est plutôt les modules qui manipulent des backends cache en direct (Redis, File, Database) via les anciennes classes Zend qui doivent être audités.

Côté REST API et GraphQL

C’est un gros morceau de ce release. Beaucoup de corrections sur la cohérence de l’API REST, notamment :

Les erreurs 500 sur requêtes malformées sont remplacées par des 400 propres (endpoints commandes, produits, créditmemo, etc.)
La validation de l’attribute_code est maintenant cohérente entre l’admin et l’API REST (le bug où l’admin acceptait les majuscules mais pas l’API est corrigé)
Correction du calcul de base_row_total et row_total dans les réponses commandes quand plusieurs articles identiques sont commandés
La pagination dans l’export stock salable quantity retourne maintenant un total_count correct (il était limité au page_size avant)
En GraphQL : la mutation clearCart est maintenant disponible dans Open Source (elle était réservée Adobe Commerce), et une nouvelle mutation clearWishlist fait son apparition
La gestion des médias produits via REST API en scope store ne remplace plus les médias hérités du scope global quand on omet le champ media_gallery_entries

Les patchs de sécurité : 2.4.6-p15, 2.4.7-p10 et 2.4.8-p5

Les trois patchs sont sortis le même jour (12 mai 2026) et partagent un socle commun de changements.

Ce qui est commun aux trois patchs

Corrections de sécurité APSB26-49 — les vulnérabilités couvertes par ce bulletin s’appliquent aux trois branches
OpenSearch 3 (dernière version mineure) — support ajouté sur les trois branches, la compatibilité OpenSearch 2 est maintenue
Valkey 8.1 LTS — nouveau backend cache supporté sur les trois branches
RabbitMQ 4.2 — la branche 4.1 arrive en fin de support en février 2026
Support API REST USPS — les anciennes « Web Tools APIs » USPS sont en cours de dépréciation côté USPS, les trois patchs préparent la transition
Fork Magento de laminas-mvc — suite au retrait du projet Laminas MVC officiel, Adobe maintient désormais son propre fork (magento/magento-zf-mvc) pour garantir la continuité des correctifs de sécurité

Ce qui est spécifique à chaque patch

2.4.8-p5 — en plus du socle commun : compatibilité MariaDB 11.8 (en complément de 11.4 déjà supporté) et support de Composer 2.9.x (étendu depuis la limite 2.2.x).

2.4.7-p10 — en plus du socle commun : compatibilité MariaDB 11.8 également. Notez que les versions 2.4.7 ou antérieures utilisant MariaDB 10.6 (EOS juin 2026) ou 10.11 (EOS février 2028) sont invitées à migrer vers une version compatible.

2.4.6-p15 — le socle commun, sans ajout de compatibilité MariaDB 11.8 (la branche 2.4.6 n’est pas validée pour cette version). Rappel : la 2.4.6 est en fin de support régulier le 11 août 2026 (voir section suivante).

Si vous n’êtes pas encore sur 2.4.9, ces patchs sont à appliquer rapidement — surtout pour le bulletin APSB26-49.

Cycle de vie des versions : jusqu’à quand êtes-vous supportés ?

C’est le bon moment pour faire le point. Adobe Commerce suit une politique de support de 3 ans à partir de la GA. Magento Open Source suit le même calendrier pour le support qualité, sans les extensions de support payantes.

Version	GA (sortie)	Fin support qualité	Fin support sécurité (EOS)
Adobe Commerce 2.4.6	14 mars 2023	11 août 2026	30 août 2027 (support étendu)
Adobe Commerce 2.4.7	9 avril 2024	31 mai 2027	TBD
Adobe Commerce 2.4.8	8 avril 2025	31 mai 2028	TBD

Quelques précisions importantes : le support étendu (qualité + sécurité une année de plus) est réservé aux clients Adobe Commerce, pas à Magento Open Source. Si vous êtes en Open Source sur 2.4.6, la fin du support qualité c’est août 2026 — soit dans moins de 3 mois au moment où j’écris ces lignes. La sécurité sera maintenue un peu plus longtemps mais sans correctifs qualité, vous roulez sur une version figée.

Autre point à surveiller : Adobe signale que les marchands sur 2.4.6 qui utilisent encore PHP 8.1 (EOS depuis 2025) ne peuvent plus garantir leur conformité PCI. PHP 8.2 arrive lui aussi en fin de vie fin 2026, ce qui posera le même problème en 2027 pour ceux qui seraient restés sur cette version.

Faut-il migrer vers 2.4.9 ?

Ça dépend vraiment de votre situation. Voilà comment je vois les choses selon les cas.

Projets existants en production

Non, pas maintenant. PHP 8.5 et Symfony 7.4 sont des changements d’infrastructure majeurs qui nécessitent un audit complet : modules tiers, extensions custom, classes qui héritent de Symfony… L’écosystème (modules marketplace, agences, intégrations) a besoin de quelques mois pour se mettre à jour. Mieux vaut appliquer les patchs de sécurité en attendant et planifier la migration quand les premiers retours terrain seront disponibles.

Nouveau projet à livraison rapide (moins de 3 mois)

Attendre encore un peu. C’est le jeu avec toute nouvelle mineure : les modules tiers prennent toujours quelques semaines à se valider sur la nouvelle version. Partir sur 2.4.8 est plus sûr pour un projet qui doit sortir vite — vous aurez plus de recul sur la compatibilité de votre stack.

Nouveau projet à livraison longue (6 mois à 1 an)

Là c’est une bonne base de départ. D’ici la livraison, l’écosystème sera à jour, PHP 8.5 sera bien établi et vous serez sur Symfony 7.4 LTS avec un horizon de support confortable. C’est le bon calcul pour un projet qui doit tenir dans la durée.

Les release notes complètes sont disponibles sur Adobe Experience League. N’hésitez pas à partager vos retours de migration en commentaire 🙂