Parches de seguridad de Magento 2.4.7: con soporte no es lo mismo que parcheado

Si está en Magento 2.4.7, está en una versión con soporte. Adobe sigue enviándole parches de seguridad, su línea no llega al fin de soporte hasta 2027 y nadie le manda avisos de fin de soporte.

Eso es exactamente por lo que las tiendas en 2.4.7 son de las instalaciones peor parcheadas que vemos, de forma sistemática.

El número de versión es la parte que todo el mundo sigue. El nivel de parche es la parte que determina si la vulnerabilidad concreta que están escaneando contra su tienda esta semana está corregida en su servidor. No son lo mismo, y los boletines de Adobe están escritos en términos de la segunda.

Qué decía de verdad el boletín de julio de Adobe

APSB26-73, publicado el 14 de julio de 2026, listaba las versiones afectadas así:

Vuelva a leer la fila de 2.4.7. No dice «2.4.7 está bien porque tiene soporte». Cada nivel de parche desde la GA hasta p10 incluido es vulnerable a lo que ese boletín corrigió. Una tienda que actualizó a 2.4.7 en 2024, salió a producción y no ha tocado el nivel de parche desde entonces va diez versiones de parche por detrás, y cada una de esas diez existe porque se encontró algo.

«Estamos en una versión con soporte» es una afirmación sobre las obligaciones de Adobe. No dice absolutamente nada sobre su servidor.

El intervalo entre parche disponible y parche aplicado

Aquí es donde vive el riesgo real, y hay buenos datos al respecto.

Cuando se divulgó CVE-2025-54236 —SessionReaper— en septiembre de 2025, Adobe publicó un parche de emergencia antes de lo previsto. Diez días después, Sansec encontró que menos de una de cada tres tiendas Magento lo había aplicado. Seis semanas después, el 62 % seguía sin parchear. La explotación masiva empezó el 22 de octubre, y Sansec bloqueó más de 250 intentos de explotación en un solo día.

El patrón anterior fue el mismo. CosmicSting (CVE-2024-34102) comprometió miles de tiendas, señala Sansec, a menudo a las pocas horas de hacerse público el exploit. En ambos casos el parche existía mucho antes de los ataques. Lo que no existía era un proceso para aplicarlo.

Los atacantes no necesitan un zero-day para entrar en tiendas Magento. Necesitan un CVE publicado, un escáner y una población de tiendas que parchea con ciclo trimestral. No le atacan por ser interesante. Le atacan por ser alcanzable e ir por detrás.

Averigüe qué está ejecutando en realidad

La mayoría de los equipos están menos parcheados de lo que creen, normalmente porque el último proyecto de actualización terminó y nada lo sustituyó. Compruébelo en lugar de darlo por hecho:

# The version and patch level Magento reports
bin/magento --version

# What Composer actually resolved — this is the authoritative answer
composer show magento/product-community-edition | grep versions

# For Adobe Commerce
composer show magento/product-enterprise-edition | grep versions

Después compárelo con el nivel de parche actual de la línea 2.4.7 en las notas de versión de Adobe. Si el número después de la p es menor que el que Adobe publicó este mes, tiene una diferencia, y el tamaño de esa diferencia es el número de versiones de seguridad que le faltan.

Ya que está, compruebe si alguien ha aplicado parches individuales encima sin subir la versión: es habitual, y significa que --version infravalora lo que está corregido:

composer require magento/quality-patches
vendor/bin/magento-patches status

Qué implica de verdad parchear 2.4.7

Una actualización de nivel de parche es un trabajo fundamentalmente distinto de una actualización de versión, y confundir las dos es la razón más habitual por la que el parcheo se pospone hasta convertirse en un proyecto que nunca empieza.

Pasar de 2.4.7-p8 al nivel de parche actual toca correcciones de seguridad y de errores dentro de la misma línea menor. No cambia los requisitos de PHP, ni los de base de datos, ni el framework. Es muy poco probable que se rompa la compatibilidad de extensiones. En la práctica:

# Substitute the current patch level from Adobe's release notes
composer require magento/product-community-edition=2.4.7-pNN --no-update
composer update
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush

En una tienda con un código bien educado, eso es un deploy a staging, una prueba de humo por el checkout y una ventana de producción. Digamos un día de trabajo, la mayor parte esperando y probando.

Compárelo con la actualización 2.4.7 → 2.4.8, que trae consigo PHP, OpenSearch y la compatibilidad de extensiones: un proyecto de varias semanas en una tienda personalizada. Las dos son necesarias. Solo una de ellas es urgente cada mes, y si las trata como la misma categoría de trabajo no hará ninguna.

