El equipo de seguridad de PHP publicó hoy, 21 de octubre, una corrección para dos vulnerabilidades, ambas con una puntuación de 9,2 sobre 10. Estaba prevista para las 10:00 (hora del este de EE. UU.) y salió antes.
Los investigadores de seguridad llaman a la pareja PHP2Shell. Sus nombres oficiales son CVE-2026-109618 y CVE-2026-109619.
Si su sitio web funciona con WordPress o Drupal, funciona con PHP.
Actualización, 9:36 (hora del este de EE. UU.): ya está la corrección
PHP publicó la corrección antes de lo previsto. La vimos en php.net a las 9:36 (hora del este de EE. UU.).
Actualice a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35. PHP 8.1 y anteriores no reciben actualización del proyecto PHP. Algunas distribuciones de Linux y proveedores de soporte adaptan la corrección, así que consulte con el suyo, o pase a una versión con soporte.
Con la versión, PHP publicó en qué consiste realmente el problema. En pocas palabras:
- Los dos fallos están en cómo PHP prepara y limpia cada petición web. Uno ocurre cuando PHP se queda sin memoria a mitad de preparar una petición: la limpieza puede tratar entonces datos a medio construir como si fueran reales. El otro deja datos de una petición después de liberar su memoria, y la siguiente petición en el mismo proceso puede usarlos.
- Cualquiera de los dos puede permitir que un desconocido ejecute su propio código en su servidor, sin iniciar sesión, enviando peticiones preparadas a propósito.
- Afecta a PHP cuando sirve páginas web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP dice que el riesgo es mayor con mod_php de Apache, donde tiene un ataque que funciona.
- Ocurre antes de que se ejecute el código de su sitio. Eso significa que un plugin de seguridad dentro de WordPress o Drupal no lo ve. Lo que le protege es la actualización y los límites aplicados delante de PHP.
PHP también enumera ajustes que reducen la exposición si no puede actualizar enseguida, y deja claro que no hacen seguro un servidor. Están en el aviso de php.net.
Por qué LFW.com nunca estuvo expuesto: estos fallos viven en el código que se ejecuta cuando PHP atiende una petición. Las páginas de LFW.com son archivos generados de antemano y en nuestros servidores ningún PHP lee ninguna petición, así que no hay nada que activar. Las copias de solo lectura que publicaron esta mañana los gobiernos europeos están a salvo por la misma razón.
Si desconectó un sitio, puede volver en cuanto su proveedor de hosting confirme que usa una de las versiones corregidas.
Lo que revisamos en nuestros propios servidores
Empezamos esta mañana por nuestra propia infraestructura.
- LFW.com: no está afectado. Está hecho con Astro y se sirve con Node.js, y en nuestros servidores no hay PHP instalado.
- Una demo de WordPress: encontramos una demo de WordPress en un contenedor que habíamos detenido hace unas tres semanas y nunca retiramos. No estaba en marcha y estaba protegida con contraseña. La retiramos de todos modos, con su base de datos y sus imágenes.
- Nuestros equipos de desarrollo: las copias locales de WordPress que usamos para desarrollar están detenidas y ninguna es accesible desde internet.
La demo es lo que vale la pena contar. Hoy no tenía ningún problema. Era simplemente un sitio con PHP que ya no necesitábamos, y seguía ahí.
El sitio que nadie recuerda
En un día así, el sitio web principal suele actualizarse. Alguien es su responsable y alguien lo vigila.
El riesgo suele estar en un sitio que nadie recuerda tener:
- el micrositio de una campaña que ya terminó
- la copia de pruebas que un proveedor montó para un rediseño
- el sitio de un evento de hace unos años
- una demo o instalación de prueba que nunca se retiró
Esos sitios siguen funcionando con PHP, y nadie está pendiente de la actualización.
Lo que haríamos hoy
En este orden:
- Revise primero a su proveedor de hosting. Si tiene hosting gestionado, consulte su página de estado o su blog. En un día así la mayoría publica su plan, y muchos actualizan PHP por usted, así que quizá no necesite contactarlos.
- Haga una lista de cada sitio con PHP. Incluya los olvidados. Retire los que no usa.
- Actualice el resto el mismo día en que salga la corrección. Pida a quien gestiona cada sitio que le avise cuando esté hecho.
- Mantenga un firewall delante hasta entonces. Un firewall de aplicaciones web solo ayuda si el servidor rechaza el tráfico que no pasa por él, así que revise también ese ajuste.
Apagar el servidor
El Centro Nacional de Ciberseguridad del Reino Unido dice que, si no puede actualizar ni aplicar las soluciones temporales de PHP, considere desconectar el sistema hasta que pueda hacerlo. Dada la gravedad que se ha informado, no es un mal consejo, aunque parezca excesivo.
Apagar el servidor no tiene por qué apagar el sitio. Mientras tanto puede publicar una copia de solo lectura: páginas estáticas, sin PHP detrás.
- Los residentes pueden seguir leyendo las páginas y encontrando los números de teléfono.
- Los formularios, los inicios de sesión y las búsquedas esperan a que esté la actualización.
- La copia se retira cuando vuelve el sitio actualizado.
Para un sitio web público del que la gente depende, es un término medio mejor que una página en blanco.
Varios gobiernos desconectaron sitios esta mañana
Varios gobiernos decidieron que unas horas sin conexión valían la pena.
Esto es lo que vimos a las 8:50 (hora del este de EE. UU.):
- El Centro Nacional de Ciberseguridad de los Países Bajos desconectó su propio sitio, NCSC.nl, como precaución.
- DigiD y MijnOverheid, el acceso del gobierno neerlandés y su portal para la ciudadanía, mostraban páginas de "no disponible temporalmente".
- La Universidad de Viena apagó sus sitios web, formularios en línea, correo web y Moodle.
- El sitio de la Cámara de Representantes neerlandesa no nos cargó en absoluto. NL Times informó que también se desconectó.
- El centro de TI del gobierno de Finlandia, Valtori, cortó como precaución el tráfico entrante de internet hacia los servicios públicos del Estado, y lo explicó en su sitio. Añadió que el corte no se debió a un ataque.
No hay nada de qué avergonzarse. Son unas horas, y el problema es lo bastante grave como para que la agencia cuyo trabajo es la ciberseguridad lo eligiera para su propio sitio.
Lo que pidieron las agencias de ciberseguridad
No fue solo Europa. Agencias nacionales de ciberseguridad de tres continentes publicaron alertas el mismo día, y en lo esencial coinciden:
- Reino Unido: el Centro Nacional de Ciberseguridad pide encontrar todos los sistemas con PHP, actualizar y considerar desconectar un sistema si no se puede.
- Unión Europea: CERT-EU, que protege a las propias instituciones de la UE, recomendó aislar las aplicaciones expuestas a internet donde no se pueda actualizar de inmediato.
- Singapur: la Agencia de Ciberseguridad pide actualizar de inmediato y buscar PHP en todos los servidores web, incluso donde el sitio principal no lo usa.
- Australia: el Centro Australiano de Ciberseguridad instó a las organizaciones a localizar PHP en su entorno, prepararse para actualizar y vigilar señales de ataque.
El punto de Singapur es el que subrayaríamos. Un sitio hecho con otra tecnología puede tener PHP en el mismo servidor: una herramienta de administración antigua, una instalación olvidada, un complemento de un proveedor.
Lo que sus páginas de desconexión hicieron bien
Mire con atención esas páginas. No están en blanco y no son mensajes de error.
- Dicen por qué. Cada una nombra las vulnerabilidades de PHP como motivo.
- Dicen qué está caído. Viena enumera cada servicio, para que nadie tenga que adivinar.
- Dicen adónde ir. El NCSC remite a su sitio de avisos, a LinkedIn y a un correo disponible 24/7 para ayuda urgente.
- Son páginas estáticas. No necesitan PHP para mostrarse, y por eso siguen en pie.
Ese último punto es toda la idea de la copia de solo lectura. Estas páginas son su versión más pequeña.
Escriba esa página antes de necesitarla
Nada de esto es difícil en un día tranquilo. Es difícil a las 6 de la mañana del día de una versión de seguridad.
Así que vale la pena decidir algunas cosas ahora, mientras no pasa nada:
- Quién puede desconectar el sitio, y a quién avisa. Un nombre y un suplente.
- La propia página de desconexión, redactada y guardada en un lugar que no use PHP: el motivo, lo que está caído, dónde seguir las novedades y cómo hablar con una persona.
- Qué páginas nunca pueden apagarse. Avisos de emergencia, avisos de hervir el agua, los números de teléfono. Esas van en la copia de solo lectura.
- Cómo sabrá que es seguro volver. Normalmente: su proveedor de hosting confirma la versión corregida y usted revisa una página por su cuenta.
Unas horas sin conexión, planificadas, son un buen día. Sin planificar, son una noticia.
Si quiere ayuda
Con gusto le ayudamos con cualquiera de estos pasos, ya sea encontrar los sitios olvidados o publicar una copia de solo lectura. Escríbanos.
Leland Fiegel