PHP en zona de riesgo: se han filtrado dos vulnerabilidades críticas
Los administradores de sitios web de todo el mundo se preparan para actualizar PHP urgentemente: sus desarrolladores han advertido de dos vulnerabilidades críticas que podrían permitir a los atacantes ejecutar código de forma remota en servidores vulnerables. PHP es uno de los lenguajes de programación más utilizados en sitios web y aplicaciones web, por lo que el alcance potencial del problema es enorme. Entre las posibles consecuencias están el secuestro de sitios web, el robo de datos y la redirección de visitantes a recursos maliciosos.
El equipo de PHP ha publicado un aviso preliminar sobre el próximo lanzamiento de las correcciones. Está previsto para el miércoles 21 de octubre de 2026 a las 14:00 UTC. Ambas vulnerabilidades han recibido una puntuación de 9,2 sobre 10 según CVSS 4.0, el sistema de evaluación de la gravedad de las vulnerabilidades. Los desarrolladores recomiendan a los administradores que se preparen para instalar la actualización en cuanto esté disponible. Si los detalles de las vulnerabilidades se hacen públicos o aparecen indicios de que se están explotando, las correcciones podrían publicarse antes. La información sobre las versiones afectadas y las compilaciones exactas corregidas se dará a conocer junto con el lanzamiento.
El inusual aviso preliminar apareció después de que la información sobre las vulnerabilidades se filtrara antes de que terminara el embargo, el periodo acordado durante el cual no deben publicarse esos datos. Anteriormente, un usuario con el seudónimo petecooper escribió en el foro Hacker News que PHP revelaría dos vulnerabilidades de ejecución remota de código el 22 de octubre de 2026. El mensaje se borró posteriormente, por lo que no fue posible verificar su contenido de forma independiente. Según BleepingComputer, la publicación afirmaba que las vulnerabilidades tenían la puntuación máxima de 10,0 en CVSS y afectaban a las versiones de PHP desde PHP 5 en adelante.
El mensaje también mencionaba los identificadores CVE-2026-109618 y CVE-2026-109619. Estos números se confirmaron posteriormente; la discrepancia estaba en la puntuación de gravedad: el aviso de PHP indica 9,2, no 10,0.
El embargo debía concluir el 20 de octubre y la corrección estaba prevista para el día siguiente. Sin embargo, Florian Roth, responsable de investigación de Nextron Systems, escribió en X que la información ya se había difundido: informó de una vulnerabilidad de ejecución remota de código en el núcleo de PHP, le asignó una puntuación de 10,0 e indicó que los detalles debían aparecer el 20 de octubre. Según él, las correcciones solo estarían disponibles para las versiones PHP 8. Después, PHP se vio obligado a publicar el aviso y enviar un mensaje a la lista de correo ANNOUNCE, informa BleepingComputer.
Los investigadores de watchTowr confirmaron la existencia de las vulnerabilidades e indicaron que en la comunidad las llaman «php2shell». Por ahora no se han divulgado detalles técnicos para no facilitar los ataques. Se supone que el problema podría afectar a PHP 5, 6, 7 y 8, aunque la lista definitiva de versiones se publicará junto con las correcciones.
El director ejecutivo de watchTowr, Benjamin Harris, declaró a BleepingComputer que las dos vulnerabilidades de ejecución remota de código se habían filtrado aproximadamente una hora antes de sus comentarios. En un principio, su divulgación estaba prevista para el jueves a las 11:00, hora del Este de Estados Unidos. Harris confirmó que las vulnerabilidades son reales y dijo que los investigadores habían conseguido reproducir la CVE-2026-109618, es decir, comprobar que funciona.
Por el momento, no hay informes confirmados de que estas vulnerabilidades se estén utilizando en ataques reales como zero-day —vulnerabilidades explotadas antes de que se publique una corrección—. A los administradores solo les queda estar pendientes del lanzamiento oficial e instalar los parches en cuanto estén disponibles.
PEREC.RU
La ciberseguridad tiene un género favorito: todo el mundo sabe que pronto cambiarán la puerta, pero alguien se adelanta a anunciar a voz en cuello dónde está rota. Y entonces los administradores no reciben un margen tranquilo para actualizar, sino una carrera entre la publicación del parche y quienes prefieren estudiar cerraduras ajenas sin que nadie les invite.
En esta historia se discute sobre plazos, puntuaciones y listas de versiones, como si la precisión de una cifra pudiera cerrar por sí sola una vulnerabilidad. Pero la clasificación del riesgo no es una cerradura ni una póliza: lo importante es cuándo estará lista la corrección y cuántos propietarios de sitios web la instalarán de verdad, en vez de dejarlo para «después del fin de semana», es decir, hasta el siguiente incidente.
Los embargos suelen servir para que los desarrolladores puedan preparar la defensa antes de que los detalles lleguen a manos de posibles atacantes. El sistema funciona mientras todos respeten las reglas; basta con que alguien decida que un espectáculo pirotécnico informativo vale más que la prudencia para que la coordinación se convierta en un apagafuegos colectivo. Los únicos que salen ganando son, quizá, quienes disfrutan accediendo antes a infraestructuras ajenas.
Resulta especialmente tranquilizadora la incertidumbre de siempre: ya se debate qué versiones podrían estar afectadas, pero la lista definitiva llegará más tarde. Para la redacción, es una buena ocasión para recordar que la escala de PHP lo convierte a la vez en una herramienta práctica y en un objetivo atractivo. Cuantos más sitios dependan de un mismo componente, más caro sale el hábito de considerar las actualizaciones una aburrida tarea de mantenimiento.
Todavía no se han confirmado ataques, y eso sí que es una buena noticia: una pausa poco habitual, no un motivo para bajar la guardia. Los propietarios de sitios web deberían seguir de cerca el lanzamiento oficial, comprobar qué versión tienen instalada y no dejar la actualización en la lista de tareas junto a «ordenar el correo» y «cambiar la contraseña algún día». En el mundo digital, «más tarde» a veces no es más que una forma educada de llamar al momento en que el código de otro ya se está ejecutando en tu servidor.
No hace falta buscar el motivo oculto de esta historia en el despacho de un villano con capucha: basta con la mezcla habitual de prisas, autopromoción y la convicción de que las normas del embargo se hicieron para alguien menos importante. Unos se llevan la atención gracias a una exclusiva prematura; otros, más trabajo y más riesgo. A los usuarios solo les queda esperar que el administrador de su sitio elija el parche y no otra reunión para explicar por qué todavía no lo ha instalado.
