El soporte de Magento 2.4.6 termina el 11 de agosto. Esto es lo que significa de verdad para usted.

El 11 de agosto de 2026, Magento 2.4.6 llega al final de su ventana de soporte regular. Según cuándo lea esto, es cuestión de días.

La mayoría de los consejos que se publican sobre esta fecha dicen lo mismo: el soporte termina, actualice ya. Es correcto hasta donde llega, y completamente inútil si está a ocho días con una tienda muy personalizada y sin entorno de staging. Nadie completa una actualización de Magento segura en una semana.

Así que este artículo cubre dos cosas que la mayoría de la cobertura se salta. Primero, la fecha límite no significa lo mismo para todas las tiendas, y la diferencia es lo bastante grande como para que algunos lectores puedan dejar de preocuparse. Segundo, qué hacer de verdad si no va a llegar, porque «actualice más rápido» no es un plan.

Adobe Commerce y Magento Open Source no están en la misma situación

Esta es la distinción más importante, y la que más a menudo se pasa por alto.

Si usa Magento Open Source (autoalojado, sin licencia de Adobe): el 11 de agosto es un corte en seco. A partir de esa fecha no hay más parches de seguridad, ni correcciones de errores, ni red de seguridad del proveedor para el código de 2.4.6. Cada vulnerabilidad divulgada a partir de ese momento es suya para evaluarla y corregirla.

Si es cliente de Adobe Commerce con licencia: tiene un periodo de soporte extendido más allá de la ventana estándar que sigue entregando parches de calidad y seguridad, de aproximadamente un año más para la línea 2.4.6, seguido de un periodo de transición limitado solo a seguridad. El soporte extendido no está disponible para el código de Open Source.

Así que dos tiendas con un Magento 2.4.6 idéntico byte a byte pueden estar en posiciones de riesgo realmente distintas el 12 de agosto, únicamente por la licencia. Antes de escalar esto internamente, confirme en cuál está. Hemos visto equipos quemar dos semanas de pánico en una actualización que tenía otros doce meses de margen, y, más a menudo, lo contrario: una tienda Open Source que daba por hecho que estaba cubierta porque alguien leyó una página del ciclo de vida de Adobe Commerce.

Compruebe su licencia, no el número de versión.

Qué pasa de verdad el 12 de agosto

Nada. Conviene decirlo sin rodeos, porque el mensaje que rodea a las fechas de fin de soporte a veces sugiere un precipicio que no existe.

Su tienda no deja de funcionar. No se vuelve más lenta. Nada llama a casa ni desactiva nada. Si no les hubiera dicho nada a sus clientes, no notarían nada.

Lo que cambia es su trayectoria de riesgo, y cambia gradualmente. Las vulnerabilidades de Magento se divulgan con una cadencia regular: Adobe publica ahora correcciones de seguridad aisladas cada mes según hace falta, más paquetes agregados dos veces al año. Cada uno de esos ciclos después de agosto es una lista de vulnerabilidades conocidas y publicadas para las que usted no recibe corrección. Publicadas es la palabra clave: la divulgación le dice a los atacantes exactamente dónde mirar, y las tiendas Magento se escanean activamente en busca de CVE conocidos. Históricamente, la explotación de vulnerabilidades de Magento divulgadas públicamente llega días después de la divulgación, no meses.

El primer mes es un aumento modesto de la exposición. Seis meses de CVE sin parchear acumulados son una tienda materialmente distinta.

También hay una dimensión de cumplimiento normativo que es fácil pasar por alto. PCI DSS exige que los parches de seguridad críticos se instalen dentro de una ventana definida. Ejecutar una versión para la que ya no se publican parches hace que ese requisito sea estructuralmente imposible de cumplir. Si acepta pagos con tarjeta y alguien le pregunta cómo lo cumple, «estamos en una plataforma sin soporte» no es una respuesta que sobreviva a una auditoría; y si tiene un seguro cibernético, conviene leer cómo trata su póliza el software sin soporte antes de necesitarlo.

Sus destinos realistas

Si va a actualizar, el panorama de versiones a día de hoy:

2.4.8 es el destino sensato para la mayoría de las tiendas en 2.4.6. Adobe soporta una actualización directa —no hace falta instalar 2.4.7 como paso intermedio— y le da hasta el 31 de mayo de 2028. Ahora es una línea madura, en su quinta versión de parche, lo que significa que los casos límite posteriores a la GA los han encontrado en gran parte otras personas.

2.4.9 es un salto mayor de lo que sugiere el número de versión. Es una modernización de la plataforma y no una versión de estabilidad: MVC nativo de PHP sustituyendo a Laminas MVC, Symfony Cache, HugeRTE sustituyendo a TinyMCE como editor del admin, y más de 560 correcciones. También sube el mínimo de infraestructura: PHP 8.4 u 8.5 (el soporte de 8.2 desaparece), MySQL 8.4 LTS o MariaDB 11.4. Esas sustituciones de framework son los cambios más disruptivos en las entrañas de Magento desde el lanzamiento de Magento 2, y la compatibilidad de las extensiones todavía se está poniendo al día.

