PHP2Shell: fallo crítico en PHP afecta al 70% de la web

Una sola petición HTTP, sin usuario ni contraseña, puede bastar para ejecutar código en el servidor que aloja tu web. Wiz Research reveló PHP2Shell, dos vulnerabilidades críticas en el núcleo de PHP —el lenguaje que sostiene cerca del 70% de los sitios web del mundo— con severidad CVSS 9.2 y versiones afectadas que se remontan a PHP 5.4. Los parches ya están publicados y el reloj corre.

Si tu startup opera con WordPress, Drupal, Joomla, Magento o cualquier aplicación PHP, esto no es una noticia de seguridad lejana: es una tarea de hoy.

¿Qué es PHP2Shell y por qué no es una vulnerabilidad más?

PHP2Shell agrupa dos fallos registrados como CVE-2026-109618 y CVE-2026-109619. Ambos son problemas de seguridad de memoria: errores en cómo PHP gestiona los errores fatales mientras procesa peticiones, en particular los errores de memoria agotada (out-of-memory). Esos fallos dejan un estado interno corrupto que una petición posterior —o otro worker del servidor— puede reutilizar, lo que deriva en divulgación o corrupción de memoria.

El impacto práctico, según la investigación de Wiz, incluye dos cosas que deberían preocupar a cualquier founder:

• Ejecución remota de código sin autenticación: un atacante ejecuta su propio código en el servidor afectado.
• Lectura de memoria del proceso: esa memoria puede contener contraseñas, tokens de autenticación, claves de API y certificados pertenecientes a otras peticiones o al propio servidor.

Wiz documentó cuatro bugs explotables agrupados en esas dos CVEs: un uso después de liberar (use-after-free) en el deserializador de progreso de subida, una divulgación remota de memoria del proceso, un use-after-free en la traza de errores fatales y una confusión de tipos en OPcache que corrompe el estado compartido entre workers.

La parte crítica es dónde vive el fallo: en el motor de PHP, no en la aplicación. La explotación no depende de un error en el código del sitio. Wiz demostró ejecución remota de código sin autenticación sobre imágenes Docker actuales de WordPress, Drupal y Joomla, y aclaró que incluso una aplicación trivial de tipo "Hello World" corriendo sobre una versión afectada es vulnerable.

¿Qué versiones están afectadas y a cuál debes actualizar?

Según la fuente original, cada versión de PHP publicada en la última década está afectada por al menos uno de estos problemas, hasta llegar a PHP 5.4.

Las actualizaciones que corrigen las fallas, reportadas por Help Net Security, son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El proyecto PHP ya no da soporte a PHP 8.1 ni anteriores, por lo que publicó backports mínimos de código fuente para PHP 7.4, 8.0 y 8.1, pensados para quienes compilan desde código o no tienen un proveedor de soporte extendido.

El alcance no se limita a una forma de servir PHP. Help Net Security detalla que están expuestos PHP-FPM, Apache con modphp, php-cgi, FrankenPHP y LiteSpeed, y que las configuraciones con modphp enfrentan el mayor riesgo. Quienes usan el repositorio mantenido por voluntarios rpms.remirepo.net deberían migrar a los paquetes de su distribución o compilar PHP por su cuenta, porque ese repositorio no tendría actualizaciones disponibles el mismo día del anuncio.

El punto de inflexión: la IA bajó la barrera del exploit

Lo más relevante de esta historia para el ecosistema emprendedor no es solo el fallo, sino cómo se encontró. El código vulnerable llevaba más de una década en el repositorio de PHP. Convertir esas fallas en un exploit funcional requería encadenar varios bugs y adaptarse a cómo cada versión y configuración asigna y reutiliza memoria. Según Wiz, ese trabajo era prácticamente inviable de escalar antes de la IA.

El equipo usó Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol. La conclusión que firman es contundente: con modelos de frontera y las herramientas adecuadas, un solo investigador completó en una semana lo que antes habría exigido meses de trabajo a un equipo de primer nivel. Wiz enmarca PHP2Shell como un punto de inflexión comparable a Heartbleed (2014) y Log4Shell (2021), pero esta vez por lo que revela sobre la explotación asistida por IA: cuando el esfuerzo de desarrollar y adaptar exploits cae, vulnerabilidades que parecían impracticables se vuelven objetivos viables.

