Una web puede funcionar perfectamente y, aun así, estar expuesta a una vulnerabilidad crítica.

Las páginas cargan con normalidad, los formularios responden, los usuarios pueden acceder a sus cuentas y los servicios siguen funcionando sin incidencias aparentes. No hay errores visibles ni señales que indiquen que algo necesita nuestra atención inmediata.

Hasta que aparece un aviso de seguridad que cambia por completo la situación.

El 21 de octubre de 2026, el equipo de desarrollo de PHP publicó actualizaciones urgentes para corregir dos vulnerabilidades críticas, identificadas como CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación de 9,2 sobre 10 según CVSS v4.0.

Los fallos estaban relacionados con la gestión interna de memoria y del estado de las peticiones. En determinadas condiciones, podían permitir que un atacante ejecutara código de forma remota sin necesidad de autenticarse. La recomendación oficial fue actualizar inmediatamente las instalaciones afectadas que procesaran peticiones web, ya que las medidas temporales de mitigación no ofrecían una protección completa.

La gravedad del incidente no tardó en trascender el ámbito estrictamente técnico. La Agencia de Seguridad Nacional de Estados Unidos (NSA) recomendó a las organizaciones que utilizaban PHP preparar las actualizaciones y contemplar la desconexión temporal de los sistemas cuando no fuera posible corregirlos inmediatamente.

La respuesta también llegó desde las propias plataformas. Drupal.org y otros servicios relacionados fueron retirados temporalmente de la red mientras sus responsables aplicaban las correcciones. La Drupal Association aclaró que el problema no estaba en Drupal, sino en PHP, y que sus mecanismos habituales de protección no resolvían esta vulnerabilidad.

Lo especialmente preocupante no era únicamente la gravedad de las vulnerabilidades, sino el lugar donde se encontraban.

No hablamos necesariamente de un error en un plugin de WordPress ni de una funcionalidad desarrollada sin las precauciones necesarias. Los fallos se encontraban en el intérprete de PHP, una tecnología de la que dependen numerosas aplicaciones web.

Eso significa que una organización podía haber mantenido correctamente su aplicación, aplicado sus actualizaciones y seguido las recomendaciones habituales de seguridad y, sin embargo, continuar expuesta por una vulnerabilidad en uno de los componentes que necesitaba para funcionar.

Durante años hemos asociado buena parte de la seguridad web a mantener actualizado nuestro software, corregir errores de programación y configurar adecuadamente las herramientas que utilizamos. Son prácticas fundamentales, pero incidentes como este nos recuerdan que la seguridad de una aplicación también depende de elementos que no siempre vemos y sobre los que no tenemos un control directo.

Que una web funcione correctamente no significa que todo lo que necesita para funcionar sea seguro.

Las vulnerabilidades publicadas el 21 de octubre nos invitan a examinar no solo cómo se corrige un fallo crítico, sino qué significa mantener la infraestructura sobre la que funciona una aplicación.

El código que no escribimos también puede comprometernos

Cuando desarrollamos una aplicación web, solemos concentrar buena parte de nuestros esfuerzos de seguridad en el código que escribimos: validar los datos que recibimos, controlar los permisos de acceso, proteger las sesiones o evitar que una entrada maliciosa termine ejecutándose como una instrucción.

Sin embargo, antes de que nuestra aplicación pueda realizar cualquiera de estas operaciones, intervienen otras tecnologías que se encargan de recibir, interpretar y procesar las peticiones.

En una aplicación desarrollada con PHP, parte de ese trabajo corresponde al propio intérprete. Es el componente encargado de ejecutar nuestro código, pero también realiza operaciones internas relacionadas con la gestión de memoria, las sesiones y el procesamiento de las solicitudes HTTP.

Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 afectan precisamente a este nivel.

La primera está relacionada con el tratamiento de errores cuando se agota la memoria disponible. La segunda, con la reutilización incorrecta de determinados estados internos entre peticiones. En ambos casos, los fallos pueden permitir que un atacante altere el comportamiento del intérprete y llegue a ejecutar código no autorizado.

Lo especialmente relevante es que, según el análisis técnico publicado por Datadog Security Labs, la explotación puede producirse antes de que PHP llegue a ejecutar el código de la aplicación.

Podemos haber desarrollado correctamente nuestros mecanismos de autenticación, aplicado controles sobre los formularios y revisado las funcionalidades expuestas al exterior. Pero si una petición maliciosa aprovecha un fallo en el procesamiento interno de PHP, esas protecciones pueden no llegar siquiera a intervenir.

No significa que todas las instalaciones sean igualmente vulnerables ni que cualquier petición permita comprometer un servidor. La exposición efectiva depende de las versiones, configuraciones y condiciones de ejecución.

