Cientos de foros en riesgo: fallo en las plantillas de un motor popular permitiría a cualquiera tomar el control del servidor

Los exploits públicos a menudo convierten una vulnerabilidad ya corregida en una amenaza real para quienes pospusieron la actualización, y ahora ese riesgo ha surgido para los propietarios de foros que usan el motor vBulletin. El 27 de julio, los especialistas de SSD Secure Disclosure publicaron los detalles de la explotación de CVE-2026-61511 (9.8 en la escala CVSS 3.1), que permite ejecutar comandos en el servidor sin autenticación en versiones vulnerables del motor.

El problema afecta a vBulletin 6.2.1 y compilaciones anteriores de la rama 6.2, así como a versiones hasta la 6.1.6 inclusive. La empresa publicó parches a finales de junio, y el 1 de julio presentó la versión corregida 6.2.2. Las plataformas en la nube de vBulletin ya se han actualizado, por lo que el riesgo principal está vinculado, sobre todo, a los foros accesibles desde Internet que los propietarios alojan y mantienen por su cuenta.

La vulnerabilidad está en el mecanismo de procesamiento de expresiones matemáticas dentro de las plantillas. El motor elimina letras y algunos otros caracteres de los datos de entrada, y la cadena resultante se pasa a la función eval() de PHP, que la ejecuta como código. El filtro deja pasar dígitos, paréntesis y operadores, por lo que un atacante puede reconstruir nombres de funciones sin usar letras directamente.

No se necesita acceso al panel administrativo para lanzar el ataque. La ruta pública ajax/render/pagenav acepta un parámetro de número de página e lo inserta en el bloque matemático de la plantilla. Un valor especialmente diseñado llega a eval(), tras lo cual el servidor ejecuta un comando del sistema operativo y devuelve el resultado en la respuesta HTTP.

El prototipo publicado contiene un error tipográfico de un carácter y no se ejecuta sin corregirlo; sin embargo, el error se corrige con facilidad y no impide comprender el principio del ataque. Una verificación independiente confirmó la posibilidad de ejecutar una expresión de prueba segura tras corregir la errata, pero los autores de la verificación no llevaron a cabo un ataque completo contra un servidor en producción.

No se habían confirmado casos de explotación al momento de la publicación. La vulnerabilidad tampoco figuraba en el catálogo de problemas conocidos explotados por CISA. Aun así, se desconoce si los agresores emplearon este método durante las cuatro semanas entre la publicación de los parches y la publicación del código del ataque.

Se recomienda a los administradores de instalaciones autogestionadas actualizar a vBulletin 6.2.2 o aplicar el parche correspondiente a la rama que usan. Para buscar actividad sospechosa se pueden revisar las solicitudes POST a ajax/render/pagenav y prestar atención a valores inusualmente largos de pagenav[pagenumber] con gran cantidad de operadores aritméticos y binarios.