Parches de Magento: lo que no sabías que puedes aplicar hoy

Si has aplicado parches en Magento alguna vez, seguramente fue así: llegó un aviso de Adobe, descargaste un fichero .patch, lo declaraste en el composer.json con cweagans/composer-patches y listo. Es el flujo que conoce casi todo el mundo, y funciona. El problema es que deja fuera un catálogo entero de correcciones oficiales que Adobe ya tiene publicadas, evaluadas y listas para tu versión exacta, y que puedes consultar con un solo comando.

La herramienta se llama Quality Patches Tool, es oficial, es gratuita y funciona también en Magento Open Source. Para que te hagas una idea de la escala: en una instalación 2.4.7-p10 con los parches de seguridad al día, a septiembre de 2026, el catálogo devuelve 171 parches disponibles y ninguno aplicado. Ninguno es obligatorio, y catorce de ellos son correcciones de rendimiento.

Esto es lo que vas a encontrar:

1. Qué es Quality Patches Tool
2. Por qué no es solo para instalaciones en la nube
3. Qué tipo de correcciones incluye el catálogo
4. En qué se diferencia de cweagans/composer-patches
5. Instalación y comandos básicos
6. Aplicar varios parches a la vez y el comportamiento todo-o-nada
7. Por qué puede fallar un parche
8. Qué significan los prefijos de los identificadores
9. Por qué los parches de seguridad no están aquí
10. Flujo de trabajo recomendado
11. Preguntas frecuentes

Qué es Quality Patches Tool

Quality Patches Tool (QPT) es una herramienta de línea de comandos oficial de Adobe, distribuida como paquete de Composer (magento/quality-patches), que permite aplicar, revertir y consultar el estado de parches individuales sobre una instalación ya montada. Trabaja directamente sobre vendor/, no como parte del proceso de composer install.

Cada parche del catálogo corrige un bug puntual y conocido, con su ticket identificador (ACSD-62355, ACP2E-4610, MDVA-43395…), ya evaluado y publicado por Adobe. La ventaja frente al flujo tradicional es que no tienes que esperar al siguiente parche de línea ni hacer un upgrade completo de versión para llevarte una corrección concreta que te está afectando.

Por qué no es solo para instalaciones en la nube

Es la confusión más extendida sobre esta herramienta, y conviene despejarla antes de nada porque es la razón por la que mucha gente nunca la llega a probar. El propio composer.json del paquete lo dice sin ambigüedad: "Provides quality patches for AdobeCommerce & Magento OpenSource".

Lo que existe son dos sabores de la misma base de parches:

El segundo se integra con ece-tools y se aplica durante el despliegue. El primero funciona igual en cualquier servidor propio con Apache o Nginx y PHP-FPM, sin nada de infraestructura de Adobe. Tampoco es una novedad reciente: el fichero community-release-notes.md que viene con el paquete documenta parches ya para Magento 2.3.7 y 2.4.3, de 2020 y 2021. En nuestra opinión, lo que ha faltado no es soporte para Open Source, sino difusión: en la comunidad hispana esta herramienta se menciona mucho menos de lo que se merece.

Qué tipo de correcciones incluye el catálogo

No son parches de seguridad, y esto es importante entenderlo desde el principio (más abajo está el detalle). Son correcciones de bugs funcionales repartidas por toda la aplicación. Este es el reparto real por categorías de los 171 parches disponibles en una instalación 2.4.7-p10, teniendo en cuenta que un mismo parche puede pertenecer a varias categorías:

Dicho así son números. Van algunos ejemplos concretos, que se entienden mejor:

• ACP2E-4535. Enviar el formulario de "olvidé mi contraseña" regenera la sesión y vacía el carrito del invitado. Un cliente que intenta recuperar su cuenta a mitad de compra pierde lo que tenía dentro.
• ACP2E-4875. Consultar en el admin un cliente con una libreta de direcciones grande puede desloguear al usuario administrador.
• ACP2E-4609. La página de presupuestos no muestra ninguno si alguno de ellos contiene productos que se han borrado.
• ACSD-69086. El cron no limpia las tablas de changelog, lo que llega a tumbar un clúster Galera cuando el volumen crece.
• ACSD-64753. La tienda preseleccionada en "recoger en tienda" no se actualiza al cambiar la dirección de envío, aunque quede fuera del radio de cobertura.