Si la fecha límite ya le tiene al límite, vaya a 2.4.8. Tome 2.4.9 como un proyecto planificado en 2027, cuando sus proveedores de extensiones se hayan puesto al día. Saltarse una línea está bien; pasarse de la fecha de fin de soporte de su línea, no.

No olvide la infraestructura que viene con ello. Una actualización 2.4.6 → 2.4.8 no es solo un comando de Composer. El soporte de Elasticsearch se eliminó en 2.4.8 en favor de OpenSearch, PHP tiene que estar en 8.3 u 8.4, y las dos cosas son trabajo en el servidor que hay que programar junto con el código.

Si no va a llegar

Seamos realistas. Una actualización de 2.4.6 a 2.4.8 en una tienda con un tema personalizado y quince extensiones suele ser un proyecto de dos a seis semanas, incluidas las pruebas de extensiones y un deploy por fases. Si lee esto en la primera semana de agosto, no va a terminar antes del día 11, y precipitarlo es como las tiendas acaban con el checkout roto durante un deploy no planificado un sábado.

Pasarse de la fecha límite es recuperable. Pasarse sin un plan es lo que se convierte en un incidente. Así que:

1. Aplique 2.4.6-p15 ahora, si no lo ha hecho. Es el último nivel de parche de la línea. Estar completamente parcheado hasta la última versión disponible es lo más barato de esta lista, y un número sorprendente de tiendas no lo está.

2. Ponga una fecha por escrito en el calendario. No «Q4», no «después de la temporada alta». Una fecha de inicio, un objetivo de puesta en producción y un responsable con nombre. Las tiendas que acaban dos años pasado el fin de soporte casi nunca son las que tomaron la decisión de aplazar: son las que nunca tomaron ninguna decisión.

3. Refuerce el perímetro mientras está expuesto. Un WAF con reglas específicas para Magento delante de la tienda eleva de forma significativa el coste de los ataques oportunistas contra CVE conocidos. Cloudflare, Sucuri o el conjunto de reglas de su CDN actual: es un trabajo de días, no de semanas, y es mitigación real, no teatro.

4. Cierre el admin. Restrinja /admin por IP donde sea operativamente posible, obligue a 2FA en todas las cuentas, cambie la ruta del admin y audite la lista de usuarios buscando cuentas de gente que ya no está. Una parte grande de los compromisos reales de Magento entra por el acceso al admin y no por un exploit exótico.

5. Ponga monitorización de integridad de archivos. Si va a correr sin parches, necesita saber rápido cuándo algo cambia. Monitorización de integridad de archivos en app/, pub/ y vendor/, más alertas sobre usuarios de admin nuevos y configuración de pagos modificada. Los skimmers de tarjetas en Magento suelen inyectarse en las plantillas del checkout o en la base de datos: detectarlo en horas en lugar de meses es la diferencia entre una mala semana y una notificación de brecha.

6. Verifique que sus copias de seguridad se restauran de verdad. No que se ejecutan. Que se restauran, en un entorno que funciona, en un tiempo que podría tolerar. Pruébelo antes de necesitarlo.

7. Suscríbase a los boletines de seguridad de Adobe de todos modos. No recibirá parches, pero sabrá qué se ha divulgado contra su versión, lo que le dice qué vigilar y, a veces, qué mitigar en la capa del WAF.

Nada de esto sustituye a actualizar. Todo ello reduce sustancialmente el riesgo del intervalo entre ahora y cuando lo haga.

La decisión que conviene tomar como es debido

Hay una tercera opción que se salta la mayoría de la cobertura sobre el fin de soporte, y para algunas tiendas es la correcta: si su instalación de Magento es tan antigua que la actualización es en la práctica una reconstrucción, la pregunta honesta no es «2.4.8 o 2.4.9», sino si Magento sigue siendo la plataforma correcta para los próximos cinco años.

No es un argumento para irse. Magento sigue encajando de maravilla con catálogos grandes, precios B2B complejos, integración profunda con ERP y negocios que necesitan control real sobre su lógica de comercio. Pero una tienda en 2.4.6 con un tema sin mantener y extensiones abandonadas va a enfrentarse a esta misma conversación otra vez en 2028, y conviene tomar esa decisión de forma deliberada y no por defecto.

En cualquier caso, la versión en la que está determina si Adobe sigue enviándole parches de seguridad. Eso es todo. Lo demás es calendario.

Si está en 2.4.6 y no tiene claro qué implica de verdad su actualización —cuántas extensiones se romperán, si sus personalizaciones sobreviven, cómo es el trabajo de infraestructura—, una auditoría lleva días, no semanas, y convierte una preocupación abierta en un proyecto con alcance y un número asociado. Después de la actualización, el soporte de Magento con retainer es lo que evita que la próxima fecha de fin de soporte llegue por sorpresa.

Emyrix se ocupa de actualizaciones de versión de Magento y Adobe Commerce, refuerzo de seguridad y la respuesta de emergencia para cuando las cosas se tuercen en el peor momento posible. Si está en 2.4.6 y necesita un plan antes del día 11, escríbanos, o use nuestra línea de soporte de emergencia si ya es urgente.

Las fechas de soporte están tomadas de la política de ciclo de vida del software de Adobe, que es la fuente autorizada y conviene consultar directamente para su versión y tipo de licencia concretos.