Adobe también publica parches de seguridad aislados: archivos de parche individuales y no acumulativos publicados al margen del ciclo anual de versiones, para que las correcciones le lleguen más rápido. APSB26-73 se entregó así.

Hay una pega que remata el argumento de todo este artículo: Adobe indica que los parches aislados se prueban contra la última versión solo de seguridad de su línea, y deben aplicarse encima de ella. Diez niveles de parche por detrás significa que no puede tomar la vía rápida en absoluto hasta que se haya puesto al día, y lo descubrirá el día que más lo necesite.

El margen que le queda

2.4.7 alcanzó la disponibilidad general el 9 de abril de 2024. La política de ciclo de vida de Adobe da a cada versión una ventana de soporte estándar de tres años, y sitúa el fin del soporte estándar de esta línea en el 31 de mayo de 2027. Lo que le deja esto:

Una salvedad que juega a su favor: Adobe ofrece actualmente un año adicional de soporte extendido sin coste extra en las líneas 2.4.6 y 2.4.7. Es una provisión de Adobe Commerce: compruebe su tipo de licencia y confirme las condiciones con Adobe en lugar de dar por hecho que le cubre, porque no aplica al código de Magento Open Source.

La fila de PHP es la que pilla a los equipos desprevenidos. 2.4.7 corre sobre PHP 8.2 u 8.3. Si está en 8.2, su runtime del lenguaje deja de recibir correcciones de seguridad a finales de 2026, antes de que lo haga su versión de Magento. Un PHP sin parchear debajo de un Magento parcheado no es una tienda segura, y «estamos en una versión de Magento con soporte» no lo cubrirá.

Pasar a PHP 8.3 dentro de la línea 2.4.7 es un trabajo comparativamente pequeño, y merece la pena hacerlo sea cuando sea que actualice Magento: 2.4.8 requiere 8.3 u 8.4 de todos modos, así que haría la migración una vez en lugar de dos.

Qué hacer esta semana

1. Establezca su nivel de parche real. No de memoria, no de la wiki. De composer show, en producción.

2. Cierre la diferencia hasta el nivel de parche actual. Si va más de una o dos versiones por detrás, prográmelo ahora en lugar de meterlo en un futuro proyecto de actualización. Meterlo ahí es como las tiendas acaban diez niveles por detrás.

3. Suscríbase a los boletines de seguridad de Adobe. Ahora llegan con un calendario predecible. Alguien concreto debería recibirlos y ser dueño de la decisión, o caen en una bandeja compartida y no pasa nada.

4. Ponga por escrito su SLA de parcheo. Un objetivo de «parches críticos aplicados en 72 horas, todo lo demás en dos semanas» es alcanzable en Magento y le habría puesto muy por delante del 62 % durante SessionReaper. Un objetivo que no ha escrito no es un objetivo.

5. Haga que parchear sea aburrido. Un entorno de staging que coincida con producción, una prueba de humo que cubra desde añadir al carrito hasta la confirmación del pedido, y un rollback que haya ensayado de verdad. El parcheo se pospone porque es arriesgado; es arriesgado porque es raro; es raro porque se pospone.

6. Planifique el paso a 2.4.8 en un calendario. No con urgencia: con deliberación. Tiene margen, y las tiendas que lo usan mal son las que descubren en febrero de 2027 que su tema necesita reconstruirse.

La versión corta

Estar en una versión con soporte significa que Adobe hará un parche para usted. No significa que nadie lo haya aplicado.

Las tiendas que se ven comprometidas rara vez ejecutan algo exótico. Ejecutan una versión con soporte, varios niveles de parche por detrás, sin dueño para los boletines y sin un proceso que convierta un CVE publicado en una corrección desplegada. Es un problema operativo con solución —un responsable con nombre y una cadencia de parcheo son la mayor parte de lo que compra de verdad el soporte y mantenimiento de Magento con retainer—, y es bastante más barato de arreglar que un incidente de skimmer de tarjetas y la notificación que viene después.

Si no está seguro de qué ejecuta o de cuánto va por detrás, eso es una auditoría de medio día, no un proyecto.

Emyrix mantiene, parchea y actualiza tiendas Magento y Adobe Commerce, incluidos ciclos de parcheo gestionados para que esto deje de ser algo que tiene que recordar. Si quiere que su posición de parcheo se evalúe como es debido, escríbanos, o use nuestra línea de soporte de emergencia si cree que ya está comprometido.

Los detalles de versiones y niveles de parche proceden de los boletines de seguridad y la política de ciclo de vida del software de Adobe, que son las fuentes autorizadas y conviene consultar directamente para su tipo de licencia.