El bloque de rendimiento merece capítulo aparte, porque es el que más interesa cuando la tienda va lenta y nadie sabe por qué. Estos son varios de los catorce:

• ACP2E-4610. Problemas de rendimiento del cron sales_clean_quotes.
• ACP2E-4613. Estructuras de directorios de medios grandes provocan respuestas lentas al cargar el árbol de la Media Gallery.
• ACP2E-4695. El indexador de reglas de catálogo consume memoria en exceso y no llega a terminar, con errores de falta de memoria.
• ACSD-67166. Ejecución duplicada de la consulta de stock al cargar un carrito en el storefront, con llamadas redundantes a base de datos.
• ACSD-62355. La página de edición de un producto configurable con muchos atributos y valores carga lenta.
• ACSD-68040. La página de búsqueda del storefront se degrada cuando hay muchas búsquedas históricas acumuladas.

Ninguno de estos es un fallo que tumbe la tienda. Son exactamente el tipo de degradación que se normaliza con el tiempo, hasta que alguien la mide y descubre que llevaba dos años ahí.

En qué se diferencia de cweagans/composer-patches

Si ya usas cweagans/composer-patches, la pregunta lógica es si esto lo sustituye. No lo sustituye, y tampoco al revés: resuelven dos problemas distintos.

Para bugs oficiales conocidos, QPT gana de calle: descubrimiento automático, catálogo curado, seguimiento de estado y reversión con un comando. Para tus propios parches sobre módulos de terceros, extensiones de pago o integraciones con el ERP, sigues necesitando cweagans/composer-patches, porque esos nunca van a estar en el catálogo de Adobe.

Ahora bien, QPT tiene un punto flaco que conviene conocer antes de empezar: no persiste sola. Los parches se escriben en vendor/, que en una instalación Magento queda fuera del control de versiones, así que un entorno levantado desde cero arranca sin ellos. Le pasa a un compañero que clona el repositorio, a un contenedor que se reconstruye o a un servidor nuevo, y también hay que reaplicarlos al subir de versión, porque el paquete se vuelve a extraer.

Esto no es una interpretación nuestra. La documentación oficial de la herramienta recomienda "mantener una lista de los parches aplicados en otro sitio", porque puede hacer falta volver a aplicarlos tras una actualización. Y un artículo del blog técnico de Adobe aborda el problema de frente, reconoce que no existe una solución centralizada para esto y propone montarte un plugin de Composer que ejecute la lista de parches después de cada instalación o actualización. Es decir, el propio fabricante te dice que la persistencia te la tienes que resolver tú.

¿Y los parches que ya apliqué a mano aparecen en el catálogo?

Depende de si Adobe llegó a publicar oficialmente ese mismo fix con su propio ticket. Si venías aplicando parches oficiales descargados a mano, con el naming clásico anterior a QPT, puede pasar que sí coincidan con un identificador del catálogo. Pero el comando de estado solo te lo mostrará si de verdad aplica a tu versión instalada, porque el catálogo se filtra por rango de versiones: si ya subiste de línea y ese fix viene de fábrica en el core, el identificador no aparece ni como aplicado ni como pendiente, simplemente no sale. Y si eran parches de seguridad críticos, no van a coincidir en absoluto, por el motivo que se explica más abajo.

Instalación y comandos básicos

La instalación es exactamente lo que esperas:

composer require magento/quality-patches
php bin/magento setup:upgrade

Y estos son los comandos que vas a usar:

vendor/bin/magento-patches status                 # catálogo completo con su estado
vendor/bin/magento-patches status --format=json   # lo mismo, para procesarlo
vendor/bin/magento-patches apply <ID>             # aplicar
vendor/bin/magento-patches revert <ID> <ID2>      # revertir
vendor/bin/magento-patches revert --all           # revertir todo

El comando que cambia las cosas es el primero. status te lista los parches aplicables a tu versión exacta, cada uno con su descripción, los componentes que toca y si está aplicado o no. Eso es precisamente lo que no tienes cuando vas buscando ficheros .patch a mano: saber qué existe.

