En resumen: la vulnerabilidad de Magento de actualidad se llama PHP2Shell y no está en Magento, sino en PHP. Un parche de Magento no la cierra. Tras la actualización de PHP con reinicio, debería revisar app/etc/env.php, la base de datos en busca de skimmers y la lista de cuentas de administrador.
Qué significa PHP2Shell para las tiendas Magento
Magento Open Source y Adobe Commerce son grandes aplicaciones PHP que suelen ejecutarse con PHP-FPM. Según el equipo de PHP, las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 permiten ejecutar código malicioso sin autenticación. Que la propia tienda esté actualizada no influye en ello.
Las tiendas Magento llevan años siendo un objetivo preferente del skimming de tarjetas de crédito, en el que se leen los datos introducidos en el checkout. PHP2Shell abre un camino más para ello. Palo Alto Networks contabilizó más de 22,6 millones de instancias de PHP expuestas y potencialmente vulnerables; no se sabe qué tiendas se encuentran entre ellas.
Vulnerabilidad de Magento: determinar correctamente el estado de PHP
Magento no muestra de forma destacada la versión de PHP en el administrador. Por eso, compruebe el estado en el panel de hosting para el dominio o pida a su proveedor de hosting que lo confirme. php -v en la línea de comandos solo muestra el PHP de CLI con el que se ejecutan bin/magento y los cron jobs. El PHP web a través de FPM puede ser otra versión, y ambos deben estar parcheados.
Las versiones corregidas de origen son 8.5.12, 8.4.27, 8.3.36 y 8.2.35; los backports de las distribuciones pueden llevar números más antiguos. Qué versiones de PHP admite su versión de Magento puede consultarlo, según los requisitos del sistema, en la documentación de Adobe (experienceleague.adobe.com). En Adobe Commerce sobre infraestructura de Adobe, pregunte el estado a Adobe o a su operador. Encontrará una guía paso a paso en Cómo comprobar correctamente la versión de PHP y el nivel de parcheo.
Dónde se aloja el código malicioso en Magento
| Lugar | Contenido | Punto de control |
|---|---|---|
app/etc/env.php |
Base de datos, clave de cifrado, ruta de administración | Fecha de modificación; renovar los valores ante una sospecha |
pub/ |
Raíz de documentos, pub/media, pub/static |
Archivos PHP en las carpetas de medios y de contenido estático |
app/code/ |
Módulos propios | Módulos desconocidos, archivos modificados |
vendor/ |
Paquetes de Composer, también extensiones | Diferencias con el lockfile |
generated/, var/ |
Código generado, caché, registros | Guardar los registros, regenerar el código |
| Base de datos | Configuración, bloques CMS, usuarios administradores | Scripts ajenos, administradores nuevos |
En Magento, los skimmers suelen estar en la base de datos, por ejemplo en los ajustes para scripts adicionales en la cabecera o el pie de la página y en bloques CMS. Un simple análisis de archivos los pasa por alto. Los accesos de solo lectura inofensivos ayudan a echar un primer vistazo (prefijo de tabla según la instalación):
bin/magento info:adminuri
bin/magento module:status
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
Un checkout limpiado no significa que no se hayan filtrado datos. Guarde los registros a partir del 20/10/2026 y copias de la base de datos antes de eliminar scripts. Solo así se podrá determinar después desde cuándo y qué pedidos se vieron afectados.
Área de administración y extensiones
En Magento, la ruta de administración es de libre elección y figura en env.php. Una ruta difícil de adivinar es útil, pero no sustituye a la autenticación en dos pasos ni a la limitación a redes conocidas. Revise con regularidad los usuarios administradores y sus roles, así como las integraciones y los tokens de API.
En Magento abundan las extensiones de terceros: métodos de pago, conexiones con ERP, módulos de búsqueda y de marketing. Cada una aporta código que hay que revisar en las actualizaciones de PHP. Use composer audit con regularidad y elimine por completo los módulos desactivados.
Piense también en los procesos en segundo plano. Magento trabaja con cron jobs y, a menudo, con consumidores de colas que se ejecutan como procesos PHP propios desde la línea de comandos. Tras la actualización de PHP, estos deben reiniciarse igual que PHP-FPM. Tras un cambio de versión principal de PHP, además, debería hacer regenerar el código generado en generated/ y los archivos estáticos, y recorrer la tienda en un entorno de pruebas antes de reanudar el funcionamiento en producción. Cómo lograr un reinicio limpio se describe en Reiniciar PHP-FPM y todos los workers.
Lo que puede y no puede hacer una actualización de Magento
Una versión de Magento o un parche de seguridad de Adobe cierra errores en el código de la tienda. No parchea PHP, no reinicia procesos FPM, no elimina scripts de la base de datos y no borra cuentas de administrador ajenas. Si ya se ha ejecutado código, hace falta una investigación. Cómo reconocer puertas traseras se explica en Reconocer y eliminar webshells.
Para los comerciantes con pago con tarjeta, además: revise las directrices de su proveedor de pago para incidentes de seguridad y coordínese con él antes de renovar claves. Si es necesaria una notificación a la autoridad de protección de datos, aclárelo con su delegado de protección de datos o con su abogado.
¿Cómo ayuda PHP SOS en concreto?
- Aclaramos el PHP web y el PHP de CLI de su servidor Magento y hacemos que se confirmen el parche y el reinicio.
- Guardamos registros, archivos y base de datos de forma trazable, si es necesario mediante nuestro análisis forense informático.
- Revisamos
env.php,pub/, módulos, tablas de configuración, bloques CMS y cuentas de administrador. - Limpiamos, renovamos claves y accesos y documentamos el periodo de posible afectación para la protección de datos y los proveedores de pago.
Preguntas frecuentes
¿Un parche de seguridad de Magento también cierra PHP2Shell?
No. Los parches de Magento corrigen errores en el código de la tienda. PHP2Shell está en el intérprete de PHP del servidor y solo se cierra con una actualización de PHP o un backport confirmado, con reinicio de todos los procesos.
¿Dónde esconden los atacantes los skimmers de tarjetas de crédito en Magento?
Con frecuencia no en archivos, sino en la base de datos, por ejemplo en los ajustes para scripts adicionales en la cabecera de la página o en bloques CMS. Por eso, ante una sospecha siempre hay que revisar también la base de datos.
¿Quién parchea PHP en Adobe Commerce en la nube?
Depende de su contrato y de su entorno. Pregunte por escrito a Adobe o a su operador por el estado de PHP y por el reinicio. Las extensiones propias y el contenido de la base de datos siguen siendo responsabilidad suya.
¿Por qué es tan importante app/etc/env.php?
El archivo contiene el acceso a la base de datos, la clave de cifrado y la ruta del área de administración. Quien haya podido leerlo puede descifrar valores cifrados y encontrar el panel de administración. Ante una sospecha, estos valores deberían renovarse.