Magento 2.4.8: la actualización más completa del ciclo 2.4.x
Adobe Commerce y Magento Open Source 2.4.8, lanzados en abril de 2025, representan la actualización más significativa dentro del ciclo 2.4.x. No se trata solo de correcciones — esta versión trae mejoras estructurales en rendimiento, seguridad y soporte de infraestructura que impactan directamente en la operativa de cualquier proyecto de desarrollo ecommerce sobre Magento.
Para los equipos técnicos, los cambios en dependencias (PHP 8.3 como mínimo, compatibilidad con MySQL 8.4 y OpenSearch 2.x) marcan un punto de inflexión que obliga a revisar la infraestructura de hosting.
Nota de actualización (julio 2026): este artículo se publicó cuando Magento 2.4.8 acababa de llegar. El análisis de la versión sigue siendo válido, pero el ecosistema ha avanzado: Adobe publicó Magento 2.4.9 el 12 de mayo de 2026 y desde enero de 2026 los parches de seguridad siguen una cadencia mensual. Hemos añadido secciones con el contexto actual y recomendaciones de actualización revisadas.
Julio 2026: dónde queda 2.4.8 hoy y qué trae 2.4.9
Un año después de su lanzamiento, Magento 2.4.8 ha pasado de ser la versión más reciente a ser la penúltima. El 12 de mayo de 2026 Adobe publicó Magento Open Source y Adobe Commerce 2.4.9, acompañado del boletín de seguridad APSB26-49. Es una de las versiones más ambiciosas del ciclo 2.4.x: moderniza componentes del framework, eleva los requisitos de PHP y base de datos, y acumula más de 500 correcciones ya desde la beta. Analizamos sus implicaciones estratégicas en nuestro artículo sobre el futuro de Adobe Commerce en 2026.
El calendario de soporte quedó así: la rama 2.4.8 tiene soporte regular hasta abril de 2028 y la 2.4.9 hasta mayo de 2029. Hacia atrás, 2.4.7 llega hasta abril de 2027, mientras que 2.4.5 y 2.4.6 agotan su soporte en agosto de 2026 — es decir, en cuestión de semanas desde la última revisión de este artículo. Si tu tienda sigue en una de esas versiones, la ventana para planificar la actualización con calma se está cerrando.
En cuanto a requisitos, 2.4.9 da el salto a PHP 8.4, exige OpenSearch 3.x en instalaciones nuevas y adopta Valkey (el fork abierto de Redis) como backend de caché y sesiones de referencia. MySQL 8.4 y MariaDB 11.4 completan el cuadro. Son cambios de infraestructura de calado, en la misma línea de lo que 2.4.8 inició con PHP 8.3: cada versión mayor del ciclo 2.4.x es, en la práctica, también un upgrade de plataforma de hosting.
Soporte para PHP 8.3 y actualización del stack
Magento 2.4.8 establece PHP 8.3 como versión mínima requerida, dejando atrás PHP 8.1 que ya está fuera de soporte activo. Esto trae mejoras de rendimiento nativas del lenguaje — las typed class constants, el json_validate() nativo y las mejoras en el readonly de clases reducen overhead y mejoran la robustez del código.
A nivel de base de datos, la compatibilidad con MySQL 8.4 y MariaDB 11 asegura que el stack completo está alineado con versiones con soporte activo. Para búsqueda, OpenSearch 2.x se consolida como alternativa a Elasticsearch, lo que es relevante para quienes operan en entornos cloud donde Elasticsearch tiene costes de licencia.
Mejoras de rendimiento en indexación y checkout
El indexer de precios, históricamente uno de los cuellos de botella en tiendas con catálogos grandes y múltiples customer groups, ha recibido optimizaciones significativas. La reindexación parcial es ahora más eficiente y los tiempos de procesamiento se han reducido notablemente en catálogos de más de 50.000 SKUs.
El checkout también mejora con optimizaciones en las consultas de base de datos durante el proceso de pago, reduciendo tiempos de carga en tiendas con muchas reglas de precio activas. Se ha mejorado el manejo de sesiones para reducir los problemas de carritos que se vaciaban inesperadamente.
GraphQL: cobertura ampliada
Para proyectos headless o con frontends desacoplados (PWA Studio, Vue Storefront, Next.js Commerce), la cobertura de la API GraphQL se ha ampliado para cubrir más operaciones del catálogo y del checkout, reduciendo la necesidad de llamadas REST complementarias. El rendimiento de las queries de catálogo también ha mejorado, con mejor uso de caché y optimización de los resolvers.
Más de 150 correcciones de seguridad
La versión incluye un paquete masivo de correcciones de seguridad, actualizaciones de dependencias y mejoras en la gestión de tokens de API. Se ha reforzado el rate limiting en endpoints sensibles y mejorado la protección contra inyecciones en formularios del backend.
Para tiendas que manejan datos de pago o volúmenes significativos de transacciones, mantener Magento actualizado no es opcional. Cada versión menor que se retrasa acumula deuda de seguridad que después cuesta más remediar.
Migración desde versiones anteriores
La migración a 2.4.8 desde 2.4.6 o 2.4.7 es relativamente directa, pero el salto a PHP 8.3 requiere verificar que todos los módulos de terceros y el código personalizado sean compatibles. Recomendamos ejecutar la migración en staging con tests funcionales completos antes de ir a producción.
Si tu Magento está en una versión anterior y estás valorando la actualización, en Keliam podemos evaluar el impacto, planificar la migración y ejecutarla con el mínimo riesgo para tu operación.
Parches de seguridad en 2026: cadencia mensual y el precedente SessionReaper
El cambio operativo más importante desde la publicación original de este artículo no es una versión, sino un proceso: desde enero de 2026 Adobe publica parches de seguridad aislados con cadencia mensual, con un esquema de nombres predecible (2.4.9-2026-jul, 2.4.8-2026-jul, etc.). El más reciente a fecha de esta actualización es APSB26-73, publicado el 14 de julio de 2026, que cubre todas las ramas con soporte activo, desde 2.4.4 hasta 2.4.9, e incluye Adobe Commerce B2B.
Para los equipos técnicos esto es una buena noticia con letra pequeña. La buena: los parches son más pequeños, más frecuentes y más fáciles de aplicar que los antiguos paquetes acumulativos. La letra pequeña: ya no vale la estrategia de actualizar «cuando toque la versión anual» — hay que tener un proceso mensual de revisión y aplicación de parches, con su ventana de despliegue y sus pruebas mínimas.
El caso que justifica esa disciplina es SessionReaper (CVE-2025-54236): una vulnerabilidad crítica en la API REST de Magento, con CVSS 9.1, divulgada en septiembre de 2025 y explotada activamente pocas semanas después contra tiendas sin parchear. Las tiendas que tenían proceso de parcheo aplicaron el hotfix en días; las que no, engrosaron las estadísticas de robo de sesiones y skimming de tarjetas. Dedicamos un análisis completo a este tema en nuestra guía de seguridad en Magento 2: hardening, parches y buenas prácticas.
¿En qué versión deberías estar en 2026?
Con el mapa de soporte actual, la recomendación depende de tu punto de partida:
Si estás en 2.4.5 o 2.4.6: actualiza ya. El soporte termina en agosto de 2026 y, a partir de ahí, cada boletín mensual de Adobe será una lista de vulnerabilidades conocidas para las que tu tienda no tiene parche. En ecommerce, operar sin parches de seguridad no es una opción defendible ni ante PCI DSS ni ante tus clientes.
Si estás en 2.4.7: tienes hasta abril de 2027, pero conviene planificar el salto en el segundo semestre de 2026. Saltar a 2.4.8 es el movimiento conservador (stack PHP 8.3, cambios moderados); saltar directamente a 2.4.9 amortiza mejor el esfuerzo de testing si tus módulos de terceros ya son compatibles con PHP 8.4.
Si estás en 2.4.8: estás en zona cómoda hasta abril de 2028. Mantén la cadencia mensual de parches y planifica 2.4.9 (o su sucesora) para 2027 sin urgencia.
Si montas tienda nueva: directamente 2.4.9, con OpenSearch 3 y Valkey desde el primer día. Y antes de decidir infraestructura, revisa nuestra comparativa Adobe Commerce Cloud vs on-premise, porque el modelo de despliegue condiciona tanto los costes como el calendario de parches.
El stack de infraestructura que viene: PHP 8.4, OpenSearch 3 y Valkey
La transición de dependencias que 2.4.8 inició con PHP 8.3 se ha acelerado. En 2.4.9, PHP 8.4 es la versión de referencia, OpenSearch 3.x sustituye a las ramas 2.x en instalaciones nuevas (con reindexado obligatorio por cambio de formato de índices) y Valkey toma el relevo de Redis como backend oficial de caché tras el cambio de licencia de este último. Quien gestione su propio hosting debe presupuestar estas migraciones como parte del upgrade, no como extras.
La contrapartida es rendimiento: PHP 8.4 rinde mejor en cargas típicas de Magento que 8.1/8.2, OpenSearch 3 mejora tiempos de indexación y búsqueda en catálogos grandes, y el indexer de precios sigue afinándose versión a versión. Si tu tienda pelea con catálogos de decenas de miles de SKUs, te interesa nuestra guía de optimización de rendimiento en Magento 2 para catálogos grandes; y si operas varias marcas o mercados desde una misma instalación, la de gestión multitienda en Magento 2.
GraphQL y headless: cómo ha evolucionado desde 2.4.8
La apuesta por GraphQL que destacábamos en 2.4.8 se ha consolidado como la dirección oficial de la plataforma. En 2.4.9, la cobertura de la API sigue creciendo — más operaciones de carrito, checkout y cuentas de cliente resolubles íntegramente por GraphQL — y el rendimiento de los resolvers mejora en catálogos con navegación por capas compleja. Para proyectos nuevos, la pregunta ya no es si la API cubre el caso de uso, sino si el frontend desacoplado compensa el coste operativo de mantener dos stacks.
En el ecosistema, el movimiento relevante de estos dos años ha sido la madurez de Hyvä como alternativa pragmática: un theme que sustituye el frontend Luma heredado sin desacoplar la arquitectura, con mejoras drásticas en Core Web Vitals y una fracción del esfuerzo de un headless completo. PWA Studio, en cambio, ha perdido tracción, y quienes van a headless hoy suelen hacerlo con Next.js u otros frameworks sobre la API GraphQL. Nuestra recomendación práctica: headless solo cuando hay una razón de negocio concreta (múltiples canales, apps nativas, equipos frontend independientes); para el resto, Hyvä sobre una instalación bien optimizada da mejor retorno.
Sea cual sea el frontend, la API es ahora superficie de ataque de primer orden: el caso SessionReaper explotaba precisamente la API REST. Rate limiting, tokens de vida corta y revisión periódica de permisos de integración deben formar parte del mantenimiento, no del incidente.
Cómo planificar el upgrade sin romper la tienda
Da igual si el salto es de 2.4.6 a 2.4.8 o de 2.4.8 a 2.4.9: los upgrades de Magento que salen mal fallan casi siempre por las mismas causas, y casi nunca por el core. El proceso que seguimos en Keliam tiene cinco pasos:
El paso que más se subestima es el primero: la auditoría previa. Antes de tocar composer hay que saber qué módulos de terceros hay instalados, cuáles tienen versión compatible con el PHP de destino, qué parches locales se aplicaron a lo largo de los años y qué personalizaciones tocan checkout o precios. El segundo punto crítico son las integraciones: ERP, pasarelas de pago, logística y marketing se prueban con casos reales en staging, porque un upgrade puede cambiar contratos de API o comportamientos de colas sin que nada «parezca» roto. Tenemos un repaso completo en la guía de integraciones clave en Magento 2.
Y después del despliegue, el trabajo no termina: la cadencia mensual de parches convierte el mantenimiento en un proceso continuo. Si tu equipo no puede asumirlo, un servicio de mantenimiento ecommerce con SLA es más barato que el primer incidente serio.
Errores comunes que vemos en auditorías de upgrade
1. Módulos abandonados. Extensiones compradas hace años cuyo vendor ya no publica versiones compatibles. Detectarlo en la auditoría previa da margen para sustituirlas; descubrirlo a mitad de upgrade lo bloquea todo.
2. Parches locales sin documentar. Fixes aplicados directamente en vendor o via cweagans/composer-patches que nadie registró. El upgrade los pisa y el bug «resuelto» en 2023 reaparece en producción.
3. Saltarse el staging con datos reales. Probar con una base de datos de juguete oculta los problemas de indexación, memoria y tiempos que solo aparecen con el catálogo y el histórico de pedidos reales.
4. No probar el flujo de pago completo. El checkout puede renderizar perfectamente y aun así fallar en la captura, el 3DS o la notificación asíncrona de la pasarela. Cada método de pago se prueba de punta a punta.
5. Quedarse en una versión EOL «porque funciona». Funciona hasta que deja de hacerlo: sin parches mensuales, cada CVE publicada es un manual de instrucciones para atacar tu tienda concreta.
Preguntas frecuentes
¿Hasta cuándo tiene soporte Magento 2.4.8?
El soporte regular de la rama 2.4.8 termina en abril de 2028. Hasta entonces recibe los parches mensuales de seguridad de Adobe, incluidos los de Magento Open Source.
¿Puedo saltar de 2.4.6 a 2.4.9 directamente?
Sí, técnicamente el upgrade directo es posible y suele ser preferible a encadenar dos migraciones. Eso sí, el salto acumula todos los cambios de stack (PHP 8.1→8.4, OpenSearch, Valkey), así que la fase de auditoría y testing debe ser proporcionalmente más exhaustiva.
¿Qué pasa si me quedo en una versión sin soporte?
La tienda sigue funcionando, pero deja de recibir parches de seguridad. Cada vulnerabilidad nueva queda sin corregir, el cumplimiento PCI DSS se complica y la prima del seguro de ciberriesgo (si lo hay) sube. Es deuda técnica con interés compuesto.
¿Cuánto tarda un upgrade típico de Magento 2?
Entre 3 y 8 semanas según el número de módulos de terceros, personalizaciones e integraciones. La mayor parte del tiempo no es el upgrade en sí, sino la compatibilización de módulos y los tests funcionales.
¿Magento Open Source recibe los mismos parches que Adobe Commerce?
Sí, los boletines de seguridad mensuales (como APSB26-73) cubren tanto Adobe Commerce como Magento Open Source en todas las ramas con soporte activo. La diferencia está en las funcionalidades (B2B, staging de contenido, soporte de Adobe), no en la seguridad del core.
Conclusión
Lo que en su día contamos sobre 2.4.8 sigue siendo cierto: cada versión del ciclo 2.4.x es más que un conjunto de correcciones — es una actualización de plataforma que toca PHP, base de datos y buscador. Lo que ha cambiado en 2026 es el ritmo: con 2.4.9 ya disponible, 2.4.5/2.4.6 a semanas de su fin de soporte y parches de seguridad mensuales, mantener Magento al día ha dejado de ser un proyecto anual para convertirse en un proceso continuo.
Ese enfoque de mejora continua es el mismo que pide cualquier marco serio de seguridad — de PCI DSS a la certificación ISO 27001 — y el mismo que aplicamos en los proyectos que mantenemos. Si no sabes en qué estado está tu Magento, una auditoría de seguridad con pentesting te da el diagnóstico; y si lo que necesitas es no volver a pensar en parches, hablemos.
🚀 ¿Necesitas ayuda con tu proyecto Magento?
En Keliam somos especialistas en Adobe Commerce y Magento open-source. Migración, optimización, desarrollo de módulos y soporte continuo.
- Desarrollo Ecommerce — soluciones e-commerce a medida
- Desarrollo y Mantenimiento Magento — especialistas en tu plataforma
- Auditoría Técnica Web — análisis de rendimiento y seguridad
