Las vulnerabilidades críticas de PHP de esta semana las detectó inteligencia artificial en un código con más de diez años de antigüedad, y las próximas podrían aparecer en cualquier tecnología que uses, así que la pregunta es si conoces tus propios sistemas lo bastante bien como para encontrarlas a tiempo. Lo escribimos desde el equipo de Tinet.
El miércoles 21 de octubre el proyecto PHP publicó un mensaje inusualmente directo, en el que recomendaba encarecidamente a todos los usuarios que actualizaran de inmediato. En cuestión de horas organizaciones de todo el mundo empezaron a desconectar sistemas: Wikimedia desactivó varios por precaución, el gobierno finlandés, el Ayuntamiento de Edimburgo, la BBC y la agencia holandesa de ciberseguridad retiraron sitios o páginas de la red, la Universidad de Ginebra desconectó sus sitios web y la Agencia de Seguridad Nacional de EE. UU. recomendó desconectar cualquier sistema que no pudiera parchearse con urgencia. Es tentador leer esto como un problema de PHP, pero PHP simplemente fue la primera tecnología importante en pasar por algo que ahora todas las organizaciones deberían esperar.
Lo que pasó fue que investigadores de las empresas de seguridad Calif y Wiz, trabajando con OpenAI, descubrieron dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, que el equipo de seguridad de PHP calificó con un 9,2 sobre 10. Dicho en simple, permiten que un atacante tome el control de un servidor web sin iniciar sesión, y en la configuración más expuesta el ataque se ejecuta incluso antes de que comience a correr el código del propio sitio.
Hay tres detalles que me parecen más importantes que lo técnico. El primero es que las fallas eran antiguas, ya que según los investigadores la ruta de código vulnerable se remonta a PHP 5.4, lanzado en 2012, y sobrevivió a más de una década de revisiones, pruebas y uso en producción. El segundo es que las detectó la IA, porque tanto Calif como Wiz dijeron que usaron modelos de IA en su investigación y Wiz las describió como las fallas más graves encontradas hasta ahora con esa herramienta. El tercero es que los atacantes llegaron primero: el equipo de inteligencia de amenazas de Amazon detectó un intento de explotación el 17 de octubre, cuatro días antes de que se publicaran los parches, y todavía no sabe cómo obtuvieron la información. El 20 de octubre se filtraron en línea los identificadores de las vulnerabilidades y PHP adelantó su lanzamiento un día, y para el 21 Amazon informó que las fallas estaban siendo “explotadas ampliamente en el mundo real”.
Según W3Techs, PHP corre en el 69,3 % de todos los sitios web cuyo lenguaje del lado del servidor se puede identificar, y las estimaciones de servidores vulnerables expuestos a Internet van desde alrededor de 1,3 millones hasta más de 1,9 millones.
La parte que la mayoría de los titulares ignoró
La recomendación oficial es actualizar a la versión más reciente, aunque que se pueda hacer o no depende de la versión que esté usando cada uno.
Para PHP 8.2 a 8.5 ya hay versiones parcheadas disponibles (8.2.35, 8.3.36, 8.4.27 y 8.5.12), mientras que para PHP 7.4 a 8.1 no existe una versión oficial y lo único que hay son correcciones mínimas a nivel de código hechas por el equipo de seguridad de PHP. Las versiones 5.4 a 7.3 están en fin de vida útil, así que el proyecto PHP no ofrece ninguna corrección para ellas.
Según W3Techs, el 26,9 % de los sitios web hechos en PHP todavía corre la versión 7 y el 7,7 % corre la versión 5, o sea que más de un tercio de esos sitios no tiene una versión oficial parcheada a la que pueda actualizarse.
Para esas organizaciones, «actualizar ahora» no es algo sencillo, porque pasar de PHP 7 a 8 cambia el comportamiento de varias funciones, elimina características y obliga a usar nuevas versiones de las bibliotecas. Una aplicación que ha funcionado sin problemas durante diez años puede fallar de maneras que nadie logra predecir, ya que nadie se acuerda de todo lo que hay detrás de ella, y por eso estas organizaciones quedan atrapadas entre aplicar los parches rápido y arriesgarse a que el sistema se caiga, o hacerlo bien y seguir expuestas mientras los atacantes ya están escaneando el sistema.
Seguramente PHP no será el último
Como le dijo Salil Kanhere, de la UNSW de Sídney, a la BBC, las fallas de fondo no eran nuevas y lo que cambió fue nuestra capacidad para detectarlas. Eso no pasa solo con PHP, porque hace unos meses escribimos sobre el Proyecto Glasswing, en el que los modelos de IA encontraron más de 10.000 vulnerabilidades graves y críticas en el software de sus socios en un plazo de un mes, y algunas de las fallas que salieron a la luz llevaban escondidas 16 e incluso 27 años. La conclusión de Anthropic fue que el cuello de botella en ciberseguridad ya no está en encontrar vulnerabilidades sino en verificarlas, divulgarlas y corregirlas.
Esta semana se vio cómo eso se manifiesta en público. La IA ahora puede revisar código antiguo a una escala que ningún equipo humano alcanza, y va a seguir haciéndolo en todos los lenguajes y bibliotecas que lleven funcionando el tiempo suficiente, como Java, .NET, Python, JavaScript y los componentes de código abierto que van metidos en todos ellos, así que es probable que algunos de esos hallazgos lleguen a manos de atacantes antes de que salgan los parches.
Por eso creo que la frase más peligrosa en una reunión de seguridad esta semana es “no usamos PHP, así que estamos a salvo”. Más que preguntarse si esta falla en particular nos afecta, conviene preguntarse si podríamos saber, rápido y con certeza, cuándo nos va a afectar la próxima.
Ya había pasado antes con Log4j
Hay un precedente que sirve para esto: en diciembre de 2021 una falla crítica en Log4j, una biblioteca de registro que usaban millones de aplicaciones Java, provocó una emergencia global bastante parecida a la de esta semana. Cuando la Junta de Revisión de Seguridad Cibernética de EE. UU. analizó cómo se había respondido, sus conclusiones leídas hoy parecen una descripción de lo que acaba de pasar, porque decían que las organizaciones que mejor manejaron la situación fueron las que “comprendían su uso de Log4j y contaban con recursos técnicos y procesos maduros para administrar los activos”. Su primera recomendación fue “desarrollar la capacidad para mantener un inventario preciso de activos de TI y aplicaciones”, y además advirtió que las copias vulnerables de Log4j “permanecerán en los sistemas durante muchos años, tal vez una década o más”.
Yo lo resumiría diciendo que lo que separó una mala semana de un mal año en esa ocasión no tuvo que ver con la tecnología que usaba cada organización, sino con qué tan bien conocía sus propios sistemas.
El riesgo está en el contexto más que en el lenguaje
Esto se nota cuando se anuncia una vulnerabilidad crítica, porque toda organización tiene que responder las mismas preguntas en cuestión de horas.
- Primero hay que saber dónde lo usamos, incluyendo las intranets antiguas, los sitios de marketing, las herramientas internas y los sistemas que administran los proveedores.
- Después en qué versión, ya que, como acaba de mostrar PHP, la versión es la que define si existe o no una solución.
- También hay que averiguar qué depende de ello, es decir, qué aplicaciones, integraciones y procesos se van a ver afectados si lo actualizamos, lo aislamos o lo desactivamos.
- Qué va a dejar de funcionar si lo cambiamos, además de cómo demostramos que nada más se vio afectado.
Las respuestas a todo eso están en el contexto de tus aplicaciones, o sea en su código, sus dependencias, su historial y las decisiones que hay detrás de ellas. En muchas organizaciones ese contexto vive en la cabeza de unas pocas personas y en documentación que dejó de actualizarse hace años, lo que funciona bien en un día tranquilo, pero en una semana como esta puede significar la diferencia entre aplicar parches en horas y pasarse semanas adivinando.
Qué hacer esta semana
Si usas PHP, el propio proyecto PHP, la CISA, el CERT-EU y Amazon recomiendan los mismos pasos:
- Identificar todas las instalaciones de PHP que tengas, incluidas las que se hayan quedado olvidadas por ahí.
- Después hay que aplicar los parches para las versiones 8.2 a 8.5 y reiniciar todos los procesos de PHP, porque si no el cambio no queda activo.
- Para las versiones más antiguas lo que corresponde es reducir la exposición ahora mismo. PHP publicó cambios temporales de configuración y Cloudflare ofrece reglas de firewall para el tráfico que protege, aunque ninguna de estas medidas garantiza que el sistema quede seguro. Si no puedes aplicar los parches, el CERT-EU recomienda considerar aislar la aplicación de Internet.
- También conviene revisar hacia atrás y no quedarse solo mirando lo que viene. Amazon recomienda investigar la actividad desde el 17 de octubre, y el Centro Nacional de Ciberseguridad del Reino Unido aconseja verificar si quedaron puertas traseras.
- Y hay que ir planeando la solución definitiva, porque en las aplicaciones que siguen en PHP 7 o 5 las medidas temporales únicamente ganan tiempo.
Si no usas PHP, puedes aprovechar la semana para hacer un simulacro. Elige cualquier tecnología central de tu stack y piensa cuánto tiempo te tomaría identificar todos los lugares donde se ejecuta, todas las versiones que tienes y todo lo que depende de ella, y si la respuesta honesta es “unas semanas”, ahí tienes tu vulnerabilidad real.
Cómo lo abordamos en Tinet
Hay que dejar algo claro desde el principio: Suite Loica no detecta vulnerabilidades ni aplica parches a PHP, y ninguna herramienta reemplaza la instalación de las actualizaciones de seguridad. Loica está pensada para entender tus sistemas lo bastante bien como para modificarlos rápido sin que dejen de funcionar, y esa es justamente la capacidad que se pone a prueba en una semana como esta.
Lo primero es saber qué tienes, y para eso está la KDB, la memoria de tu empresa, que mapea el código, las reglas y las dependencias de tus sistemas. Con ella se responde algo que normalmente toma semanas, que es qué depende de qué y qué va a dejar de funcionar si tocamos una pieza determinada. La KDB se actualiza sola a medida que cambia el código y vive únicamente en tu propia infraestructura.
Después viene planificar el cambio, y ahí GenDEV toma una actualización o una corrección y la transforma en un plan técnico validado contra el código real, donde queda claro qué componentes hay que cambiar, cuáles pueden quedar como están y qué módulos se van a ver afectados.
Una vez hecho el cambio, hay que comprobar que no se haya roto nada más, y de eso se encarga GenQA, que prueba la aplicación tal como lo haría un usuario y guarda fotos y videos de cada prueba, así que si algo falla, el cambio no sale a producción.
En todos estos pasos hay una persona que toma la decisión, porque Loica propone y tu equipo aprueba, y cada cambio deja registrado quién lo pidió, por qué y quién lo autorizó.
Tres preguntas que conviene hacerse esta semana
- Si mañana anunciaran una falla crítica en cualquier tecnología que usas, piensa cuánto tardarías en hacer una lista de todos los sistemas que la ocupan y en qué versión están, y si ese tiempo se mide en horas, en semanas o en meses, porque ese número es tu exposición real.
- Después viene la pregunta de cuáles de tus sistemas corren en versiones que ya no tienen una solución oficial, y eso incluye a PHP pero también a los viejos entornos de ejecución de Java, a los marcos de trabajo sin soporte y a las bibliotecas que nadie ha tocado en años. En 2021 Log4j mostró el mismo patrón, ya que las organizaciones que respondieron mejor fueron las que ya sabían dónde lo estaban usando.
- Por último, vale la pena averiguar quién sabe qué depende de qué, porque si la respuesta es una o dos personas, ese conocimiento concentrado ya es un riesgo en sí mismo.
Para cerrar
Las vulnerabilidades de PHP se van a ir corrigiendo de a poco en millones de servidores, pero PHP fue solo el primero, porque la inteligencia artificial hizo que detectar fallas en código antiguo sea barato y va a seguir encontrándolas en cualquier tecnología que lleve funcionando el tiempo suficiente.
Las organizaciones que salgan bien paradas de esto probablemente no serán las que nunca tengan vulnerabilidades, sino las que conozcan tan bien sus propios sistemas que puedan responder en horas, y no en semanas, dónde están expuestas, qué tienen que cambiar y cómo demostrar que no se dañó nada más.
Si quieres ver cómo funcionaría esto en tu organización, ofrecemos una sesión de 45 minutos con nuestro equipo, trabajando sobre tu código real y sin presentación de diapositivas, y la primera conversación la planteamos como un diagnóstico más que como una demostración.
Fuente: PHP, aviso de seguridad oficial del 21 de octubre de 2026 (php.net).
