Vulnerabilidades de PHP: qué hacer tras PHP2Shell

Las vulnerabilidades de PHP dejaron de ser un tema exclusivo del equipo técnico. Esta semana, el proyecto PHP y la agencia de ciberseguridad de Estados Unidos (CISA) pidieron parchar de inmediato dos fallas críticas en el propio lenguaje, y PHP es el lenguaje de servidor del 69.3% de los sitios web cuyo lenguaje se conoce, según W3Techs. Si tu tienda o sitio corre en WordPress, WooCommerce, Magento o Adobe Commerce, esto te afecta directamente.

Este artículo explica, sin tecnicismos innecesarios y sin exagerar, qué pasó, qué versiones están en riesgo, por qué las plataformas PHP con muchos plugins acumulan más exposición y cuándo tiene sentido considerar una arquitectura sin PHP con Medusa (comercio) y Sanity (contenido).

En este artículo:

• Qué es PHP2Shell y por qué importa a un dueño de negocio
• Qué versiones de PHP están afectadas y cuándo termina su soporte
• Por qué WordPress, WooCommerce y Magento concentran tanto riesgo
• Cómo reduce el riesgo una arquitectura headless con Medusa y Sanity
• Qué riesgos siguen existiendo sin PHP
• Qué hacer esta semana

# ¿Qué es PHP2Shell y por qué importa a tu negocio?

PHP2Shell es el nombre de dos vulnerabilidades críticas en PHP (CVE-2026-109618 y CVE-2026-109619), corregidas el 21 de octubre de 2026. Permiten que un atacante sin usuario ni contraseña ejecute código en el servidor que atiende tu sitio. En términos de negocio: puede robar datos de clientes, alterar precios, instalar malware o tumbar la tienda.

El aviso oficial de PHP califica ambas fallas con CVSS 9.2 y señala que afectan a todas las instalaciones que atienden peticiones web: PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed, con mayor riesgo en mod_php. La PHP Foundation confirmó que la ejecución remota se demostró con la configuración por defecto en mod_php.

Lo que lo vuelve urgente es la velocidad. De acuerdo con el análisis de Tenable, Amazon Threat Intelligence detectó un intento de explotación el 17 de octubre, cuatro días antes de la divulgación, y los investigadores confirmaron ejecución remota previa a autenticación en versiones específicas de WordPress, Drupal, Joomla y Magento. El CTO de Cloudflare, Dane Knecht, reportó estar viendo "ataques tempranos".

Recomendación de CISA (21 de octubre de 2026): los sistemas que no puedan actualizarse, o que ejecuten PHP 8.1 o anterior, deben desconectarse hasta poder parcharse. Consulta el aviso original.

Un matiz importante para ser justos: al momento de su publicación, CISA indicó que no había observado explotación confirmada, y estas CVE no figuraban en su catálogo de vulnerabilidades explotadas conocidas (KEV) al 22 de octubre. Aun así, la recomendación es parchar sin esperar.

# ¿Qué versiones de PHP están afectadas y cuándo termina su soporte?

Todas las ramas con soporte recibieron parche; las que ya terminaron su ciclo de vida no. Según php.net, PHP 8.2 sólo recibe correcciones de seguridad hasta el 31 de diciembre de 2026, y PHP 8.1 dejó de recibirlas el 31 de diciembre de 2025. Si tu plataforma depende de 8.1 o anterior, hoy no hay versión oficial que corrija PHP2Shell.

El aviso de PHP menciona que existen parches mínimos de código fuente (backports) para 7.4, 8.0 y 8.1, pero aplicarlos exige compilar PHP manualmente; no es algo que la mayoría de los hostings compartidos haga por ti. Las fechas de fin de vida están en php.net/eol.

¿Cuántos sitios siguen en ramas viejas? W3Techs estima que, entre los sitios con PHP, el 26.9% usa la versión 7 y el 7.7% la versión 5, ambas sin soporte. Ese es el universo más expuesto.

# ¿Por qué WordPress, WooCommerce y Magento concentran tanto riesgo?

El riesgo no viene sólo del lenguaje: viene de la suma de núcleo, plugins, temas y extensiones de terceros que se ejecutan en el mismo servidor PHP. Cada componente es una puerta adicional, y muchas tiendas tardan semanas en actualizar. PHP2Shell se agrega a ese historial; no lo inicia.

# WordPress y WooCommerce: el problema son los plugins

