Parches de seguridad de Magento 2.4.9: la más nueva no es la más segura

Hay una suposición cómoda que recorre la mayoría de las conversaciones sobre actualizaciones: pásese a la versión más nueva y el problema de seguridad queda resuelto por un tiempo.

El boletín de Adobe de julio de 2026 es una corrección útil. APSB26-73 listaba las versiones afectadas como 2.4.9, 2.4.8-p5 y anteriores, 2.4.7-p10 y anteriores, y así hacia abajo por las líneas. Fíjese en la primera entrada. 2.4.9 llevaba unos dos meses en disponibilidad general y ya estaba en la lista: no un nivel de parche suyo, la propia versión.

No es una crítica a 2.4.9. Es cómo funciona el software. Pero sí significa que si actualizó pronto para adelantarse a la curva de seguridad, tiene que entender qué compró de verdad, porque no fue inmunidad.

El código nuevo no es código probado

2.4.9 es el cambio más significativo en las entrañas de Magento desde el lanzamiento de Magento 2. El MVC nativo de PHP sustituyó a Laminas MVC. Symfony Cache sustituyó a la capa de caché anterior. HugeRTE sustituyó a TinyMCE en el admin. Varios cientos de correcciones llegaron con ello.

Cada una de esas sustituciones es una buena decisión a largo plazo y un aumento a corto plazo de superficie sin probar. Al código de framework que lleva cinco años en producción en decenas de miles de tiendas ya se le han encontrado los bordes. Al código de framework que salió en mayo, no.

Ese es el intercambio que hace como adoptante temprano, y es razonable, pero invierte la intuición habitual:

El recorrido es el premio de verdad. La madurez es el precio. Estar en 2.4.9 significa estar más cerca de hacia dónde va el ecosistema y más lejos de donde se ha probado, que es una buena posición mientras se mantenga de forma deliberada.

La obligación de parcheo del adoptante temprano

En una línea establecida, un par de semanas de retraso en el parcheo es un riesgo manejable, porque la vulnerabilidad que se corrige suele ser uno de muchos problemas conocidos en código muy transitado. En una línea nueva, la cadencia de versiones hace más trabajo: las correcciones llegan porque los problemas se están descubriendo al ritmo más alto que ese código va a tener nunca.

Así que la disciplina tiene que ser más estricta, no más laxa. En concreto:

Aplique los parches de seguridad aislados, no espere a las versiones completas. Adobe los publica como archivos de parche individuales y no acumulativos, al margen del ciclo anual de versiones; APSB26-73 llegó así. En una línea nueva importan más de lo habitual, porque las versiones de parche completas de 2.4.9 todavía son poco frecuentes. Tenga en cuenta la condición de Adobe: un parche aislado se prueba contra la última versión solo de seguridad de su línea, y debe aplicarse encima de ella. La Quality Patches Tool es la ruta:

composer require magento/quality-patches
vendor/bin/magento-patches status
vendor/bin/magento-patches apply <patch-id>

Lea las notas de la versión, no solo el número. En una línea madura puede aplicar una versión de parche de forma bastante mecánica. En 2.4.9 las notas le dicen qué subsistema nuevo se ha tocado, que es exactamente en lo que deberían centrarse sus pruebas de regresión.

Espere ser de los primeros en reportar. Si encuentra algo raro en el nuevo comportamiento de caché o de enrutado, puede que sea de verdad de los primeros. Repórtelo en lugar de rodearlo en local: la solución alternativa se convierte en una personalización, y las personalizaciones son lo que hace difícil aplicar el siguiente parche.

El problema de las extensiones es un problema de seguridad

La exposición de seguridad más habitual en 2.4.9 ahora mismo no está en Magento. Está en lo que hay instalado a su lado.

Los cambios de framework de 2.4.9 rompieron suposiciones que las extensiones llevaban años haciendo. Eso produce tres resultados, y dos son malos:

1. El proveedor publicó una versión compatible. Bien. Manténgala actualizada.
2. El proveedor no lo ha hecho, y usted la parcheó por su cuenta para que funcione. Ahora mantiene un fork del código relevante para la seguridad de otra persona, y su futura corrección de seguridad no se aplicará limpiamente.
3. El proveedor se ha quedado callado y usted la ejecuta de todos modos. Es un módulo sin mantener con acceso a la base de datos y a menudo al checkout, sobre un código para el que no se escribió.

El caso tres es como se comprometen muchas tiendas, y no aparece en ningún boletín de Adobe. Nadie publica un CVE por una extensión abandonada; la tienda simplemente cae, y el trabajo forense encuentra el punto de entrada después.

Audite lo que hay instalado:

composer show --outdated
composer show | grep -v "^magento/"

Para cada módulo de terceros, responda a dos preguntas: ¿sigue haciendo falta?, y ¿el proveedor ha publicado algo desde que salió 2.4.9? Todo lo que falle en las dos es candidato a eliminación, y eliminar es la única solución que reduce de verdad la superficie de ataque. Desactivar un módulo deja el código en el disco.

