Qualys, Inc., proveedor pionero y líder en soluciones de gestión de riesgos basadas en la nube, ha hecho público un análisis sobre las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 detectadas la semana pasada en los sistemas PHP, que suponen la exposición de más del 70% de los sistemas web de todo el mundo. Dicho análisis concluye que la mayoría de las instalaciones analizadas siguen expuestas o utilizan versiones sin soporte.
Las dos vulnerabilidades, bautizadas como PHP2Shell, tienen una puntuación CVSS de 9.2 y pueden permitir la ejecución remota de código sin autenticación, con el consiguiente riesgo de divulgación de contraseñas, tokens de autenticación y claves de API. Aunque PHP ha publicado correcciones, el análisis de datos anonimizados de más de 10.000 clientes de Qualys muestra que disponer de una actualización no garantiza que el riesgo haya desaparecido.
De los 156 millones de instalaciones con versión conocida, 44 millones (un 28%) ejecutaban versiones con soporte -para las que ya existe una corrección- mientras que 110 millones (el 71%) utilizaban ramas sin soporte. “Esto significa que muchas de estas instalaciones no recibirán un parche del proveedor”, explica Sergio Pedroche, Country Manager de Qualys Iberia. “Además, actualizar o parchear sistemas críticos puede tener impacto en el negocio, por lo que es importante mitigar el riesgo mientras se prepara una solución definitiva”.
El análisis contabilizó un total de 167 millones de instalaciones de paquetes PHP, el 73% en activos accesibles desde internet. En las primeras 24 horas desde la divulgación, solo 581.000 instalaciones (el 0,37% del total analizado) habían sido parcheadas.
La respuesta a PHP2Shell exige una visión completa del entorno, priorizar y verificar. En los sistemas sin soporte, la estrategia debe incluir una decisión explícita entre aplicar una corrección del proveedor cuando exista, aislar el servicio o retirarlo mediante una migración.
Los analistas de Qualys cuatro pasos para mitigar el riesgo:
1. Descubrir todas las instalaciones. Inventariar dónde se ejecuta PHP, incluidas las instalaciones integradas en otras aplicaciones, los servidores tradicionales, las imágenes de máquinas virtuales, los contenedores, Kubernetes y las funciones sin servidor. Registrar las versiones, configuraciones y exposición a internet, y contrastar los resultados con los avisos de PHP y del proveedor de cada distribución.
2. Priorizar y validar la exposición. Dar prioridad a los activos accesibles desde internet, las versiones antiguas y los despliegues de Apache mod_php. Evaluar la configuración y los controles existentes para distinguir entre sistemas que solo utilizan una versión potencialmente afectada y aquellos cuyo punto de entrada vulnerable es realmente accesible. Las pruebas de seguridad de aplicaciones web y API pueden ayudar a identificar servicios y puntos finales que no figuren en el inventario.
3. Corregir o contener. Actualizar las ramas de PHP con soporte conforme a las indicaciones oficiales y reiniciar los servicios para que la corrección entre en vigor. En versiones antiguas, comprobar si el proveedor ofrece correcciones retroportadas. Asimismo, y dado que actualizar o parchear sistemas críticos puede tener impacto en el negocio, si no existe una corrección aplicable, reducir el riesgo mediante restricciones de acceso o aislamiento temporal y planificar la migración o retirada del sistemaLas medidas de contención son provisionales y no sustituyen una solución definitiva.
4. Verificar el cierre de la exposición. Volver a analizar los activos y aplicaciones después de actualizar o aplicar mitigaciones. Confirmar que se ejecuta la versión prevista, que los procesos se han reiniciado y que el punto de entrada vulnerable ya no es accesible. Documentar los resultados y mantener identificados los sistemas que siguen pendientes de corrección o migración.
