Magento es uno de los sistemas de tienda más potentes que existen, y justo por eso funciona a menudo en tiendas con muchas extensiones, funciones propias y conexiones a sistemas ERP y de almacén. La otra cara: cada parche de seguridad debe comprobarse frente a todo eso antes de salir a producción. Si eso no ocurre durante unos meses, una tienda se queda de pronto varios parches atrás, y ponerse al día parece un proyecto para el que nadie tiene tiempo.
Somos signundsinn, una agencia de comercio electrónico de Múnich, y acompañamos tiendas online desde 2009. Aquí le contamos cómo funciona hoy el ciclo de parches de Magento, por qué las tiendas se quedan atrás y con qué rutina una tienda Magento pequeña se mantiene al día.
Así funcionan hoy los parches de seguridad de Magento
Parches aislados mensuales. Adobe publica boletines de seguridad en un día fijo, normalmente el segundo martes de cada mes. A eso se suman los parches de seguridad aislados: paquetes pequeños que corrigen vulnerabilidades concretas para cada línea de versión con soporte. Dos reglas son importantes: debe estar en la última versión de parches de su línea (por ejemplo 2.4.8-p5) y debe haber aplicado antes todos los parches aislados mensuales anteriores. Se apoyan unos en otros.
Una versión completa de parches al año. Una vez al año, en mayo, Adobe publica un parche completo para cada línea con soporte (las versiones “-p”, como 2.4.7-p10 o 2.4.8-p5 en mayo de 2026). Agrupa las correcciones aisladas de los meses anteriores. Las nuevas versiones menores aparecen también más o menos una vez al año: la 2.4.9 llegó en mayo de 2026.
Líneas de versión con fecha final. Cada línea 2.4 tiene una ventana de soporte limitada. Adobe da a Adobe Commerce tres años de soporte estándar desde su publicación. Para las líneas que usan hoy la mayoría de las tiendas:
| Línea de versión | Publicada | Fin del soporte estándar de Adobe |
|---|---|---|
| 2.4.6 | Marzo de 2023 | 11 de agosto de 2026 (finalizado) |
| 2.4.7 | Abril de 2024 | 31 de mayo de 2027 |
| 2.4.8 | Abril de 2025 | 31 de mayo de 2028 |
| 2.4.9 | Mayo de 2026 | 31 de mayo de 2029 |
Para algunas líneas más antiguas Adobe ofrece soporte ampliado a los clientes de Adobe Commerce. Esa prórroga forma parte de Adobe Commerce. Así que si usted utiliza Magento Open Source en 2.4.6 o una versión anterior, planifique ahora el cambio a 2.4.8 o 2.4.9, y no cuando se conozca la siguiente vulnerabilidad crítica.
PHP marca un segundo plazo. La 2.4.6 admite PHP 8.1 y 8.2. PHP 8.1 ya no recibe actualizaciones de seguridad, y PHP 8.2 recibe sus últimas actualizaciones de seguridad el 31 de diciembre de 2026. La 2.4.8 funciona con PHP 8.3 y 8.4. En una tienda con 2.4.6, la versión de PHP y la de Magento se agotan por tanto más o menos a la vez.
Por qué las tiendas se quedan atrás
1. Las extensiones tienen que seguir el ritmo.
Una tienda Magento típica usa docenas de extensiones de terceros. Un parche puede cambiar algo de lo que depende una extensión, y el proveedor quizá necesite tiempo para una versión compatible. Hasta entonces, el parche espera.
2. El código propio y la plantilla.
Las funciones propias y los ajustes de la plantilla hacen única a una tienda, y son justo lo que hay que revisar después de cada parche. Cuantas más personalizaciones, más pruebas.
3. El retraso crece.
Como los parches mensuales se apoyan unos en otros, saltarse un mes no ahorra trabajo, solo lo aplaza. Tres meses saltados significan tres parches que hay que aplicar y probar, en el orden correcto, además del riesgo de trabajar entretanto con vulnerabilidades conocidas.
4. Se confunden parches y actualizaciones de versión.
Un parche (por ejemplo de 2.4.8-p4 a 2.4.8-p5) es una actualización de seguridad acotada. Un salto entre versiones (de 2.4.6 a 2.4.8) es un verdadero proyecto de actualización, a menudo con nuevos requisitos de PHP, de la base de datos o del motor de búsqueda. Las tiendas que hasta ahora solo han hecho parches suelen sorprenderse del alcance de una actualización y la aplazan.
5. Nadie es responsable.
La agencia original ha seguido su camino, el freelance está saturado, el desarrollador interno está atrapado en peticiones de funciones. Parchear es importante, pero rara vez urgente, hasta el día en que lo es.
Una rutina con la que una tienda Magento pequeña se mantiene al día
Cada mes (después del boletín de seguridad):
- Leer el boletín: ¿qué líneas de versión están afectadas y cómo de crítico es?
- Aplicar el parche aislado en una copia de la tienda (staging), junto con todos los parches anteriores.
- Probar aquello con lo que gana dinero: búsqueda, páginas de producto, cesta, proceso de compra con cada forma de pago, cuenta de cliente, correos de pedido y las conexiones con su sistema ERP o de almacén.
- Copia de seguridad, salida a producción en un momento planificado y un pedido de prueba en la tienda real.
Cada trimestre:
- Revisar las extensiones: ¿hay actualizaciones y sigue cada proveedor dando soporte a su línea de versión?
- Comparar la línea de versión y la versión de PHP con las fechas finales de arriba.
- Eliminar las extensiones que ya no utiliza.
Una vez al año (en torno a la versión de mayo):
- Pasar a la nueva versión completa de parches de su línea.
- Decidir cuándo llega el siguiente salto de versión y planificarlo como un proyecto con tiempo para pruebas, mucho antes de que acabe el soporte de su línea.
Antes de sus semanas de más facturación: termine de parchear antes del periodo previo al Black Friday (este año el 27 de noviembre) y a la Navidad, y acuerde después una congelación de cambios, con una excepción: los parches de seguridad críticos se aplican igualmente, probados primero en la copia.
¿Cuánto trabajo supone?
Un parche aislado mensual en una tienda bien mantenida, probado en una copia, suele ser cuestión de horas. El esfuerzo crece con el número de extensiones, la cantidad de código propio y con cada mes saltado. Un salto entre líneas de versión es un proyecto: según nuestra experiencia, actualizar el sistema de tienda lleva entre dos semanas y más de un mes, según la tienda y lo atrasada que esté.
Así mantiene al día la Eywora AI Crew las tiendas Magento
La Eywora AI Crew es nuestro equipo de desarrollo con IA, acompañado por nuestro equipo, y trabaja también en tiendas Magento. Parchear encaja bien con las tareas recurrentes: por ejemplo “aplicar el parche de seguridad mensual de Magento”. Para cada tarea recurrente usted elige cuánto hace la crew por su cuenta: preparar el parche solo para su aprobación, llevarlo dentro de un límite de presupuesto hasta la copia de su tienda, o ejecutarlo de forma totalmente automática dentro de ese límite.
Cada pasada sigue el mismo proceso: el trabajo ocurre en una copia de su tienda, con pruebas automáticas y revisión de código, y nada sale a producción sin su aprobación (salvo que haya elegido el modo automático). Antes de cada despliegue hay una copia de seguridad, y nuestro equipo puede revertirla si algo sale mal. En un salto de versión la crew trabaja igual, como una tarea normal con una estimación que usted aprueba antes. La AI Crew es una suscripción mensual más el uso de IA por tarea, que ve como estimación antes de que empiece el trabajo.
La lista de comprobación para llevarse
Fuentes
- Adobe Experience League, Monthly isolated security patching policy – https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/monthly-isolated-security-patches
- Adobe Experience League, Patch release schedule – https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/schedule
- Adobe Experience League, Adobe Commerce lifecycle policy – https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy
- Adobe Experience League, System requirements – https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements
