Cualquier titular resulta socorrido cuando se escribe sobre alertas de ciberseguridad. ¡Hay tantas! En los últimos días se ha hablado de octubre negro y, cómo no, de apocalipsis. Inspirados por el llamado Incidente PHP, denunciado globalmente el 21 de octubre. Sin llegar a tanto, ha revelado que lenguajes de programación con décadas de uso pueden – por la confianza que se les asigna – ser víctimas de atacantes que buscan impacto mundial y que, por alguna razón, se detienen al borde del abismo. Sobraron minutos para saber de su transversalidad: casi el 70% de las páginas web existentes llevan el estigma de una vulberabilidad que no se había detectado hasta que la IA permitió que algunos dieran el aviso
Como es natural, el episodio está siendo analizado del derecho y del revés. Y en toda su magnitud, dentro de lo humanamente posible (con preciosa ayuda artificial). Si no se hiciera así, el riesgo sería una solución de brocha gorda. Una más.
Básicamente, la vulnerabilidad PHP2Shell permite a cualquiera que sepa cómo explotarla acceder a un sistema online que ejecute PHP (una página web o un servidor conectado a internet), sin necesidad de contraseña para acceder o modificar sus datos. Tan sencillo como eso: algunos de los sitios web más exitosos del mundo funcionan con software que depende de PHP, como el popularísimo WordPress, así como Drupal, Joomla y MediaWiki, utilizado este último por la Wikipedia.
En realidad, PHP2Shell ya fue detectada por la PHP Foundation en 2024. Algunos expertos llegan a afirmar que ese año se tuvo constancia del problema sin que fuera necesario recurrir in extremis a la IA. Fueran cuales fuesen los plazos, la organización que vela por el mantenimiento de este software de código abierto consideró que las posibilidades de explotarlas eran descabelladas. Esta es una prueba eficaz de que la IA ha cambiado el cuadro.
Recuperar la cronología es importante para extraer todas las conclusiones. La empresa Calif, bajo el programa Patch the Planet de OpenAI, y Wiz Research, propiedad de Google, detectaron dos vulnerabilidades graves en la ejecución remota de código PHP, comunicándoselo a PHP Foundation el 11 y 24 de agosto, respectivamente. Wiz sostiene que estas vulnerabilidades se remontan a la versión PHP 5.4 y para dar con ellas utilizó su propio modelo Wiz Atlas, además de Gemini 4 Argon y GPT-5.6 Sol.
En este punto es importante destacar que no se trata de un error al uso, sino que la vulnerabilidad se debe a una combinación de varios bugs que habitualmente pasan inadvertidos. No fue hasta el 21 de septiembre – casi un mes después de la notificación formal – cuando PHP Foundation se puso manos a la obra a elaborar los parches. El mundo entero lo supo el 21 de octubre por una razón: fue ese día cuando se publicaron los parches que resolvían estas brechas de seguridad, llamando a actualizar el software a alguna de las versiones PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. En el caso de no poder hacerlo, se aconsejaba desconectar y aislar esas páginas web.
Un día antes de hacerlo público, se filtraron los detalles de ambas vulnerabilidades (CVE-2026-109618 y CVE-2026-109619). Alguien rompió el embargo y el secretismo con que se venía trabajando para no levantar la liebre y, con ello, disparar la posibilidad de ciberataques. En cualquier caso, antes de que se produjera la filtración, ya se detectaron casos en los que se explotaba la vulnerabilidad. En este sentido, es importante destacar que uno los factores que han cambiado por completo el escenario de la ciberseguridad es que el tiempo entre el descubrimiento de una vulnerabilidad y su explotación se ha reducido significativamente.
Matthew Prince, CEO de Cloudflare, confirmó la cantidad y rapidez de intentos de explotar la vulnerabilidad. Amazon, por su parte, fue diligente en revelar que había detectado PHP2Shell casi una semana antes de la divulgación de los parches, lo que significa que en algún lugar, alguien sabía cómo explotar los errores antes de que sus datos estuvieran disponibles por completo. Por esta razón, Amazon apuntó que es posible que la vulnerabilidad se hubiera explotado antes.
Aunque no resulta sencillo transformar en arma este cúmulo de bugs que conforman la vulnerabilidad, lo que es incontestable es que saber dónde está el error y cómo se soluciona da pistas a los delincuentes sobre dónde apuntar y cómo desarrollar sus exploits.
Si bien es cierto que no se ha detectado una explotación masiva a gran escala, tanto la empresa de seguridad Trail of Bits como investigadores de Perplexity descubrieron diversos exploits. El retraso de un mes desde que Wiz advirtió de la vulnerabilidad hasta que PHP Foundation comenzó a desarrollar los parches parece demasiado tiempo, pero es velocidad ultrasónica comparado con lo que habría llevado a la comunidad open source ocuparse de otro proyecto menos maduro.
Quienes mantienen este tipo de código abierto no acostumbran a disponer del tiempo ni de la financiación o acceso a modelos de frontera sin restricciones, que les harían falta para ir más rápido. Así pues, aunque la industria, los organismos públicos y los gobiernos se movieron con eficiencia. rápido, todavía no está claro el alcance verdadero de PHP2Shell.
A fin de cuentas, PHP no sólo está presente en servidores web; también se utiliza en herramientas para desarrolladores, paquetes de línea de comandos y terminales, y otros componentes de software empleados por routers, dispositivos de almacenamiento y de seguridad empresarial, como cortafuegos y VPNs. Dicho de otro modo, todavía puede haber desagradables sorpresas, sobre todo por el efecto dominó que podría desencadenar.
Cuanto más antigua sea la versión de PHP en una organización, más probable es que ésta no sea capaz de actualizarla. Ojalá fuera tan sencillo como instalar un parche, pero es más complejo: es preciso identificar en qué aplicaciones, plataformas y servicios de terceros está presente PHP y esperar a que esos proveedores lancen correcciones. No se puede obviar que hay muchas instalaciones antiguas de WordPress que no se han actualizado en años, siendo uno de los gestores de contenidos (CM) más afectados.
El exdirector de la Agencia de Ciberseguridad (CISA) de EEUU, Chris Krebs – al comienzo del primer mandato de Donald Trump – ya ha aconsejado, especialmente a las empresas más pequeñas, «escanear constantemente» en busca de vulnerabilidades, desplegar parches y no dudar en desconectar sistemas heredados. Según Krebs, el 3% de todas las vulnerabilidades críticas descubiertas se han encontrado en el último mes.
Por su parte, el subdirector de seguridad de la información (CISO) en Anthropic, Jason Clinton, teme que la cosa vaya a peor, por lo que llama a la movilización de los consejos de administración, instándoles a no subestimar la amenaza y pedir ayuda si fuera preciso. A pesar de ello, el ritmo de corrección ha sido bueno a la luz de los datos de Wiz Telemetry, que registró en pocos días una disminución aproximada del 67% en el número por día de máquinas expuestas a internet vulnerables a PHP2Shell.
En caso de las organizaciones con despliegues más antiguos. Algunos claramente oobsoletos, la proporción que ejecuta PHP versión 7.3 o anterior cayó del 8,3% al 5,7% en un periodo de cinco días. Pero una semana después de la divulgación pública, menos del 53% de las organizaciones inicialmente afectadas seguían siendo vulnerables a PHP2Shell. La conclusión que puede extraerse es que la IA permite ahora explotar cadenas de errores menores, sin corregir o inadvertidos. Hay numerosos modelos de IA, incluidos los de peso abierto, que pueden utilizarse para ello. Los precedentes del potencial de Mythos reconocido por Anthropic y el incidente de Hugging Face a cargo de OpenAI fueron señales de esta nueva normalidad en ciberseguridad.
Considerando la cantidad de software legacy de la que dependen muchas organizaciones, la superficie de ataque se expande drásticamente. En el caso de internet, el efecto en cadena puede ser devastador con la cantidad de códecs multimedia y de vídeo, bibliotecas de compresión, etc. obsoletos que todavía mantienen las páginas web.
De hecho, acaba de descubrirse una vulnerabilidad, bautizada como HTTP2Shell, en el algoritmo de compresión de Brotli que podría permitir un desbordamiento de búfer que llevaría a la divulgación de memoria, denegación de servicio y ataques de ejecución remota de código (RCE), similares a PHP2Shell. Brotli, que también es open source, fue desarrollado por Google para reducir el tamaño de los archivos sin perder información, permitiendo así tiempos de transmisión más rápidos consumiendo menos ancho de banda. Se utiliza para comprimir respuestas HTTP como HTML, CSS y JavaScript que están soportados por la mayoría de navegadores web, servidores y bibliotecas de software.
Aunque Google solucionó el error el 21 de octubre de 2026 lanzando las versiones 1.0.10, 1.1.1 y 1.2.1 de Brotli, hay otros programas que incluyen o utilizan versiones vulnerables del algoritmo, de modo que actualizar sólo la biblioteca de Google puede no proteger todas las aplicaciones. Este es el motivo por el que recientemente Microsoft lanzó una actualización de emergencia para solucionar el error en .NET. El problema de PHP y otros lenguajes y tecnologías envejecidos reside en su ‘memoria insegura’, es decir, que existen diversas vulnerabilidades a través de las cuales es posible forzar al software a filtrar datos sensibles del almacenamiento de memoria del software.
La Agencia de Seguridad Nacional (NSA) de EEUU estima que alrededor del 75% de todas las vulnerabilidades explotadas activamente aprovechan estos fallos relacionados con la memoria. Este es uno de los motivos por los que se ha ido virando progresivamente hacia otros lenguajes más seguros en memoria, como Python, Rust y Swift.
La prestigiosa Unit 42, rama de investigación de Palo Alto Networks asume que lo sucedido con PHP marca el inicio de una aceleración masiva de ciberamenazas. Por este motivo, recomienda adoptar una estrategia de defensa que combine parches tradicionales con parches virtuales en tiempo real.
Desde este punto de vista, las cifras hablan por sí solas: con 22 millones de instancias expuestas, pensar que bastaría con ciclos manuales de remediación sería pecar de ingenuidad. En su Defender’s Guide to the Frontier AI Impact on Cybersecurity h , Palo Alto Networks advierte de cómo los últimos modelos de IA de vanguardia tienen una capacidad extraordinaria para encontrar vulnerabilidades en el código. Esto propicia que nada más divulgar los parches, los atacantes aplican ingeniería inversa gracias a la IA, localizan la falla raíz y la atacan prácticamente en tiempo real. Ni siquiera da tiempo a instalar los parches.
Como remedio a esto, además de priorizar esa instalación en las rutas más críticas, Unit 42 habla de sus parches virtuales (Frontier Virtual Patching), entendidos como una capa de mitigación que da a los equipos ese tiempo necesario para desplegar los parches. Especialmente cuando se cuenta con software open-source, Unit 42 aconseja realizar una monitorización continua y proactiva para conocer la verdadera exposición en cualquier momento. Sin poner en manos de las defensas los mismos modelos de IA que utilizan los atacantes es complicado encontrar y corregir vulnerabilidades antes de que puedan ser usadas como arma.
Este panorama recuerda aquello de que “a río revuelto, ganancia de pescadores”. O, dicho sin metáfora, las aseguradoras no han tardado en ver una oportunidad de negocio incorporando otro riesgo adicional en sus primas. La rapidez con que los cibercriminales pueden aprovechar brechas de seguridad que permanecieron ocultas durante años y la creciente dependencia de plataformas de terceros concentra nel riesgo cibernético, hasta el punto de que fuentes del sector afirman que la proporción de organizaciones afectadas por un incidente de este tipo a través de terceros pasó del 19% al 39% entre 2020 y 2025.