Hoy el PHP publicó la corrección de emergencia para dos fallas críticas que se filtraron antes de la hora. El nombre que la comunidad le dio al caso ya entrega la gravedad: PHP2Shell.
Lo que se sabe, con fuente: las dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, tienen severidad 9.2 Critical y permiten ejecución remota sin autenticación. Y el PHP corre en alrededor de siete de cada diez sitios de la web.
Cómo funcionan las dos fallas
En el primer camino, el tratamiento de desborde de memoria interrumpe el PHP con datos internos inicializados a la mitad, y la limpieza de la petición trata lo inválido como válido. En el segundo, el estado interno de una petición sobrevive a la memoria que lo sostenía, y la petición siguiente en el mismo worker usa ese estado antes del reset.
El camino confirmado pasa por session.upload_progress: una feature legada que viene activada por defecto y que la mayoría de los desarrolladores olvidó que existe. La superficie de ataque es, casi siempre, lo que quedó activado desde la instalación.
La cronología es la lección
Los detalles se filtraron antes del plazo combinado, la prueba de concepto se hizo pública en horas, y la corrección de emergencia salió al día siguiente del filtrado, con el PHP ejerciendo justamente la cláusula que había escrito en el aviso: lanzar antes si los detalles se vuelven públicos o si hay explotación activa.
Y el peor escenario está sin rodeos en el aviso oficial: todas las instalaciones que sirven web, con mod_php como el caso grave, donde existe exploit demostrado que corre antes de cualquier línea de tu código.
La respuesta del mercado, el mismo día
Cloudflare activó protecciones en el borde, los proveedores de hosting publicaron reglas propias, y la orientación europea de ciberseguridad recomendó sacar del aire el sitio expuesto que no pudiera ser corregido. Cientos de sitios ya están fuera de línea de forma preventiva.
Es la respuesta que la gravedad pide: RCE sin autenticación en un runtime de siete de cada diez sitios no es ciclo mensual de parche, es emergencia con sitio fuera de línea preventivo como medida legítima.
Qué hacer hoy, en este orden
- Actualizar a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (el aviso oficial dice que la mitigación no sustituye la corrección).
- Confirmar el paquete de tu proveedor: las distribuciones recibieron los parches con antelación.
- Si no cabe hoy: desactivar la feature de sesión comprometida con reinicio de todos los workers y apretar los límites de memoria y de tamaño de POST en el borde.
- Migrar de línea quien está en PHP 8.1 o más viejo: esas versiones no reciben más corrección del proyecto.
En Tech86, ese fue el trabajo del día para los clientes: inventariar qué corre PHP en cada host, aplicar la corrección o mitigación y documentar, en el mismo diseño de operación que aplicó el parche del core de WordPress la semana pasada.
Conclusión
El PHP2Shell cierra la semana en que los runtimes pasaron a ser blanco en masa, y la reflexión que queda es la del inventario: la feature vulnerable era una que la mayoría olvidó que existía, activada por defecto desde siempre.
Parche hoy, migración de línea en la semana, y el inventario de features activadas por defecto en el backlog permanente. El boletín informa; el inventario protege.