Su plan de rollback es parte de su postura de seguridad

Suena a una preocupación de disponibilidad más que de seguridad, pero en una línea nueva son la misma preocupación.

La razón por la que los equipos retrasan los parches es el miedo a romper producción. En 2.4.9 ese miedo está más fundado de lo habitual, porque el código es más nuevo y sus extensiones están menos probadas contra él. Si no se aborda, produce exactamente el resultado que intentaba evitar: una tienda que sigue sin parchear porque parchear parece peligroso.

La salida es hacer que revertir sea barato:

• Una copia de seguridad de la base de datos tomada justo antes del deploy, con una ruta de restauración probada; probada significa que alguien la ha restaurado de verdad en un entorno que funciona y lo ha cronometrado.
• Un mecanismo de deploy que pueda volver a la versión anterior con un comando. Si su deploy es un git pull en producción, eso es lo primero que hay que arreglar.
• Una prueba de humo de diez minutos que cubra añadir al carrito, checkout como invitado y registrado, un método de pago real, inicio de sesión en el admin y un guardado de producto. Ejecútela antes y después de cada parche.

Con esas tres cosas en su sitio, aplicar un parche de seguridad deja de ser una decisión que necesita una reunión.

Dónde está 2.4.9 en realidad

Para dejar clara la recomendación, porque «tenga cuidado» se lee como «no lo haga»:

Si ya está en 2.4.9, está en una buena posición: el recorrido de soporte más largo disponible, sobre la arquitectura futura de la plataforma. Mantenga el nivel de parche al día, mantenga el inventario de extensiones ajustado y acepte que verá más correcciones durante el próximo año que una tienda en 2.4.8.

Si está decidiendo si ir ahí, la cuestión de 2.4.8 frente a 2.4.9 depende sobre todo de su parque de extensiones y de su posición de infraestructura, no de la seguridad. 2.4.9 necesita PHP 8.4 u 8.5, MySQL 8.4 o MariaDB 11.4 y OpenSearch 3: ese trabajo de infraestructura es el proyecto de verdad, no el comando de Composer.

Si está en una versión sin soporte, nada de esto le aplica todavía. Volver a una línea con soporte es lo único que importa, y el fin de soporte de 2.4.6 lo ha hecho urgente para muchas tiendas este mes.

Por qué la disciplina importa más que la versión

Los datos de explotación son consistentes en todas las vulnerabilidades recientes de Magento, y dicen lo mismo cada vez.

Cuando SessionReaper (CVE-2025-54236) se parcheó en septiembre de 2025, Sansec encontró que menos de una de cada tres tiendas había aplicado la corrección a los diez días, y el 62 % seguía sin parchear a las seis semanas, que es cuando empezó la explotación masiva, con más de 250 intentos bloqueados en un solo día. CosmicSting (CVE-2024-34102) siguió el mismo patrón un año antes, comprometiendo miles de tiendas.

En ninguno de los dos casos el número de versión fue el factor decisivo. El factor decisivo fue el número de días entre que un parche estuvo disponible y se aplicó. Una tienda en 2.4.9 que parchea en seis semanas está peor que una tienda en 2.4.7 que parchea en tres días, y el hecho de que esto resulte contraintuitivo es precisamente por lo que sigue pasando.

Qué hacer esta semana

1. Confirme su nivel de parche. composer show magento/product-community-edition | grep versions, en producción, hoy.

2. Compruebe si hay parches aislados que no ha aplicado. vendor/bin/magento-patches status le dirá qué hay disponible para su versión.

3. Haga inventario de sus módulos de terceros. Cualquiera sin una versión publicada desde mayo de 2026 necesita una decisión: actualizar, sustituir o eliminar.

4. Cronometre un rollback. Restaure la copia de anoche en staging y anote cuánto tardó. Si el número no le gusta, ese es el trabajo.

5. Suscríbase a los boletines de seguridad de Adobe, con un responsable con nombre recibiéndolos. En una línea nueva quiere enterarse de una corrección el día que se publica, no en la próxima revisión programada.

Estar en la versión más nueva le compró un recorrido de soporte largo y un código moderno. No le compró un pase para nada de lo anterior; en todo caso, trasladó la responsabilidad más hacia usted, porque en una línea nueva hay menos experiencia acumulada en la que apoyarse. Si nadie de su equipo es dueño de esa lista, el soporte y mantenimiento continuo de Magento es el acuerdo que la cubre.

Emyrix actualiza, parchea y da soporte a tiendas Magento y Adobe Commerce, incluido el trabajo de compatibilidad de extensiones que hace que las versiones nuevas sean seguras de ejecutar. Si está en 2.4.9 y quiere que revisemos su posición de parcheo y su parque de módulos, escríbanos, o use nuestra línea de soporte de emergencia si algo ya está fallando.

Los detalles de versiones afectadas y del calendario de versiones proceden de los boletines de seguridad de Adobe, que son la fuente autorizada y conviene verificar directamente para su versión y tipo de licencia.