El 11 de agosto de 2026, Adobe dejó de publicar parches de seguridad para Magento 2.4.5 y 2.4.6.
Si tienes una tienda en cualquiera de esas dos versiones, esto es lo que pasó ese día: nada. El sitio arrancó. Los pedidos entraron. El checkout funcionó. El panel de administración cargó exactamente igual que la semana anterior. No apareció ningún banner, no llegó ningún email, y nada en la aplicación le dijo a nadie que las condiciones habían cambiado.
Esa es la trampa, y vale la pena ser preciso sobre el porqué.
Qué es lo que realmente se detuvo
El fin del soporte no desactiva el software. Lo que termina es el flujo de correcciones que llega hasta ti.
Antes de esa fecha, cuando un investigador revelaba una vulnerabilidad en Magento, llegaba un parche. Lo aplicabas, y la ventana entre la divulgación y la exposición se medía en días. Después de esa fecha, para esas dos versiones, la divulgación sigue produciéndose — el parche no. Cada CVE registrado contra 2.4.5 o 2.4.6 a partir de ahora queda abierto para siempre, sea cual sea su severidad.
Hay un segundo detalle que toma por sorpresa a quienes usan específicamente Magento Open Source. Los clientes de Adobe Commerce han tenido históricamente acceso a acuerdos de soporte extendido. Open Source no tiene ese nivel. No hay nada que comprar, ninguna extensión de pago que negociar, ningún account manager enterprise al que llamar. El fin del soporte regular es, sencillamente, el final.
Y si estás en 2.4.5, la situación es anterior al mes pasado: esa línea salió del soporte estándar en agosto de 2025. Los comerciantes que leyeron "2.4.5 y 2.4.6" como un único evento de 2026 llevan, en el caso de 2.4.5, un año funcionando sin parches.
La asimetría que hace que esto salga caro
Una tienda en funcionamiento tiene exactamente el mismo aspecto esté parcheada o no. Esa simetría es lo que hace que el riesgo sea difícil de percibir y fácil de aplazar.
La asimetría está del lado del atacante, y va en una sola dirección:
- La divulgación es pública. Las bases de datos de vulnerabilidades, los avisos y las notas de versión son abiertos. El mismo documento que le dice a un defensor qué corregir le dice a un atacante qué buscar.
- Detectar la versión es trivial. Las instalaciones de Magento se pueden identificar a escala desde fuera. Nadie necesita adivinar qué tiendas están en qué versión; se puede enumerar.
- El parche es el mapa. Cuando llega una corrección para una versión con soporte, el diff describe la vulnerabilidad con precisión. Los atacantes leen los parches de las líneas con soporte y aplican ese conocimiento a las que no lo tienen, donde el mismo código sigue ejecutándose y no llegará ninguna corrección.
- La brecha solo se agranda. La ventana de exposición de una tienda con soporte se cierra cada vez que aplica parches. La de una tienda sin soporte no tiene ningún mecanismo de cierre. Cada mes suma y nada resta.
Por eso "todavía no hemos tenido ningún problema" es una afirmación sobre los últimos doce meses y no una previsión. Lo que cambió en agosto no es la probabilidad de que un ataque concreto tenga éxito — es que el remedio ya no existe.
PCI DSS convierte una cuestión de seguridad en una de cumplimiento
Si tu tienda acepta pagos con tarjeta, el debate deja de girar en torno al apetito de riesgo y pasa a girar en torno a un estándar que ya te has comprometido a cumplir.
PCI DSS exige que los sistemas dentro del alcance tengan aplicados los parches de seguridad vigentes. No es una aspiración vaga del estándar — la gestión de parches es un requisito explícito, y una plataforma sin soporte es el caso de manual de no poder cumplirlo. No puedes aplicar un parche que no existe, y "el proveedor ya no lo publica" no es un control compensatorio aceptado. Es precisamente la razón por la que se exigiría un control compensatorio.
De ahí se derivan algunas cosas que los comerciantes suelen entender mal:
- Ser SAQ A no vacía tu alcance. Llevar los campos de la tarjeta a un iframe alojado o al JavaScript de un proveedor de pagos reduce lo que manejas, pero la página que carga ese script sigue siendo tuya. Si la plataforma que la sirve está comprometida, el script se puede sustituir. Ese es exactamente el mecanismo detrás de años de incidentes de skimming digital, y es la razón por la que el estándar presta ahora atención a la integridad de la propia página de pago.
- "Pasó el escaneo" dice menos de lo que parece. Un escaneo ASV informa de lo que detecta. No es una declaración de que tu plataforma tenga soporte, y un escaneo limpio sobre una versión sin soporte describe la cobertura del escáner, no tu situación.
- La pregunta llega en el peor momento. Nadie pregunta en qué versión estás mientras todo está tranquilo. Se pregunta durante una evaluación, durante la revisión de un proveedor de pagos o después de un incidente — tres momentos en los que la respuesta honesta sale cara.
También hay una dimensión de seguros que conviene revisar antes de necesitarla. Las pólizas de ciberseguro preguntan cada vez más por las prácticas de parcheo, y ejecutar software al que el proveedor ha retirado públicamente el soporte es el tipo de detalle que aflora durante un siniestro y no durante la suscripción de la póliza.
Por qué esperar cuesta más que moverse
Cuando el presupuesto aprieta, el instinto es aplazarlo un año. Con las actualizaciones de plataforma, aplazar no es neutral — la factura crece mientras esperas, por razones que no tienen nada que ver con la inflación.
El coste de una actualización lo determina la distancia, no el número de la versión actual. Cada release que te saltas añade cambios de esquema, API obsoletas y requisitos de PHP que tus extensiones tienen que cruzar de un solo salto en lugar de por etapas. Una tienda con una versión de retraso es un proyecto. Una tienda con cuatro versiones de retraso es un ejercicio de arqueología, porque las personas que escribieron las personalizaciones a menudo ya se han ido y puede que las extensiones de las que dependían ya no tengan equivalentes mantenidos.
Hay un segundo coste, más silencioso. Los proveedores de extensiones de terceros siguen el calendario de soporte de Adobe. Cuando una versión se queda sin soporte, los proveedores que la atienden acaban dejando de probar contra ella también. Cuanto más tiempo te quedes en una línea sin soporte, mayor parte de tu parque de extensiones pasa a estar realmente sin soporte y no solo anticuada — y la sustitución, no la actualización, se convierte en el único camino.
La versión que ejecutas también fija un mínimo para tu versión de PHP, que a su vez fija un mínimo para todo lo demás en el stack. Aplazar la actualización de Magento aplaza las decisiones de PHP, búsqueda y caché que van detrás, y esas tienen sus propios calendarios de fin de vida que no esperan al tuyo.
La matriz de extensiones es lo que convierte un rango en una fecha
Pregunta a tres agencias cuánto tarda una actualización de Magento y obtendrás tres rangos, todos amplios. No es por evasivas. Es un reflejo honesto de que la variable no es Magento.
La ruta de actualización del propio Magento está razonablemente trillada. Lo que diferencia un proyecto de seis semanas de uno de seis meses es todo lo que hay encima: extensiones de terceros, módulos a medida, overrides del tema e integraciones con el ERP, el WMS o el sistema de contabilidad que alguien construyó con prisas hace tres años.
El artefacto que convierte esa incertidumbre en un plan es una matriz de compatibilidad de extensiones — una línea por cada extensión y módulo a medida y, para cada uno, la respuesta a cuatro preguntas:
- 1¿Existe una versión compatible con la release de destino? Si la hay, es una subida de versión y una prueba de regresión.
- 2¿El proveedor la sigue manteniendo? Una fecha de publicación reciente importa más que el número de versión actual. Una extensión actualizada por última vez en 2023 es un pasivo aunque hoy funcione.
- 3¿Sigue haciendo algo que el negocio necesita? Los parques de extensiones se acumulan. Es habitual encontrar extensiones que ya no sirven para nada, y eliminar una es más rápido y barato que migrarla.
- 4Si nada de lo anterior aplica, ¿qué la sustituye? Parte de la funcionalidad tiene que reconstruirse, y saberlo en la primera semana es muy distinto de descubrirlo en la novena.
Construye esa matriz antes de escribir una sola línea de código. Es la diferencia entre un proyecto acotado y uno sin final a la vista, y es lo más útil que puedes producir aunque no empieces la actualización de inmediato. Un propietario de tienda que tiene la matriz puede tomar una decisión informada sobre el momento. Uno que no la tiene está eligiendo entre opciones sin precio.
La otra disciplina en la que vale la pena insistir es el ensayo. La actualización debería ejecutarse de principio a fin en un clon de producción antes de ejecutarse en producción. Cada sorpresa desagradable — un módulo que no se instala, un conflicto de esquema, una regresión del tema en el checkout — es bastante más barata la primera vez que ocurre en una máquina en la que nadie está comprando.
Esto no es realmente un problema de Magento
El modo de fallo aquí no es exclusivo de Magento, y reconocerlo es útil porque te dice en qué otros sitios mirar.
Hace poco escribimos sobre por qué los sitios WordPress siguen siendo comprometidos a través de su ecosistema de plugins, y la observación central de aquel artículo se aplica exactamente: el software que deja de mantenerse no lo anuncia. Sigue funcionando perfectamente, y ese es precisamente el problema. Nada en el sitio parece estar mal hasta que se revela una vulnerabilidad y no hay ningún parche en camino.
Un plugin de WordPress abandonado por su autor y una versión de Magento abandonada por su proveedor son el mismo evento a distinta escala. En ambos casos el software sigue funcionando, el riesgo se acumula de forma invisible y el momento del descubrimiento lo elige otra persona, no tú.
La defensa es la misma en ambos casos, y es poco glamurosa: averigua qué estás ejecutando, comprueba si cada pieza sigue teniendo mantenimiento y trata "sigue recibiendo actualizaciones de seguridad" como una propiedad que verificas activamente en lugar de darla por supuesta.
Qué hacer este mes
Si estás en 2.4.5 o 2.4.6, los siguientes pasos útiles son pequeños y en su mayoría gratuitos:
- Confirma tu versión y tu nivel de parches exactos. No lo que dice la documentación del último proyecto — lo que el sistema informa hoy. Es más habitual de lo que debería que una tienda esté un patch release por detrás de donde todo el mundo cree.
- Haz inventario de las extensiones y de cuándo se actualizó cada una por última vez. Es la materia prima de la matriz, y se puede producir en una tarde.
- Decide tu release de destino de forma deliberada. Las líneas con soporte tienen horizontes distintos y requisitos de PHP distintos, y la respuesta correcta depende de tu parque de extensiones y no de qué número es más alto. Vale la pena dejar claro si estás comprando dos años de margen o cuatro.
- Comprueba qué dicen realmente tu proveedor de pagos y tu documentación PCI. Mejor encontrar tú el requisito que dejar que otro lo encuentre por ti.
- Deja la decisión por escrito, incluida la decisión de esperar. Si la respuesta es "este trimestre no", es una decisión de negocio legítima — pero debería quedar registrada y con una fecha asociada, no ser un aplazamiento que silenciosamente se vuelve permanente.
En resumen
No se rompió nada el 11 de agosto. Tampoco se romperá nada mañana, y esa es toda la dificultad: el coste de esta decisión es invisible hasta que deja de serlo, y para entonces la elección del momento pertenece a otra persona.
Una plataforma de e-commerce sin soporte es un problema de cumplimiento antes de ser un incidente de seguridad, y es un problema de presupuesto antes que cualquiera de las dos cosas — porque cuanto más tiempo sigue en marcha, más cuesta salir de ella.
Si quieres una visión clara de dónde está tu tienda, nuestra práctica de consultoría Magento cubre la planificación de la actualización, la postura de seguridad y el pipeline de entrega que hay debajo, y la evaluación incluye la matriz de compatibilidad de extensiones descrita arriba. O habla con nuestro equipo si prefieres empezar con una conversación en lugar de con un documento.