La misma capacidad juega a favor de la defensa. La cita que acompaña el anuncio, atribuida a Raluca Ada Popa, responsable de Seguridad de Gemini en Google DeepMind, apunta a eso: durante más de una década estos fallos quedaron sin resolver porque descubrirlos y explotarlos era demasiado complejo, y la IA permite a los defensores cerrar esa brecha.

¿Qué significa esto para tu startup?

La mayoría de las startups hispanohablantes no tiene un equipo de seguridad dedicado. Eso hace que la velocidad de reacción importe más que la perfección del proceso. Estas son las acciones concretas por prioridad:

• Inventaria toda tu superficie PHP, no solo la que recuerdas. El punto ciego habitual son los entornos que nadie actualiza: landings antiguas, sitios de campañas, staging, plugins de terceros, imágenes Docker fijadas a una versión vieja y servidores gestionados por agencias. Según Help Net Security, toda instalación de PHP que sirva peticiones web está afectada.
• Parchea hoy o aísla. El NCSC del Reino Unido pidió actualizar de inmediato y considerar sacar de línea los sistemas que no se puedan corregir en el momento. CERT-EU recomendó identificar todas las aplicaciones PHP y prepararse para parchearlas de una sola vez; donde eso no sea posible, sugiere aislar las aplicaciones expuestas a internet hasta aplicar la corrección.
• Si no puedes parchear en minutos, activa mitigaciones temporales. Según Help Net Security, Cloudflare ya desplegó un primer conjunto de reglas WAF para los vectores conocidos y están disponibles para todos los clientes, incluidos los del plan gratuito. Es una red de seguridad, no un reemplazo del parche.
• Asume explotación masiva, no teórica. SecurityWeek reporta que WatchTowr logró reproducir una de las vulnerabilidades y que Sansec estima que la explotación masiva podría empezar dentro de los 15 minutos posteriores a la publicación del parche. El dato más útil para calibrar tu urgencia viene de hace un mes: WordPress corrigió en septiembre un fallo crítico sin autenticación con CVSS 9.2, CVE-2026-87902, y según BleepingComputer las primeras peticiones maliciosas aparecieron menos de cinco horas después de que se liberara el parche, con un aumento de diez veces en la actividad en los días siguientes.

¿Qué revisar en tus logs mientras llega el parche?

Wiz advierte que estas fallas se ejecutan por debajo de la capa de aplicación, así que los logs de tu aplicación pueden tener poco contexto. Las señales que recomienda vigilar hasta parchear son:

• Peticiones multipart inusuales seguidas de errores de límite de memoria o respuestas HTTP 500 repetidas.
• Cookies de respuesta PHPSESSID anormalmente grandes o malformadas.
• Rotación inexplicable de workers de PHP (worker churn).

Para quien usa un gestor de contenidos, vale recordar que PHP2Shell no requiere que tu CMS tenga un error propio. El parche de PHP es la única remediación completa; las mitigaciones de red y las detecciones ayudan a ganar tiempo, pero no cierran el problema.

Conclusión

PHP2Shell combina dos ingredientes que rara vez coinciden: un fallo en infraestructura compartida por la mayor parte de la web y una barrera de explotación que la IA acaba de derribar. Para un founder, la lección operativa es doble. Primero, la remediación es binaria: o actualizas a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o dependes de mitigaciones que no eliminan el riesgo de raíz. Segundo, el inventario vuelve a demostrar su valor: como resumió el experto en forense Hal Pomeranz a Help Net Security, hay demasiadas instalaciones embebidas que nunca se parchean y demasiadas aplicaciones olvidadas, y eso anticipa una cola larga de incidentes.

La pregunta útil no es si tu startup está expuesta, sino cuántas instalaciones PHP tienes y quién es responsable de actualizar cada una. Si no puedes responder eso hoy, empieza por ahí.

Fuentes

• Wiz Research: PHP2Shell (fuente original)
• Help Net Security: PHP2Shell, critical PHP vulnerabilities patched
• SecurityWeek: PHP2Shell, mass exploitation looms
• Infosecurity Magazine: critical PHP vulnerabilities leaked
• The Next Web: EU cybersecurity team on unpatched PHP sites
• The Hacker News: WordPress patch for critical flaw
• BleepingComputer: hackers start exploiting critical WordPress flaw