El reporte State of WordPress Security in 2026 de Patchstack contabilizó 11,334 vulnerabilidades nuevas en el ecosistema WordPress durante 2025, 42% más que en 2024. El 91% estaba en plugins, el 9% en temas y sólo 6 en el núcleo. El 46% no tenía corrección al momento de hacerse pública y la mediana para explotación masiva fue de 5 horas. WooCommerce es, precisamente, un plugin de WordPress.

# Magento y Adobe Commerce: CosmicSting y SessionReaper

En Magento y Adobe Commerce, dos fallas recientes muestran el patrón. Sansec, firma especializada en seguridad de ecommerce, calificó a CosmicSting como "el peor bug que ha golpeado a las tiendas Magento y Adobe Commerce en dos años" y observó tiendas hackeadas a un ritmo de 5 a 30 por hora. Poco más de un año después llegó SessionReaper.

Según Sansec, los ataques automatizados de SessionReaper alcanzaron a más del 50% de las tiendas Magento y Adobe Commerce a nivel global. Tanto CosmicSting como SessionReaper fueron agregadas por CISA a su catálogo de vulnerabilidades explotadas activamente.

Para ser precisos: estas fallas son de las aplicaciones, no del lenguaje PHP. PHP bien mantenido puede ser seguro, y hay grandes sitios que lo demuestran. El punto para un dueño de negocio es otro: en un monolito PHP, el núcleo, las extensiones y el panel de administración comparten servidor, así que una sola falla puede comprometerlo todo. Si ya te preocupa el fraude en tu ecommerce, la seguridad de la plataforma es el primer filtro.

# ¿Cómo reduce el riesgo una arquitectura headless con Medusa y Sanity?

Una arquitectura headless separa la tienda en piezas independientes que se comunican por API. Con Medusa como motor de comercio y Sanity como capa de contenido, no hay intérprete PHP en el servidor, el contenido vive en una plataforma administrada y una falla en una pieza no expone automáticamente a las demás. Eso reduce la superficie de ataque.

# Medusa: el motor de comercio, en Node.js

Medusa es una plataforma de comercio de código abierto (núcleo con licencia MIT) que se ejecuta en Node.js y PostgreSQL. Gestiona productos, carrito, pedidos, pagos e inventario mediante API. Como la lógica de comercio se expone por API, el escaparate puede vivir en otro servidor, y muchas integraciones se construyen como módulos a la medida, con menos dependencia de un marketplace de plugins.

# Sanity: el contenido, fuera de tu servidor

Sanity guarda el contenido como datos estructurados en su Content Lake y lo entrega por API a través de una CDN. En la práctica, tu equipo edita en Sanity Studio, una aplicación que trabaja contra la API de Sanity, sin un panel PHP tipo /wp-admin corriendo en tu propio servidor. Además, el contenido estructurado facilita marcarlo con datos estructurados como JSON-LD para buscadores y motores de IA.

Esta separación también facilita conectar la tienda con agentes y asistentes de IA de forma controlada, como explicamos en function calling y MCP en ecommerce.

# ¿Headless sin PHP significa cero riesgo?

No. Quitar PHP elimina una categoría de vulnerabilidades, pero agrega otras. Medusa depende del ecosistema npm, la configuración de API y credenciales puede fallar, y cualquier código propio puede tener errores. Lo que cambia es dónde está el riesgo y qué tan contenido queda, no su desaparición.

El ejemplo más claro: en septiembre de 2025, CISA alertó sobre "Shai-Hulud", un gusano que comprometió más de 500 paquetes del registro npm, el mismo ecosistema del que depende Node.js. Una tienda headless necesita fijar versiones, auditar dependencias, rotar llaves de API, limitar permisos de tokens y monitorear sus servicios igual que cualquier otra.

La recomendación honesta: headless con Medusa y Sanity tiene sentido cuando tu plataforma actual te obliga a vivir parchando plugins, está en una rama de PHP sin soporte o necesitas separar comercio y contenido para crecer. Si tu sitio PHP está actualizado, con pocos plugins y un equipo que lo mantiene, actualizar puede ser suficiente por ahora.

# ¿Qué debe hacer tu negocio esta semana?

Primero contener PHP2Shell y después decidir la estrategia. Estos pasos sirven tanto si te quedas en PHP como si evalúas migrar:

1. Pregunta a tu proveedor de hosting o agencia qué versión exacta de PHP corre tu sitio y pide confirmación por escrito de que ya está en 8.2.35, 8.3.36, 8.4.27 u 8.5.12 o superior, o de que su distribución de Linux ya aplicó el parche (Debian, Ubuntu o RHEL lo hacen a veces sin cambiar el número de versión).
2. Si usas PHP 8.1 o anterior, sigue la recomendación de CISA: aísla o desconecta el sitio hasta actualizar de rama.
3. Activa reglas de firewall de aplicaciones (WAF), como las que publicó Cloudflare, como medida temporal, no como sustituto del parche.
4. Revisa que Magento o Adobe Commerce tengan aplicados los parches de CosmicSting y SessionReaper, y que WordPress y sus plugins estén al día.
5. Haz un inventario de plugins y extensiones: elimina los que no uses y anota cuáles no se actualizan desde hace meses.
6. Si estás en PHP 8.2, agenda la migración antes del 31 de diciembre de 2026.
7. Evalúa si conviene seguir parchando o mover el comercio a Medusa y el contenido a Sanity.

Si operas en la región, también puede servirte nuestro repaso de soluciones técnicas para tiendas en Latinoamérica.

# Preguntas frecuentes

# ¿Mi sitio en WordPress está afectado por PHP2Shell?

Sí, si corre en una versión de PHP sin el parche del 21 de octubre de 2026. La falla está en PHP, no en WordPress, así que la solución es actualizar PHP a 8.2.35, 8.3.36, 8.4.27 u 8.5.12 o superior. Pide confirmación a tu hosting.

# ¿Basta con un firewall o WAF?

No. Las reglas WAF, como las que publicó Cloudflare, ayudan como medida temporal mientras actualizas, pero no corrigen la vulnerabilidad. El parche oficial de PHP sigue siendo indispensable.

# ¿Cuándo termina el soporte de PHP 8.2?

PHP 8.2 recibe sólo correcciones de seguridad hasta el 31 de diciembre de 2026, según php.net. Después quedará sin parches oficiales, como ya ocurre con PHP 8.1 desde el 31 de diciembre de 2025.

# ¿Medusa y Sanity son inmunes a vulnerabilidades?

No. Eliminan las vulnerabilidades propias de PHP y reducen la superficie de ataque, pero Medusa depende de paquetes npm y cualquier configuración de API o credenciales puede fallar. Requieren mantenimiento y monitoreo.

# ¿Migrar a headless es caro o lento?

Depende del catálogo, las integraciones y el contenido. Por eso conviene diagnosticar primero: hay negocios donde basta actualizar PHP y otros donde migrar comercio a Medusa y contenido a Sanity se justifica.

# Conclusión: parchar hoy, decidir la arquitectura con calma

• PHP2Shell (CVSS 9.2) exige actualizar PHP de inmediato; las ramas 8.1 y anteriores no tienen parche oficial.
• PHP 8.2 pierde soporte de seguridad el 31 de diciembre de 2026.
• En WordPress y Magento, los plugins y extensiones concentran gran parte del riesgo, como muestran Patchstack, CosmicSting y SessionReaper.
• Medusa + Sanity reduce la superficie de ataque al quitar PHP y separar comercio y contenido, sin eliminar el riesgo de npm y configuración.

En las próximas entregas de esta serie veremos cómo tener una tienda en línea sin PHP migrando de Magento o WooCommerce a Medusa y cómo construir sitios web seguros sin PHP con Sanity frente a WordPress. Si quieres revisar tu caso, conoce nuestro servicio de tiendas con Medusa o el de migración de WordPress a Sanity.

# Sobre el autor

Arturo Sánchez Gándara es CEO de ia¹, consultora con sede en Guadalajara que diseña tiendas en línea con Medusa y sitios con Sanity, y ayuda a empresas a adoptar inteligencia artificial y a ser visibles en motores de IA.

# Fuentes referenciadas

• PHP: anuncio de seguridad del 21 de octubre de 2026 (PHP2Shell)
• PHP: versiones soportadas
• PHP: ramas sin soporte (EOL)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• The PHP Foundation: Today's PHP security release
• Tenable: PHP2Shell FAQ
• W3Techs: uso de PHP en sitios web
• Patchstack: State of WordPress Security in 2026
• Sansec: CosmicSting attack & defense overview
• Sansec: SessionReaper
• NVD: CVE-2024-34102
• NVD: CVE-2025-54236
• CISA: compromiso de la cadena de suministro en npm (Shai-Hulud)
• Medusa: repositorio oficial
• Sanity: Content Lake