PHP2Shell y las fallas de PHP en 2026: qué significan para tu tienda Magento

• Amazon detectó intentos de explotación desde el 17 de octubre, cuatro días antes del parche.
• Los investigadores confirmaron ejecución remota de código sin autenticación en Magento 2.4.9.
• PHP 8.1 ya no tiene soporte oficial desde el 31 de diciembre de 2025, y PHP 8.2 lo pierde el 31 de diciembre de 2026.

Si tu tienda corre en Magento o Adobe Commerce, una vulnerabilidad de PHP es una vulnerabilidad de tu tienda. En las últimas semanas se juntaron tres problemas serios: PHP2Shell en el propio lenguaje PHP y dos fallas críticas en Magento (StyleSmuggler y BlockStrap). En este artículo te explicamos qué pasó, a quién afecta, qué hacer hoy y cómo revisar si ya te atacaron, con fuentes oficiales y fechas.

En este artículo:

• Qué es PHP2Shell y por qué es tan grave
• Cómo afecta a Magento y Adobe Commerce
• Si ya lo están explotando
• Qué versión de PHP debe usar tu Magento
• Qué hacer con PHP 8.1 o anterior
• Mitigaciones temporales
• Cómo saber si ya te atacaron
• StyleSmuggler y BlockStrap
• Checklist práctico

¿Qué es PHP2Shell y por qué es tan grave?

PHP2Shell es el nombre de dos fallas de memoria en el núcleo de PHP, publicadas el 21 de octubre de 2026. Permiten que un atacante, sin usuario ni contraseña, ejecute código en el servidor enviando una petición especialmente armada. Afectan a PHP desde la versión 5.4, de 2012, tanto con mod_php como con PHP-FPM.

Las dos fallas tienen una calificación CVSS 4.0 de 9.2 sobre 10. La primera, CVE-2026-109618, está en la forma en que PHP procesa el progreso de subida de archivos y puede además filtrar memoria del servidor en la cookie de sesión: contraseñas, tokens, llaves de API o llaves TLS. La segunda, CVE-2026-109619, está en el manejo de errores fatales y en OPcache. Así lo detallan el anuncio oficial de PHP, la investigación de Wiz y el sitio php2shell.com.

Wiz estima que PHP está detrás de cerca del 70% de los sitios web. OpenAI, que coordinó la respuesta junto con los mantenedores de PHP, lo resumió así en su comunicado del 21 de octubre:

“Consideramos que este es uno de los problemas de seguridad de mayor impacto en la memoria reciente.” — OpenAI (traducción propia)

Un dato que importa para lo que viene: las fallas las encontraron investigadores apoyados en inteligencia artificial (Calif, Wiz y el equipo de Codex Security de OpenAI). Wiz señala que la IA bajó la barrera para encadenar este tipo de errores. Eso aplica también a los atacantes.

¿Cómo afecta PHP2Shell a Magento y Adobe Commerce?

Magento está escrito en PHP, así que cualquier tienda Magento o Adobe Commerce con una versión de PHP sin parchar está expuesta. Los investigadores de Calif confirmaron ejecución remota de código sin autenticación en Magento 2.4.9. El ataque ocurre antes de que se ejecute el código de Magento, así que los parches de Magento no te protegen.

Esto tiene una consecuencia práctica: ni las extensiones de seguridad de Magento ni un firewall a nivel aplicación dentro de la tienda frenan este ataque. Sansec lo dice claramente en su análisis de PHP2Shell: su propio producto Sansec Shield no protege contra esta falla porque el ataque corre antes que el código de la tienda. La única corrección real es actualizar PHP.

Hay también una noticia que baja un poco la presión. En su actualización del 22 de octubre, Sansec explicó que la explotación masiva parece menos probable de lo que se temía al inicio: las pruebas de concepto públicas no funcionan en instalaciones por defecto y la mayoría necesita además otra falla (inclusión de archivos locales). Su recomendación: no necesitas apagar tu tienda, pero sí actualizar PHP cuanto antes.

¿Ya están explotando PHP2Shell?

Sí hay intentos reales. Amazon Threat Intelligence registró en sus servidores trampa un intento el 17 de octubre de 2026, cuatro días antes del parche, y hoy describe los intentos como amplios. Lo que no está confirmado públicamente es cuántos ataques tuvieron éxito en tiendas reales. Hay que actuar sin pánico, pero rápido.

Sophos reportó escaneos e intentos fallidos que buscaban instalar una variante de la botnet Mirai llamada “Potassium”, y después corrigió un reporte inicial de un compromiso exitoso. Puedes leer el detalle de Amazon en el AWS Security Blog y la nota técnica en CERT/CC VU#763488.

¿Qué versión de PHP debe usar tu Magento en 2026?

