La emergencia PHP2Shell puso el foco de los inversores en las empresas de ciberseguridad: mientras administradores de sitios web buscaban cómo proteger sus sistemas o instalar parches, el firewall de aplicaciones web de Cloudflare era directamente relevante para esa respuesta. La acción de Cloudflare subió más de un 6% en operaciones intradía, y otras compañías de seguridad y software también avanzaron. Pero el movimiento no se explica solo por las fallas de PHP: los reportes también señalaron una rotación desde acciones de semiconductores hacia el software y noticias separadas sobre la colaboración de Nvidia y CrowdStrike en seguridad para IA.
19
20
22
17
Qué impulsó las acciones
La divulgación de las vulnerabilidades y el cierre preventivo de algunos sitios llevaron la atención del mercado hacia el gasto en seguridad. TradingKey vinculó el incidente con avances en empresas de software relacionadas, entre ellas Datadog, Okta y Zscaler. Otro informe de la tarde situó a Cloudflare con una subida cercana al 7% y a Palo Alto Networks con un alza del 4%. Son cifras intradía reportadas, no rendimientos de cierre verificados, y no demuestran que el incidente de PHP causara por sí solo el movimiento de cada acción.
19
20
Cloudflare tenía una conexión especialmente visible con el episodio: la empresa dijo que había desplegado protecciones de firewall de aplicaciones web (WAF, por sus siglas en inglés) contra las fallas. Eso hizo que sus servicios fueran pertinentes para las organizaciones que buscaban reducir su exposición mientras aplicaban una actualización. Una regla de firewall puede servir como medida de mitigación, pero no reemplaza la actualización del entorno PHP.
15
11
También había otros factores en juego. Un reporte describió un traslado de capital desde acciones de semiconductores hacia empresas de software, en medio de inquietudes sobre el gasto en infraestructura de IA y los costos de financiamiento. Otro atribuyó parte de la subida de CrowdStrike a la ampliación de su colaboración con Nvidia en seguridad para IA; ese mismo informe registró avances en Datadog y Okta. Estas noticias ayudan a entender por qué el repunte del día fue más amplio que la historia de PHP.
22
17
En qué consistían las fallas de PHP
Las dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, se conocieron en conjunto como PHP2Shell. Los reportes les asignaron una puntuación de 9,2 en la escala CVSS v4.0 y describieron el riesgo como ejecución remota de código sin autenticación: un atacante podría llegar a ejecutar código en un servidor vulnerable sin iniciar sesión.
14
15
Cloudflare describió el grupo afectado como servidores web que usaban PHP 5.4 o una versión posterior. Las actualizaciones de emergencia para ramas compatibles fueron PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
15
8
Los desarrolladores de PHP alertaron sobre las fallas el martes 20 de octubre y las correcciones estuvieron disponibles al día siguiente. Un reporte indicó que la actualización correctiva se confirmó cerca de las 13:45 GMT del 21 de octubre.
13
9
Por qué algunos sitios quedaron fuera de línea
Sitios web de gobiernos, hospitales y universidades de distintos puntos de Europa se desconectaron como medida preventiva mientras sus administradores trabajaban para atender las vulnerabilidades. Que un sitio se haya cerrado temporalmente no demuestra, por sí solo, que hubiera sido atacado con éxito.
3
El aviso de incidentes de Wikimedia mencionó específicamente Cloud VPS y Toolforge entre los servicios desconectados durante el mantenimiento preventivo. Eso no significa que todos los servicios de Wikipedia estuvieran fuera de línea.
7
La preocupación también se explica por el amplio uso de PHP: un reporte estimó que esta tecnología está presente en alrededor del 70% de los sitios web. Esa cifra habla de su alcance, no del número de sitios que eran vulnerables o que fueron comprometidos.
8
Qué deben tener en cuenta quienes administran sitios web
Cloudflare dijo que estaba observando ataques incipientes, mientras que otros reportes señalaron que varias agencias nacionales no habían detectado explotación. Ambas cosas pueden ser ciertas: la cobertura y el periodo de observación varían, y no haber detectado actividad no demuestra que un sistema vulnerable esté a salvo.
1
3
Si tienes un sitio pequeño en un servicio de alojamiento compartido, confirma con el proveedor que el servidor haya actualizado su entorno PHP a una versión corregida o que haya aplicado un parche alternativo proporcionado por el proveedor. Actualizar el sistema de gestión de contenidos no necesariamente actualiza la versión de PHP que lo ejecuta. Considera el firewall de aplicaciones web como una capa temporal de protección y pregunta al proveedor qué corrigió y cuándo.
11
14