Aplicar varios parches a la vez y el comportamiento todo-o-nada

Se pueden pasar varios identificadores en una sola llamada, y funciona sin problemas:

vendor/bin/magento-patches apply ID1 ID2 ID3 ID4 ID5

Tampoco hace falta respetar ningún orden concreto entre ellos. Probamos a aplicar directamente un parche de un paquete mensual sin haber aplicado antes el del mes anterior, y se aplicó sin reclamar ninguna dependencia previa.

Lo que sí conviene saber es que el comportamiento es todo-o-nada, y esto lo comprobamos a propósito de dos formas distintas. Primero metiendo un identificador inexistente en un lote con otros válidos: la herramienta valida que todos existan antes de tocar un solo fichero, así que devuelve error y no aplica ninguno, ni siquiera los que estaban perfectos. Después provocando un conflicto real: modificamos a mano un fichero que uno de los parches iba a tocar, simulando un override propio, y lo metimos en un lote de tres junto a otros dos que aplicaban limpiamente. El lote entero abortó. Los otros dos, que comprobamos por separado que funcionaban, tampoco se aplicaron.

La consecuencia práctica es menos grave de lo que parece, porque el mensaje de error identifica cuál es el parche culpable. Basta con sacarlo del lote y relanzar el resto. No hace falta ir de uno en uno por precaución, aunque en un pipeline automatizado los lotes pequeños te ahorran tiempo de diagnóstico.

Con un conflicto de código, la secuencia queda así:

$ vendor/bin/magento-patches apply ID1 ID2 ID3

Error: patch ID2 can't be applied
error: patch failed: vendor/magento/module-ejemplo/Model/Ejemplo.php:4
error: vendor/magento/module-ejemplo/Model/Ejemplo.php: patch does not apply

# Ninguno de los tres se ha aplicado, tampoco ID1 ni ID3.
# Se relanza el lote sin el parche que da el conflicto:

$ vendor/bin/magento-patches apply ID1 ID3

Si lo que falla es un identificador que no existe o que no aplica a tu versión, el mensaje es distinto y bastante explícito:

$ vendor/bin/magento-patches apply ID1 ACSD-00000

Next patches weren't found: ACSD-00000. Please, check with "status" command
availability of these patches for the current Magento version.

Conviene no confundir los dos casos. El primero significa que el parche existe y te corresponde, pero choca con código que ya tienes modificado, así que toca investigarlo. El segundo suele ser una errata en el identificador, o que ese parche simplemente no aplica a tu versión y por eso no aparece en el catálogo.

Por qué puede fallar un parche

Esta es la parte que no encontrarás en la documentación oficial y la que más te va a ahorrar.

Permisos sobre vendor/. La herramienta escribe directamente ahí, así que si esos ficheros no pertenecen al usuario que lanza el comando falla con Permission denied a mitad de parche, y puede dejarlo aplicado a medias. La causa casi siempre es la misma: en algún momento se ejecutó composer install con un usuario distinto al habitual y la propiedad de los ficheros quedó mezclada.

Lanzarlo como root evita ese error, porque root escribe donde quiera, pero no es la solución. Los ficheros que cree quedan con propietario root, el servidor web pierde el acceso de escritura, y ese es justamente el motivo más común de que una instalación Magento acabe con los permisos rotos. La recomendación de Adobe es ejecutar siempre los comandos como el propietario de los ficheros, nunca como root, y vale igual para Composer y para bin/magento. Si no puedes entrar directamente con ese usuario, tienes sudo -u <propietario> <comando>.

Conviene no confundir el propietario de los ficheros con el usuario del servidor web. En instalaciones pequeñas suelen ser el mismo, pero en una configuración de producción cuidada son dos usuarios distintos que comparten grupo. El criterio que importa es la coherencia: siempre el mismo usuario, y que ese usuario no sea root.

Conflicto de contexto en el diff. Es el fallo más común en proyectos con personalizaciones, y se manifiesta como hunk FAILED o patch does not apply. Cada parche de Adobe es un diff generado contra el código original de un módulo en una versión concreta. Si ese fichero ya fue modificado por un plugin u override propio que reescribe el mismo método, por un retoque manual sobre vendor/, o por un parche anterior que tocó las mismas líneas, el contexto ya no coincide y el parche se rechaza. La solución nunca es forzar la aplicación: toca revisar a mano si el bug ya está resuelto por tu propio código o adaptar el parche.