Depende de tu versión de Magento, porque cada versión solo acepta ciertas versiones de PHP. Lo ideal es estar en Magento 2.4.8 o 2.4.9 con PHP 8.3, 8.4 u 8.5. Si estás en 2.4.6 o anterior, probablemente sigues en PHP 8.1 u 8.2, que ya no tienen soporte o lo pierden este año.

Adobe es claro en su política de ciclo de vida: no da correcciones de seguridad para componentes de terceros como PHP. También advierte que correr PHP 8.1 pone en riesgo el cumplimiento PCI en 2.4.4 a 2.4.6, y que con el fin de PHP 8.2 conviene planear la actualización antes de que termine 2026. Revisa la tabla completa en los requisitos de sistema de Adobe y en las versiones soportadas de PHP.

Si necesitas el contexto completo de fechas, lo explicamos en Magento 2.4.x en 2026: fechas de fin de soporte y en la guía para actualizar Magento.

¿Qué hago si mi Magento corre PHP 8.1 o una versión anterior?

No te quedas sin opciones, pero tu caso es más delicado. El equipo de PHP publicó parches de código para 7.4, 8.0 y 8.1, y varios proveedores ofrecen paquetes con la corrección. Lo importante es confirmar que tu servidor tiene el paquete parchado, no solo que dice PHP 8.1 en la versión.

• Debian y Ubuntu: repositorio de Ondřej Surý (deb.sury.org), Ubuntu 22.04 para PHP 8.1 y Ubuntu Pro.
• Red Hat, AlmaLinux, Remi y CloudLinux para distribuciones tipo RHEL.
• Soporte extendido comercial: Freexian ELTS, TuxCare ELS y ZendPHP LTS.
• Ojo con Docker: la imagen oficial php no recibe la corrección para 8.1 o anteriores.

Para confirmar que el paquete instalado ya incluye el parche, busca el número de la falla en el registro de cambios del paquete:

# Debian / Ubuntu (ajusta php8.1 a tu versión)
zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz

# RHEL / AlmaLinux
rpm -q --changelog php-common | grep CVE-2026-109618

# Después de actualizar, reinicia PHP-FPM para que tome el cambio
sudo systemctl restart php8.1-fpm

Estas opciones compran tiempo. La solución de fondo sigue siendo subir de versión de Magento y de PHP. Si tu tienda está atorada en una versión vieja porque nadie se atreve a moverla, revisa el costo de no actualizar.

¿Qué mitigaciones temporales existen si no puedo actualizar hoy?

Si no puedes actualizar PHP de inmediato, hay medidas temporales que reducen el riesgo mientras programas el cambio. Ninguna sustituye el parche y algunas rompen funciones de la tienda, como subir imágenes en el panel. Pruébalas primero y revisa que el checkout siga funcionando después de aplicarlas.

# 1) Nginx: bloquear peticiones multipart (rompe subidas de imágenes en el admin)
if ($http_content_type ~* "multipart/form-data") { return 403; }

# 2) PHP-FPM (pool de la tienda): desactivar el progreso de subida
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1

# 3) Solo PHP 8.5: desactivar backtraces en errores fatales (php.ini)
fatal_error_backtraces = 0

# Recarga PHP-FPM para aplicar
sudo systemctl reload php8.3-fpm

• En Apache, el bloqueo equivalente se hace con una regla RewriteCond sobre Content-Type y la bandera [F].
• Gina Peter Banyard, del equipo de PHP, advirtió que desactivar el progreso de subida por sí solo no basta.
• Si usas Cloudflare, AWS WAF u otro WAF, revisa si tu proveedor publicó reglas para PHP2Shell; ayudan, pero no reemplazan el parche.

¿Cómo sé si ya atacaron mi tienda?

Revisa tus registros desde el 17 de octubre de 2026, que es cuando Amazon vio el primer intento. Las señales principales son peticiones POST con el texto PHP_SESSION_UPLOAD_PROGRESS, procesos que no reconoces en el servidor y archivos modificados sin explicación. Si encuentras algo, trátalo como incidente, no como ajuste.

# Buscar intentos en los logs de Nginx (ajusta la ruta)
zgrep -a "PHP_SESSION_UPLOAD_PROGRESS" /var/log/nginx/access.log* | head

# Archivos PHP modificados en los últimos 7 días dentro de la tienda
find /ruta/a/magento -name "*.php" -mtime -7 -not -path "*/var/*" -not -path "*/generated/*"

Como CVE-2026-109618 puede filtrar memoria del servidor, si tu PHP estuvo expuesto conviene rotar contraseñas de base de datos, llaves de API de pasarelas y servicios, y revisar usuarios del panel. Si encuentras archivos o procesos extraños, sigue nuestra guía para eliminar malware de Magento y asegúrate de tener respaldos verificados antes de tocar nada.

¿PHP2Shell es lo único? StyleSmuggler y BlockStrap en Magento

