PHP parchea PHP2Shell: dos fallos RCE con CVSS 9.2

PHP2Shell: el parche de emergencia ya está y la ventana de exposición recién se abre

Dos vulnerabilidades de ejecución remota de código en PHP, valoradas en 9.2 sobre 10 bajo CVSS v4.0, obligaron a publicar parches de emergencia en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. La comunidad de seguridad las bautizó PHP2Shell: el salto de una petición HTTP normal a una shell viva dentro del servidor.

Para un founder, la lectura es directa. PHP sostiene entre el 75% y el 80% de los sitios web del mundo, según BleepingComputer, y VirusTotal estima que hay más de 5,1 millones de hosts PHP expuestos en línea, de los cuales unos 3,8 millones tienen al menos un puerto abierto. Si tu producto, tu landing o el panel de tu cliente corre sobre PHP, esto no es una nota de seguridad ajena.

¿Qué son CVE-2026-109618 y CVE-2026-109619?

Ambas fallas comparten la misma raíz: PHP puede dejar su memoria en estado corrupto cuando una petición termina de forma anormal. Lo que las hace graves es dónde viven: en la gestión de memoria y el manejo de errores, dos zonas que casi cualquier petición toca.

• CVE-2026-109618: una cadena de debilidades que provoca corrupción por agotamiento de memoria (OOM) y permite ejecutar código con la cuenta del worker web. Según sansec.io, citado por Investing.com, también arrastra una fuga de memoria estilo Heartbleed capaz de exponer contraseñas, tokens de sesión, claves de API y claves privadas TLS de otras peticiones, sin que la aplicación llame siquiera a session_start().
• CVE-2026-109619: un estado global obsoleto que habilita un use-after-free en el heap sin autenticación, divulgación de memoria y ejecución remota de código con los privilegios del worker.

El alcance es amplio: afectan a toda instalación que sirva peticiones web, incluidas PHP-FPM, Apache con modphp, php-cgi, FrankenPHP y LiteSpeed. El equipo de seguridad de PHP advirtió que el riesgo es mayor en modphp, donde una petición no autenticada puede disparar el ataque antes de que se ejecute una sola línea del código de la aplicación.

La fuga que rompió el embargo: cronología de 48 horas

El proceso de divulgación coordinada funcionó bien hasta dos días antes de la fecha objetivo. El martes 20 de octubre, alrededor de las 15:00 UTC, los dos identificadores CVE empezaron a circular en foros y redes sociales con una hora de publicación equivocada y un CVSS de 10.0 que no era real (la puntuación correcta es 9.2). No se filtraron detalles técnicos.

La respuesta fue rápida: el proyecto adelantó su preanuncio a las 19:30 UTC y movió la publicación del 22 de octubre a las 14:00 UTC al 21 de octubre a las 14:00 UTC. Los distribuidores todavía estaban empaquetando el parche, así que publicar de inmediato habría dejado a muchos usuarios sin una vía simple de actualización.

Alrededor de las 20:00 UTC, Calif —una de las firmas que había reportado los fallos— publicó por error un video con su prueba de concepto funcionando contra varios objetivos. Copias del video borrado circularon en redes y aceleraron el desarrollo de PoCs.

El golpe final llegó el 21 de octubre a las 07:41 UTC, más de seis horas antes de la divulgación coordinada: Chainguard rompió el embargo de forma unilateral y publicó imágenes ya construidas con el parche. Cualquier atacante podía estudiar la corrección en formato binario mientras el resto del ecosistema seguía esperando. Cloudflare registró los primeros ataques contra sitios PHP a las 07:43 UTC, dos minutos después, según Investing.com.

Por qué un fallo detectado en 2024 tardó dos años en arreglarse

En 2024, PHP pasó por su primera auditoría de seguridad externa en años, financiada por la Sovereign Tech Agency, organizada a través de OSTIF y ejecutada por Quarkslab. Mientras corregía uno de los hallazgos, un desarrollador del core contratado por la PHP Foundation encontró los primeros indicios del problema de OOM detrás de CVE-2026-109618. Ese año se teorizó un posible exploit, pero no aparecieron vectores concretos.

El equipo de seguridad desarrolló varios enfoques en competencia, cada uno con su costo: romper compatibilidad hacia atrás, abrir una nueva vía de denegación de servicio o exigir cambios en decenas de extensiones de terceros imposibles de coordinar. Operando por consenso, el equipo se trabó. La propia PHP Foundation lo describe sin matices: fue una falla estructural, causada tanto por el proceso de decisión como por la falta de recursos.