Versión de línea distinta a la instalada. Muchos ficheros llevan en el nombre una versión que no es la tuya y aun así aplican sin problema, porque el código de alrededor no cambió entre esas líneas menores. Pero cuanto más lejos esté la versión del parche de la tuya, más probable es que el contexto ya no encaje y acabes en el caso anterior.

Identificadores que no van uno a uno con los ficheros. Un mismo identificador puede resolver internamente en un fichero con el nombre de otro ticket, porque son variantes o renombrados del mismo fix histórico. Otro puede aplicar dos ficheros de golpe si el bug requiere tocar varios módulos. Y aplicar uno puede dejar otro marcado como aplicado sin que se lo hayas pedido, porque comparten el mismo diff bajo tickets de seguimiento distintos. Nada de esto es un fallo, pero descoloca si esperabas una correspondencia exacta.

El estado N/A, que no significa lo que parece. Además de aplicado y pendiente, existe un tercer estado que la documentación describe como "el estado del parche no puede determinarse debido a algún conflicto". Es fácil leerlo como "este no lo toques". Lo probamos: aplicamos directamente un parche marcado así y se aplicó sin ningún problema, pasando a aplicado con normalidad. La causa del N/A era que ese parche modifica el propio motor interno que calcula el estado, así que la herramienta no puede describirse a sí misma limpiamente. Indagando un poco más, vimos que si aplicas dos parches de ese tipo a la vez, el más antiguo empieza a reportarse como N/A aunque esté perfectamente aplicado, y vuelve a la normalidad en cuanto reviertes el otro. Nuestra recomendación es no descartar un parche solo por estar en ese estado, y revisar el caso concreto.

El aviso de acumulación. A partir de cierto número de parches aplicados, la propia herramienta te recuerda que Adobe recomienda instalar un número limitado para no complicar el siguiente salto de versión. No bloquea nada, pero conviene tomárselo en serio: esto son correcciones puntuales para problemas concretos, no una alternativa a mantener la tienda actualizada. De hecho, si tu versión ya está fuera de soporte, el problema es otro y lo tratamos en el artículo sobre el fin de vida de Magento.

Qué significan los prefijos de los identificadores

Cuando empiezas a mirar el catálogo aparecen prefijos distintos sin explicación aparente: ACSD, ACP2E, MCLOUD, MDVA, PB… Ni la documentación de Adobe ni el README de la herramienta explican qué significan, lo comprobamos.

Lo que sigue sale de analizar el catálogo completo instalado, que contiene 1.149 parches, y de lo que se conoce públicamente sobre los proyectos Jira históricos de Magento y Adobe. No es información oficial, así que cada línea lleva su nivel de certeza:

La conclusión operativa es más útil que la tabla: el prefijo es una pista sobre la antigüedad y el origen del ticket, no un filtro fiable de nada. Lo único que determina si un parche te aplica es el campo releases, que dice qué versiones cubre. Y conviene insistir en un detalle, porque alimenta el mito del principio: ni siquiera un ticket MCLOUD- significa que el parche sea exclusivo de instalaciones en la nube, lo verificamos aplicando parches con ese prefijo en una instalación propia.

Por qué los parches de seguridad no están aquí

Si vienes del flujo de parchear cuando llega el aviso de Adobe, es natural esperar que esta herramienta sea lo mismo pero automatizado. No lo es, y conviene tenerlo claro para no confiarse.

Analizamos el catálogo completo, los 1.149 parches, buscando correcciones de seguridad. Solo hay cuatro, un 0,35% del total, y las cuatro son parches puente: existen para quien no puede subir de versión inmediatamente después de un aviso, y desaparecen del catálogo aplicable en cuanto la línea alcanza la versión que ya las incorpora de fábrica. En una instalación 2.4.7-p10, ninguna de las cuatro aparece, porque esa versión ya las trae. Los boletines de seguridad propiamente dichos no pasan por este canal en absoluto: cero apariciones en todo el catálogo.