La cuestión es que la seguridad de nuestro código y la seguridad del entorno que lo ejecuta son responsabilidades diferentes, aunque inseparables.

Podemos controlar cómo desarrollamos una aplicación, pero no siempre podemos corregir directamente los defectos de las herramientas sobre las que funciona. En esos casos dependemos de las correcciones publicadas por sus responsables y de nuestra capacidad para incorporarlas correctamente.

Y ahí aparece un nuevo desafío: una vez que el proveedor publica una solución, todavía tenemos que conseguir que esa corrección llegue de forma segura a nuestros sistemas.

Actualizar no es lo mismo que estar protegido

Cuando se publica una corrección para una vulnerabilidad crítica, la recomendación suele ser inmediata: actualizar cuanto antes. Pero entre la disponibilidad de un parche y la certeza de que un sistema está protegido existe un proceso que no siempre resulta tan sencillo como parece.

Uno de los aspectos que puede generar confusión es la numeración de las versiones.

Distribuciones como Ubuntu mantienen determinadas versiones de PHP durante años y aplican sobre ellas correcciones de seguridad mediante un procedimiento conocido como backporting. Esto permite incorporar parches de versiones posteriores sin necesidad de cambiar toda la rama del intérprete, algo especialmente importante en servidores de producción donde las aplicaciones dependen de versiones concretas.

Así, por ejemplo, el PHP 8.1 distribuido por Ubuntu 22.04 puede recibir correcciones específicas de seguridad aunque esa rama ya no reciba actualizaciones del proyecto PHP. No debemos confundir el soporte del fabricante de la distribución con el del proyecto original.

Una versión aparentemente antigua no significa necesariamente que sea vulnerable, del mismo modo que una versión más reciente no garantiza por sí sola que incluya una corrección concreta.

En el caso de las vulnerabilidades del 21 de octubre, Ubuntu publicó paquetes corregidos para sus distribuciones compatibles. La comprobación adecuada no consistía únicamente en consultar la versión de PHP, sino también en verificar el origen de los paquetes y que las correcciones correspondientes a los CVE estuvieran efectivamente incorporadas.

Pero la verificación no termina al instalar los paquetes. También es necesario comprobar qué versión utiliza realmente el servicio web, si los procesos se han reiniciado cuando corresponde y si las aplicaciones continúan funcionando correctamente.

Una actualización puede haberse completado sin errores y, aun así, dejar procesos ejecutando código anterior o provocar incompatibilidades que no se detectan hasta que alguien utiliza una funcionalidad concreta.

Por eso conviene distinguir entre tres situaciones: tener una corrección disponible, haberla instalado y haber comprobado que está aplicada en el entorno que realmente presta servicio.

La seguridad no debería basarse únicamente en la confianza de haber actualizado, sino en la capacidad de demostrar qué se ha corregido y qué sigue funcionando.

Y esa comprobación necesita algo que no siempre podemos improvisar durante una emergencia: tiempo para intervenir, verificar los resultados y reaccionar si aparecen problemas.

La seguridad también es una cuestión de tiempo

Uno de los aspectos más relevantes de este incidente es el papel de la inteligencia artificial en la investigación. Según OpenAI, Calif identificó uno de los fallos con ayuda de GPT-5.6 Sol; Wiz, de forma independiente, descubrió y comunicó ambos problemas, utilizando también modelos de IA en su investigación, según Google Cloud. Estas herramientas contribuyeron al análisis técnico y a la comprobación de las correcciones.

No significa que la inteligencia artificial haya sustituido a los investigadores de seguridad. El descubrimiento, la evaluación de los riesgos y la coordinación con los responsables de PHP siguieron requiriendo intervención humana. Pero sí demuestra cómo estas herramientas pueden ampliar la capacidad de analizar grandes cantidades de código e identificar problemas difíciles de detectar mediante los procedimientos tradicionales.

Si cada vez podemos descubrir vulnerabilidades con mayor rapidez, ¿estamos preparados para corregirlas al mismo ritmo?

Identificar un fallo no significa que todos los sistemas afectados puedan actualizarse inmediatamente. Las correcciones deben desarrollarse, distribuirse y aplicarse en infraestructuras con características muy diferentes. Algunas organizaciones disponen de equipos especializados y procesos de despliegue automatizados. Otras dependen de intervenciones manuales, proveedores externos o aplicaciones antiguas que requieren comprobaciones adicionales.

La inteligencia artificial puede ayudar a reducir el tiempo necesario para descubrir una vulnerabilidad, pero no elimina automáticamente el trabajo necesario para corregirla en producción. Y esa aceleración también puede beneficiar a quienes buscan explotar los fallos antes de que las organizaciones hayan aplicado las actualizaciones.

Por eso, el verdadero desafío no consiste únicamente en detectar más problemas y hacerlo antes. También necesitamos reducir el tiempo que transcurre entre conocer una vulnerabilidad y conseguir que los sistemas afectados vuelvan a operar con las correcciones necesarias.

