Vulnerabilidad de PHP del 21 de octubre: qué ocurrió y cómo está la situación ahora

El miércoles 21 de octubre se dieron a conocer dos vulnerabilidades de seguridad graves en PHP, el lenguaje de programación sobre el que funciona la gran mayoría de los sitios web, incluido WordPress. Es posible que usted haya notado algo, ya que durante parte del día los sitios web alojados con nosotros estuvieron fuera de línea. En este artículo le explicamos qué ocurrió, cómo actuamos y cuál es la situación actual.

¿Qué sucedió?

Las vulnerabilidades (CVE-2026-109618 y CVE-2026-109619) permitían a personas no autorizadas ejecutar código en un servidor web. Se trata, prácticamente, del tipo de fallo más grave que existe: un atacante no necesita contraseña alguna y afecta a casi toda Internet.

Cómo actuamos

1. Medida provisionalmiércoles 21 de octubre, 10:00

   En ese momento solo se sabía que había dos vulnerabilidades graves en todas las versiones de PHP, con una puntuación CVE de 9,2. Todavía no se conocían los detalles y no había constancia de ataques exitosos, aunque, por ejemplo, Cloudflare observaba un número cada vez mayor de intentos. Como no se conocían los detalles de la vulnerabilidad, nadie sabía exactamente en qué consistía ni qué se podía hacer para reducir el riesgo. Sí fueron apareciendo cada vez más medidas de mitigación y posibles acciones para limitar el riesgo. Las fuimos aplicando de inmediato en cada caso, como la desactivación de determinadas funciones de PHP y la actualización del firewall en varias ocasiones.
   A partir de las 10:00 también pusimos en marcha de forma continua análisis de malware muy estrictos, de modo que pudiéramos detectar de inmediato si se colocaba algún script en nuestros servidores o en las cuentas de nuestros clientes. Esto no ocurrió.

2. Sitios web fuera de líneamiércoles 21 de octubre, 15:15

   Aunque no observamos intentos de explotación en nuestros servidores, decidimos optar por la opción más segura: poner todo fuera de línea. El motivo principal fue que teníamos dudas sobre la eficacia de las mitigaciones (soluciones provisionales) que circulaban por Internet, ya que nadie podía confirmar que ofrecieran una protección suficiente.
   En una situación con tanta incertidumbre y con consecuencias potencialmente enormes, unas horas de inactividad son justificables; asumir el riesgo, no.

3. Solución oficialmiércoles 21 de octubre, 16:00

   Los desarrolladores de PHP publicaron la actualización oficial con la corrección para las versiones 8.3, 8.4 y 8.5. A partir de ese momento, solo quedaba esperar los paquetes actualizados de CloudLinux, el proveedor de las versiones de PHP de nuestros servidores.
   Al publicarse la actualización también se conocieron los detalles de las vulnerabilidades, lo que confirmó nuestra sospecha: las mitigaciones conocidas y las reglas adicionales del firewall reducían el riesgo de un ataque, pero no eran suficientes para proteger el servidor.

4. Solución provisionalmiércoles 21 de octubre, 19:00

   Lamentablemente, CloudLinux tardó bastante más de lo que esperábamos en tener listas las actualizaciones. En nuestro contacto con otros proveedores comprobamos que no éramos los únicos sorprendidos. Al ver que ya habían incumplido varios plazos que ellos mismos se habían fijado, trabajamos en una solución provisional.
   Instalamos nosotros mismos la versión 8.3.36 de PHP en todos nuestros servidores y pasamos temporalmente a todos nuestros clientes a esta versión. El 90 % de los sitios web volvió a estar en línea entre las 19:00 y las 20:30. Los únicos sitios que no se recuperaron eran sitios desactualizados que no podían funcionar con una versión moderna de PHP.

5. Actualizaciónjueves 22 de octubre, 00:30

   Las actualizaciones se publicaron y comenzamos de inmediato a instalarlas y verificarlas, servidor por servidor.

6. Resueltojueves 22 de octubre, 02:30

   Todos los servidores estaban actualizados y todos los sitios web volvieron a estar en línea, con la misma versión de PHP que utilizaban anteriormente.

Entendemos perfectamente que resulte molesto que su sitio web no esté disponible durante una tarde y una noche. Sin embargo, esta molestia no compensa las posibles consecuencias. Nunca antes habíamos tenido que decidir poner todo fuera de línea por precaución, pero si se diera de nuevo la misma situación, actuaríamos exactamente igual.

¿Cuál es la situación actual?

• Todas las versiones de PHP que ofrecemos, desde la 5.2 hasta la 8.5, incluyen las correcciones de seguridad para ambas vulnerabilidades.
• Los pocos sitios web que funcionaban con una versión de PHP todavía más antigua, para la que no existe corrección, los hemos migrado a una versión corregida.
• Hemos revisado los servidores durante y después de conocerse la vulnerabilidad en busca de indicios de explotación, como procesos de PHP bloqueados, procesos sospechosos, archivos subidos y solicitudes compatibles con el ataque conocido. No hemos encontrado ningún indicio de que la vulnerabilidad se haya explotado en nuestros servidores, y tampoco se detectaron intentos de hacerlo antes de que pusiéramos los sitios fuera de línea.

¿Mi sitio web está separado del de otros clientes?

Sí. Cada paquete de hosting funciona con nosotros en un entorno propio y aislado. PHP se ejecuta bajo el usuario de su paquete, sin permisos de administrador en el servidor, y no puede acceder a los archivos ni a las bases de datos de otros clientes. El uso de procesador y memoria también está limitado por paquete. No compartimos públicamente más detalles sobre nuestra seguridad de forma deliberada: cuanto menos sepa un atacante, mejor.