Desde entonces cambiaron cosas. En mayo de 2026 se creó el Ecosystem Security Team; Volker Dusch trabaja como AI Security Engineer in Residence; Alexandre Daubois se sumó en julio y Daniel Scherzer en septiembre. La fundación también incorporó herramientas de IA —un escaneo con Claude Mythos de Anthropic junto a Alpha-Omega, y Daybreak Red de OpenAI para validar reportes y exploits— además de builds con sanitizers.

El punto de quiebre llegó con el programa Patch the Planet: la firma Calif inició una auditoría el 30 de julio de 2026 y el 11 de agosto el investigador Ryan A reportó una ejecución remota de código incondicional con la misma causa raíz de 2024. OpenAI reportó la misma raíz ese mismo día, con vectores adicionales el 18 de septiembre, y Wiz sumó los suyos el 24 de agosto. Desde el 11 de agosto, arreglar el problema pasó a ser la prioridad absoluta del equipo.

¿Qué versiones quedaron sin parche?

Solo las cuatro ramas soportadas —8.2 a 8.5— reciben la actualización. Todo lo anterior, de PHP 5.x a 8.1.x, está al final de su vida útil y no tendrá parche oficial, aunque el equipo publicó backports mínimos de código fuente para PHP 7.4, 8.0 y 8.1 pensando en quienes compilan desde cero o no tienen un proveedor LTS.

Ahí está la aritmética incómoda de PHP2Shell: el software está en todas partes y las instalaciones más viejas y abandonadas son las más difíciles de arreglar.

Qué significa esto para tu startup

Si tu producto corre sobre PHP, hoy tienes cuatro tareas concretas:

• Inventaría cada instalación de PHP, no solo la de tu servidor principal. Contenedores, appliances de proveedor, paneles como cPanel y Plesk y plataformas CMS suelen quedar fuera del radar. Wordfence advirtió que las actualizaciones automáticas no aplican este parche, así que confirma versión por versión.
• Parchea primero lo expuesto a internet y verifica si tu distribución Linux o tu hosting ya publicaron builds con el backport. Si no puedes actualizar de inmediato, el equipo de PHP publicó mitigaciones parciales: memory_limit=-1 vía php_admin_value en el pool de FPM o Apache, post_max_size en 8M (32M si necesitas subidas), session.upload_progress.enabled=0 y, en PHP 8.5, fatal_error_backtraces=0. Ninguna bloquea todos los vectores: la única defensa definitiva es el parche.
• Vigila qué procesos lanza PHP. La explotación suele verse como un worker PHP ejecutando algo anómalo: una shell, un intérprete de scripts o una herramienta de descarga. Si detectas compromiso, aísla el servidor, preserva los logs web y de PHP y busca webshells, archivos nuevos en la raíz del sitio y tareas programadas o cuentas desconocidas.
• Prepara el inventario para tus clientes. Si vendes SaaS a empresas, tu equipo de seguridad o tu comprador va a pedir evidencia de parcheo en las próximas horas. Tener la lista de versiones y fechas de aplicación lista te ahorra una semana de correos incómodos.

El problema de fondo: la infraestructura crítica que casi nadie financia

PHP mueve servicios de gobierno, tiendas online, bancos y medios. Sin embargo, su seguridad depende de un grupo pequeño de desarrolladores financiados por la fundación y algo de trabajo voluntario. La IA acelera el descubrimiento de errores —para defensores y atacantes por igual— y el volumen de reportes crece: desde el 1 de julio, el equipo publicó 15 CVE y procesó más de 100 reportes que resultaron inválidos, duplicados o no reproducibles. La IA ayuda a validar y agrupar reportes, pero cada decisión y cada parche los hace una persona.

Lo que ninguna herramienta puede hacer es decidir el arreglo correcto para una decisión de diseño de hace años, sopesar el costo de compatibilidad y revisar el parche. Eso requiere ingenieros que conozcan todo el código de PHP, y hoy hay muy pocos.

Conclusión

PHP2Shell deja tres lecciones para cualquier equipo técnico. Primero, la dependencia invisible es la más peligrosa: nadie tiene PHP en su roadmap y aun así sostiene buena parte de su producto. Segundo, el embargo es tan frágil como la parte menos disciplinada de la cadena —una filtración en un foro y una imagen publicada antes de tiempo bastaron para adelantar los ataques. Tercero, la seguridad del software libre que usas gratis se financia con donaciones: si tu negocio depende de PHP, financiar a la PHP Foundation es una decisión de gestión de riesgo, no de filantropía.

Actualiza hoy, verifica mañana y asume que este tipo de episodios se repetirá.

Fuentes

• PHP Foundation — Today's PHP security release and how we're strengthening PHP security
• BleepingComputer — PHP ships emergency patches for critical PHP2Shell flaws
• Investing.com vía Yahoo Finance — PHP patches critical flaw hitting 70% of websites
• Techaeris — PHP2Shell: The Emergency PHP Patch Is Out