La velocidad del descubrimiento está cambiando. Nuestra capacidad de respuesta también tendrá que hacerlo.

El día de la emergencia no es el momento de descubrir qué tenemos

Cuando se anuncia una vulnerabilidad crítica, una de las primeras preguntas debería ser relativamente sencilla: ¿qué sistemas tenemos afectados?

Sin embargo, responderla no siempre resulta fácil.

En muchas organizaciones, la infraestructura tecnológica ha evolucionado durante años. Se han migrado aplicaciones, contratado nuevos proveedores, incorporado servicios y mantenido servidores antiguos porque todavía alojan alguna funcionalidad necesaria. Parte de esa información está documentada, pero otra depende del conocimiento de quienes participaron en cada proyecto.

Mientras todo funciona, esta situación puede pasar inadvertida. El problema aparece cuando necesitamos intervenir con urgencia.

Identificar qué servidores utilizan una versión concreta de PHP, qué aplicaciones dependen de ella o qué repositorios suministran las actualizaciones puede convertirse entonces en una investigación que consume un tiempo especialmente valioso.

También necesitamos saber si existen copias de seguridad recuperables, si podemos probar los cambios antes de aplicarlos en producción y qué procedimiento seguiremos si una actualización provoca una incompatibilidad. Incluso aspectos aparentemente secundarios, como el espacio disponible en disco, pueden condicionar una intervención urgente.

La diferencia no está únicamente en disponer de herramientas de monitorización o en contar con un equipo especializado. También reside en decisiones mucho más básicas: mantener actualizado el inventario tecnológico, documentar las configuraciones relevantes, definir responsabilidades y comprobar periódicamente que los mecanismos de recuperación funcionan.

Estas tareas rara vez tienen la visibilidad de un nuevo desarrollo o de una funcionalidad que mejora la experiencia de usuario. Su valor suele hacerse evidente precisamente cuando algo falla.

Durante este incidente, algunas organizaciones también optaron por desconectar temporalmente determinados servicios mientras aplicaban las correcciones de seguridad. Es el caso de ICANN y de la Oficina Europea de Patentes. Estas decisiones muestran que responder a una vulnerabilidad no siempre consiste en mantenerlo todo funcionando: en determinadas circunstancias, interrumpir temporalmente un servicio puede ser la opción más prudente para reducir la exposición mientras se aplica una solución.

Por eso, una organización preparada no es aquella que puede garantizar que nunca tendrá problemas de seguridad. Es aquella que, cuando aparece una amenaza, no necesita empezar por averiguar cómo funciona su propia infraestructura.

La capacidad de responder ante una vulnerabilidad no se construye durante la emergencia. Es el resultado del mantenimiento y de las decisiones que hemos tomado mucho antes de que aparezca.

Conclusión

Las vulnerabilidades de PHP nos recuerdan que ningún sistema puede garantizar la ausencia absoluta de fallos. Las buenas prácticas de desarrollo y el mantenimiento reducen los riesgos, pero no eliminan la posibilidad de que aparezcan vulnerabilidades desconocidas en tecnologías consolidadas.

Por eso, quizá deberíamos dejar de entender la seguridad como un estado que alcanzamos después de instalar determinadas herramientas o completar una serie de comprobaciones.

La seguridad no es algo que conseguimos una vez y podemos dar por terminado. Es una responsabilidad que debemos mantener en el tiempo.

Esto implica asumir que, tarde o temprano, alguna de las tecnologías que utilizamos necesitará una corrección urgente. Y que nuestra capacidad para identificar el problema, evaluar su alcance, intervenir y comprobar los resultados será tan importante como las medidas preventivas que hayamos adoptado.

Una infraestructura fiable no es aquella que nunca necesita una intervención, sino aquella que puede afrontar los cambios y las incidencias sin perder el control sobre su funcionamiento.

Al final, no podemos garantizar que ninguna tecnología falle, pero sí podemos decidir hasta qué punto estamos preparados para responder cuando suceda.

Y esa es la pregunta que conviene hacerse incluso cuando nuestros sistemas no se han visto afectados:

¿Conocemos suficientemente bien nuestra infraestructura como para responder cuando una tecnología de la que dependemos deja de ser segura?

¿Sabes en qué estado se encuentra tu infraestructura web?

Una vulnerabilidad crítica no debería ser el momento en el que descubres cómo están configurados tus servidores o quién se encarga realmente de mantenerlos.

En ITDO podemos ayudarte a revisar tu infraestructura, identificar posibles riesgos y definir una estrategia de mantenimiento y actualización adaptada a las necesidades de tu proyecto.

Hablemos de tu proyecto

Fuentes:

Compartir es construir