Según estos datos, la seguridad se juega en otros dos sitios:

El zero-day de septiembre de 2026 lo ilustra bien: Adobe lo distribuyó como un hotfix de seguridad de emergencia, con el prefijo que tiene cero apariciones en este catálogo. Quien lo hubiera esperado aquí se habría quedado esperando, y mientras tanto la tienda seguía expuesta.

Flujo de trabajo recomendado

1. Prueba siempre primero en un entorno de pruebas, nunca directamente en producción.
2. Lanza status para ver el catálogo completo aplicable a tu versión exacta.
3. Filtra por relevancia real para tu proyecto. Aplicar los 171 a ciegas no tiene ningún sentido, y además contradice la recomendación de la propia Adobe.
4. Aplica en lotes, recordando el comportamiento todo-o-nada. Si falla, el mensaje te dice qué identificador lo provocó: sácalo y relanza el resto.
5. Ejecuta setup:di:compile y haz una comprobación rápida de la tienda tras cada lote.
6. Decide cómo vas a persistir la lista antes de llevarlo a producción, o los parches desaparecerán en el siguiente composer install limpio.
7. Mantén cweagans/composer-patches para tus propios parches sobre módulos de terceros.

Sobre el punto sexto, que es el que más se descuida, hay tres formas razonables de resolverlo: un script de Composer que ejecute la lista fija de identificadores aprobados después de cada instalación, un fichero versionado con esa lista que lea el pipeline de despliegue, o documentarlo como paso manual del proceso. Cualquiera vale, pero hay que elegir una antes de que el primer composer install se lleve el trabajo por delante.

Preguntas frecuentes

¿Quality Patches Tool funciona en Magento Open Source?

Sí. El paquete magento/quality-patches funciona en cualquier instalación propia, incluida Open Source, sin necesidad de infraestructura de Adobe ni de ece-tools. La variante con ece-patches es la específica de Adobe Commerce on Cloud.

¿Sustituye a cweagans/composer-patches?

No. QPT solo aplica el catálogo oficial de Adobe. Para tus propios parches, los de módulos de terceros o los boletines de seguridad descargados a mano, sigue haciendo falta cweagans/composer-patches. La mayoría de proyectos acaban usando ambas.

¿Hay que aplicar todos los parches disponibles?

No, y no conviene. Son correcciones opcionales para problemas concretos, y la propia herramienta avisa de que acumular muchos complica el siguiente salto de versión. Lo razonable es revisar el catálogo, identificar los que corresponden a problemas que tienes de verdad y aplicar solo esos.

¿Los parches aplicados sobreviven a un composer install?

No. Se escriben en vendor/, que normalmente está fuera del control de versiones, así que una instalación limpia los elimina sin avisar. Hay que resolver la persistencia con un script de despliegue o un fichero versionado con la lista de identificadores.

¿Sirve para aplicar parches de seguridad?

Prácticamente no. De los 1.149 parches del catálogo completo, solo cuatro corresponden a vulnerabilidades, y son parches puente que desaparecen cuando tu versión ya las incorpora. Los boletines de seguridad de Adobe se distribuyen por otro canal y se aplican a mano, o se resuelven subiendo de versión.

Cuántos parches tienes pendientes ahora mismo

Todo lo anterior lo puedes hacer tú, hoy, sin contratar nada: instalas el paquete, lanzas status y ya tienes la foto. Si lo haces, nos parece muy probable que te sorprenda el número, sobre todo el de correcciones de rendimiento esperando.

Si tu tienda la lleva una agencia y quieres saber en qué estado está sin depender de lo que te cuenten, Ticpan te da un diagnóstico automático y gratuito del estado general. Y si prefieres que miremos nosotros qué parches concretos te aplican, cuáles resolverían problemas que ya estás sufriendo y cuáles no merecen la pena, eso forma parte de una auditoría técnica. Es, de hecho, una de las cosas más rentables que encontramos: correcciones oficiales, gratuitas y ya probadas por Adobe, que llevaban meses disponibles sin que nadie las mirara.

Diagnostica gratis tu Magento con Ticpan

¿Quieres saber qué parches te aplican? Cuéntanos tu caso →