No. En septiembre y octubre de 2026 Adobe publicó dos parches críticos para Magento y Adobe Commerce, ambos con calificación CVSS 10. Uno ya se explotaba antes de existir el parche. Si actualizaste PHP pero no aplicaste estos parches, tu tienda sigue expuesta por otro lado. Hay que revisar las tres cosas juntas.

En StyleSmuggler, según el análisis de Sansec, los ataques empezaron el 4 de septiembre y entraron por rutas como /paypal/transparent/response/ y /graphql. Dejaron puertas traseras, procesos disfrazados, archivos en pub/media y skimmers de tarjetas guardados en la configuración de diseño. Adobe recomienda rotar la llave de cifrado y las credenciales después de parchar.

En BlockStrap, Sansec reprodujo cuatro rutas de ataque en un día, y advirtió que los agentes de IA aceleran el análisis de parches para crear ataques. Para 2.4.4 a 2.4.6 existen versiones adaptadas del parche (Happy Horizon) y Mage-OS 3.6.0 ya lo incluye.

# ¿Está aplicado el hotfix VULN-39341 (StyleSmuggler)?
vendor/bin/magento-patches -n status | grep "39341\|Status"

# ¿Está aplicado el parche de BlockStrap? (debe devolver un número mayor a 0)
grep -c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php

Ya habíamos escrito sobre alertas de malware en Adobe Commerce y sobre seguridad en Magento; este caso confirma que la seguridad depende tanto del servidor como de la aplicación.

Checklist práctico: qué hacer esta semana

Este es el orden que recomendamos para una tienda Magento o Adobe Commerce. Los primeros cuatro puntos son urgentes y se pueden hacer en uno o dos días con alguien técnico. Los demás son parte de un plan para no volver a estar en esta situación con la siguiente falla, que llegará.

1. Identifica la versión exacta de PHP de cada servidor y contenedor (php -v y el paquete instalado), incluidos staging y servidores de cron.
2. Actualiza a PHP 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o al paquete parchado de tu distribución, y reinicia PHP-FPM.
3. Verifica en el registro de cambios del paquete que incluye CVE-2026-109618 y CVE-2026-109619.
4. Confirma que tienes el hotfix VULN-39341 y el parche de BlockStrap aplicados.
5. Busca PHP_SESSION_UPLOAD_PROGRESS en los logs desde el 17 de octubre y revisa archivos y procesos.
6. Rota llave de cifrado, contraseñas y llaves de API si hubo exposición.
7. Confirma que tienes un respaldo reciente que sí se puede restaurar.
8. Revisa reglas del WAF (Cloudflare, AWS WAF u otro) para PHP2Shell y para las fallas de Magento.
9. Programa la actualización a Magento 2.4.8 o 2.4.9 si sigues en 2.4.6 o anterior; PHP 8.2 pierde soporte el 31 de diciembre de 2026.
10. Define quién vigila los boletines de PHP y de Adobe y en cuánto tiempo se aplican los parches críticos.

Conclusión

PHP2Shell, StyleSmuggler y BlockStrap llegaron en menos de dos meses y tienen algo en común: el tiempo entre que se conoce una falla y que se intenta explotar ya se mide en horas o días. Para una tienda Magento, la defensa empieza por lo básico: PHP y Magento al día, parches verificados, respaldos probados y alguien revisando señales de ataque.

Si tu tienda necesita ayuda, en soporte Magento atendemos incidencias y actualizaciones pendientes, y si heredaste una tienda sin documentación, revisa cómo trabajamos los takeovers. Para el mantenimiento de todo el año, lee cómo mantener Magento 2 estable, seguro y rápido.

Sobre el autor

Panamerik es CEO y fundador de Panamerik, agencia de ecommerce en Guadalajara especializada en Magento Open Source, Adobe Commerce y Hyvä. Es ingeniero en Sistemas Computacionales por el ITESO y acompaña a empresas en desarrollo, soporte e integraciones de sus tiendas. Ver perfil.

Fuentes

• PHP: anuncio de las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 (21 de octubre de 2026)
• PHP: versiones soportadas
• php2shell.com: resumen y cronología (21 de octubre de 2026)
• Wiz: PHP2Shell (21 de octubre de 2026)
• Sansec: PHP2Shell y Magento (21 y 22 de octubre de 2026)
• AWS Security Blog: explotación antes de la publicación (octubre de 2026)
• CERT/CC VU#763488 (22 de octubre de 2026)
• OpenAI: Patch the Planet (21 de octubre de 2026)
• Adobe: requisitos de sistema (13 de octubre de 2026)
• Adobe: política de ciclo de vida (18 de septiembre de 2026)
• Sansec: StyleSmuggler (septiembre de 2026)
• Sansec: BlockStrap (15 de octubre de 2026)