En esta noticia
Una sola petición HTTP, sin credenciales, puede alcanzar para ejecutar código en el servidor que aloja el sitio de una empresa, su intranet o el portal de autogestión de sus clientes. Eso es, en síntesis, PHP2Shell: el nombre con el que la industria bautizó a dos vulnerabilidades del núcleo de PHP que obligaron al proyecto a publicar parches de emergencia el 21 de octubre.
La comparación con Log4Shell, el agujero que en 2021 puso en alerta a medio mundo corporativo, no es casual. Como entonces, la falla no está en una aplicación puntual sino en una pieza de infraestructura que está en todos lados, muchas veces sin que nadie la tenga registrada. Y como entonces, la primera pregunta que deben responder los equipos de tecnología no es cómo parchear, sino dónde.
Una falla en los cimientos
PHP2Shell agrupa dos registros del catálogo internacional de vulnerabilidades: CVE-2026-109618 y CVE-2026-109619. Ambas son errores en la gestión de memoria del motor de PHP y recibieron un puntaje de 9,2 sobre 10 en la escala CVSS, el estándar con el que la industria mide la gravedad. Según los avisos oficiales de PHP, permiten la ejecución remota de código sin autenticación, con los permisos del proceso que atiende las solicitudes web.
El alcance es amplio. Están expuestas todas las instalaciones de PHP que atienden tráfico web, ya sea con Apache mod_php, PHP-FPM, php-cgi, FrankenPHP o LiteSpeed. Las fallas afectan versiones que se remontan a PHP 5.4, y Palo Alto Networks identificó más de 22,6 millones de instancias expuestas en internet potencialmente vulnerables.
La historia tiene, además, un componente de época. Las fallas fueron detectadas con ayuda de un modelo de inteligencia artificial de OpenAI, que coordinó durante dos meses con mantenedores e investigadores la preparación de los parches. Pero los identificadores se filtraron en redes sociales un día antes de la publicación oficial, y Cloudflare informó que ya observaba los primeros intentos de ataque. La ventana entre la divulgación y la explotación, otra vez, se midió en horas.
La corrección exige actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según la rama. Quienes todavía usan 8.1 o versiones anteriores, que ya no reciben soporte oficial, deben migrar a una rama vigente o recurrir a los paquetes corregidos de su distribución de Linux o de un proveedor de soporte extendido. PHP publicó cambios de configuración temporales para ganar tiempo, pero aclaró que no vuelven segura una instalación: solo la actualización lo hace.
El verdadero problema: no saber qué se tiene
En teoría, la respuesta es sencilla: actualizar. En la práctica, el cuello de botella aparece antes. PHP no vive solo en el sitio institucional. Está en servidores de desarrollo que nadie apagó, en aplicaciones internas heredadas, en sistemas de terceros que lo incluyen sin que figure en ningún contrato y en sitios de WordPress administrados por distintas áreas.
Madelein van der Hout, analista senior de Forrester, lo resumió ante la prensa especializada: como PHP sostiene aplicaciones de muchas organizaciones y de sus proveedores, revisar solo el sitio corporativo no alcanza. Las empresas, sostuvo, primero tienen que establecer dónde están expuestas y priorizar los sistemas abiertos a internet.
La región no es ajena. En Colombia, el equipo nacional de respuesta a incidentes, Colcert, emitió una alerta crítica, reportó más de 8.600 servicios con PHP expuestos a internet y recomendó, como primer paso, hacer un inventario de dónde corre PHP. Gobiernos de Europa, Asia y Estados Unidos pidieron actualizar o desconectar los sistemas afectados.
Hay además una trampa técnica que complica cualquier relevamiento manual. Distribuciones de Linux como Ubuntu incorporan la corrección sin cambiar el número de versión original de PHP. Un servidor puede parecer vulnerable en una planilla y estar protegido, o al revés. Sin datos actualizados y centralizados, cada equipo termina revisando servidor por servidor, por SSH, mientras el reloj corre.
“Cuando aparece una vulnerabilidad como PHP2Shell, el parche suele estar disponible en horas. Lo que demora la respuesta es otra cosa: saber dónde está instalado ese software. Las empresas que tienen su inventario actualizado pueden pasar de la alerta a la acción en minutos; las que dependen de planillas pierden días buscando servidores mientras siguen expuestas. Hoy la gestión de activos ya no es solo una cuestión de orden o de costos, es la primera línea de la ciberseguridad”, afirma Ariel Gesto, CEO y fundador de InvGate.
Del inventario a la lista de trabajo
Ahí es donde la gestión de activos de IT deja de ser una tarea administrativa y pasa a ser una herramienta de seguridad. InvGate, la compañía fundada por Ariel Gesto que desarrolla software de gestión de servicios y activos de IT, publicó una guía para que los equipos ubiquen las instalaciones vulnerables con su plataforma InvGate Asset Management.
El punto de partida es el inventario de software. El agente de la plataforma registra la versión exacta de PHP instalada en cada servidor y computadora que cubre, y la consolida junto con los datos que llegan del descubrimiento de red, las integraciones y las cargas manuales. Con un filtro, el equipo de IT obtiene en minutos todos los activos con PHP que no están en una versión corregida, junto con su responsable y su ubicación.
Ese filtro puede guardarse como una Etiqueta Inteligente, una lista que se mantiene sola: un activo entra cuando cumple las condiciones de riesgo y sale cuando el agente reporta la versión con el parche. Así, la nómina de pendientes se achica a medida que avanza la remediación, sin planillas paralelas ni conciliaciones manuales.
El último paso es la visibilidad para la gerencia. Un tablero muestra cuántos activos tienen PHP, cuántos usan ramas sin soporte, en qué sedes se concentra la exposición y cuántos ya están actualizados. Es, en los hechos, el reporte de avance que hoy piden las áreas de seguridad, auditoría y los directorios.
La lógica excede a PHP2Shell. La próxima vulnerabilidad crítica en un componente masivo, sea una librería, un servidor web o un sistema operativo, planteará la misma pregunta inicial. Las organizaciones que ya tienen un inventario confiable y centralizado empiezan esa carrera con ventaja.
Qué deberían hacer hoy las empresas
Los especialistas coinciden en una secuencia de respuesta:
- Mapear la exposición. Relevar todos los sistemas internos y públicos que ejecutan PHP, incluidos los de proveedores.
- Priorizar lo expuesto a internet. Los servidores accesibles desde afuera y las ramas sin soporte van primero.
- Actualizar. Pasar a la versión corregida de cada rama y reiniciar los servicios para que la tomen. En Linux, contrastar con el aviso de seguridad de la distribución.
- Mitigar o aislar lo que no pueda esperar. Aplicar los ajustes temporales de PHP o limitar la exposición del servidor hasta parchearlo.
- Buscar señales de compromiso. Un parche cierra la puerta, pero no expulsa a quien ya pudo haber entrado.
PHP2Shell deja una lección que va más allá de PHP: en ciberseguridad, la velocidad de respuesta depende de algo tan poco glamoroso como saber qué hay instalado y dónde. Las empresas que todavía gestionan sus activos en planillas lo descubrieron esta semana.