Bricksforge CVE-2026-85097 se está explotando: actualiza Pro Forms ya

#Mi sitio con Bricksforge es vulnerable a CVE-2026-85097

Lo es si tienes instalada la 3.1.8.9 o una inferior. Ese es el rango del registro en NVD y de la base de datos de Wordfence. El atacante no necesita iniciar sesión ni que nadie de tu lado haga clic en nada.

Tener un campo de subida en el formulario no es requisito. En el registro de cambios del fabricante, la entrada de la 4.0.1 dice de forma explícita que el problema afecta a todos los sitios con Pro Forms activo, incluidos aquellos cuyos formularios no tienen campos de subida. “Solo tenemos un formulario de contacto” no sirve como motivo para esperar.

La gravedad depende de la fuente. Patchstack le da 10.0 y la marca como explotada (KEV). Wordfence y NVD dan 9.8 con CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Para quien gestiona el sitio la diferencia no cambia nada: ataque por red, sin privilegios, impacto total.

Bricksforge es un plugin comercial. La API de plugins de WordPress.org responde “Plugin not found”. Eso importa en dos pasos de más abajo: las actualizaciones llegan por la licencia del fabricante, no por el directorio, y wp plugin verify-checksums no tiene con qué comparar.

#Cómo funciona el fallo de subida en Bricksforge Pro Forms

La descripción de la CVE y el análisis de Patchstack describen tres pasos:

1. El atacante obtiene un nonce válido desde la acción AJAX bricksforge_regenerate_nonce, que responde sin autenticación.
2. Sube un archivo que es a la vez un GIF válido y PHP válido, un políglota. La comprobación de tipo MIME en la primera subida lo deja pasar, porque el archivo parece de verdad una imagen. Acaba en una carpeta temporal.
3. Envía un formulario con el parámetro temporaryFileUploads manipulado. La ruta en el servidor apunta al GIF validado, pero el campo url termina en .php. El plugin se fía de los metadatos que manda el cliente y escribe el contenido en una ruta PHP.

Patchstack señala dos puntos de entrada: POST /wp-json/bricksforge/v1/form_submit y /wp-admin/admin-ajax.php con la acción bricksforge_form_submit. El código afectado está en includes/elements/pro-forms/actions/init.php y base.php. Según el registro de la CVE, el fabricante recibió el aviso el 3 de septiembre de 2026 y la divulgación llegó el 7 de octubre. El investigador acreditado es d.v4n_s3c.

#Cómo comprobar la versión de Bricksforge en wp-admin y con WP-CLI

En el escritorio: Plugins, Plugins instalados, fila de Bricksforge, número de versión bajo la descripción. Si la licencia ha caducado, puede que el escritorio no muestre una actualización que sí existe. Que no haya aviso no demuestra que estés al día.

Por SSH, para un sitio:

wp plugin list --name=bricksforge --fields=name,status,version,update_version

Si llevas varios sitios de clientes en el mismo servidor, un bucle te da el inventario en segundos:

for d in /var/www/vhosts/*/httpdocs; do
  printf '%s ' "$d"
  wp --path="$d" plugin get bricksforge --field=version 2>/dev/null || echo "no instalado"
done

La ruta /var/www/vhosts/*/httpdocs es la estructura por defecto de Plesk. Con cPanel suele ser /home/*/public_html. Todo lo que esté en la 3.1.8.9 o por debajo va a la lista de actualizar y revisar.

#Actualizar Bricksforge a la 3.1.8.10 o a la 4.0.1

Las fuentes no coinciden, y conviene saberlo antes de pulsar Actualizar.

• Patchstack y Wordfence indican las dos la 3.1.8.10 como versión corregida.
• El registro de cambios del fabricante, a 10 de octubre de 2026, no tiene entrada para la 3.1.8.10. Recoge la 3.1.8.9 (28 de agosto), la 4.0.0 (17 de septiembre) y la 4.0.1 (8 de octubre), esta última con el título “Security fix for the Pro Forms file upload”.

La regla práctica: tras actualizar, la versión tiene que ser la 3.1.8.10, o la 4.0.1 o superior. Si estás en la 4.0.0, pasa a la 4.0.1. Ninguna de las fuentes dice de forma expresa si la 4.0.0 es vulnerable, pero el fabricante publicó la corrección de la subida en la 4.0.1, así que no hay motivo para quedarse.

wp plugin update bricksforge
wp plugin get bricksforge --field=version

Si WP-CLI no ve la actualización, descarga el zip desde tu cuenta de cliente del fabricante e instálalo desde el archivo: wp plugin install /tmp/bricksforge.zip --force. El salto a la 4.x es una versión mayor. En un sitio con formularios complejos, pruébalo antes en staging, pero hoy y no la semana que viene.

¿No puedes actualizar todavía? Desactiva el plugin (wp plugin deactivate bricksforge) o bloquea los dos endpoints en el WAF. Patchstack ha desplegado una regla RapidMitigate para esta CVE para sus clientes. La propia Patchstack la presenta como medida provisional, no como sustituto de la actualización.

#Qué revisar si el sitio funcionó con Bricksforge 3.1.8.9 o anterior

La actualización cierra la puerta. No echa a quien ya ha entrado. El 7 de octubre es la primera observación en la telemetría de Patchstack, no la prueba de que nadie lo intentara antes. Revisa por eso una ventana más amplia, por ejemplo desde el 3 de septiembre, cuando se avisó al fabricante.

#Cuentas de administrador nuevas

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Compara con las personas que conoces. Una cuenta creada en las últimas semanas, con una dirección en un dominio extraño o un usuario tipo wp-support, basta para abrir una investigación completa. Revisa también las contraseñas de aplicación: wp user application-password list <ID> para cada administrador.

#Archivos PHP en la carpeta de uploads

En wp-content/uploads no debe haber PHP ejecutable. Patchstack encontró archivos llamados login_admin_*.php en /wp-content/uploads/bricksforge/tmp/ y /wp-content/uploads/2026/10/.

find wp-content/uploads -type f \( -iname '*.php*' -o -iname '*.phtml' -o -iname '*.phar' \) -ls
find wp-content/uploads -type f -name 'login_admin_*' -ls
ls -la wp-content/uploads/bricksforge/tmp/

El patrón *.php* con -iname también encuentra .php5 y .PHP. Patchstack describe variantes de extensión, de mayúsculas y minúsculas y de codificación en las cargas, así que no busques solo .php exacto. Busca también archivos .htaccess extraños dentro de uploads, porque pueden hacer que otras extensiones se ejecuten como PHP.

#Archivos modificados en el núcleo, temas y plugins

wp core verify-checksums
find wp-content -type f -name '*.php' -newermt '2026-09-03' ! -path '*/cache/*' -ls

El núcleo se comprueba con sumas de verificación. Bricksforge y Bricks no están en WordPress.org, así que descarga copias limpias del fabricante y compáralas con diff -r. Mira con especial cuidado wp-content/mu-plugins, donde el código siempre se carga y nunca aparece en la lista de plugins, y el wp-config.php.

#Tareas programadas

wp cron event list --fields=hook,next_run_relative,recurrence
crontab -l

Hooks desconocidos en WP-Cron, o una línea del crontab que descarga algo de una dirección externa, son la vía clásica para volver a entrar después de borrar la webshell.

#Logs del servidor

Busca los endpoints del informe de Patchstack. En Plesk los logs están en /var/www/vhosts/<dominio>/logs/:

grep -E 'bricksforge/v1/form_submit|bricksforge_regenerate_nonce|bricksforge_form_submit' access_ssl_log*
zgrep -E 'bricksforge/v1/form_submit' access_ssl_log*.gz
grep -E '^(177\.75\.57\.20|23\.97\.62\.146|84\.247\.60\.125|38\.154\.185\.97|150\.109\.16\.166|153\.75\.90\.146) ' access_ssl_log*
grep -E 'GET /wp-content/uploads/.*\.php' access_ssl_log*

Estas seis direcciones son las más activas de las 63 IP únicas que Patchstack contó en la campaña. Una limitación: un log de acceso normal guarda solo la URL, y el nombre de la acción AJAX suele ir en el cuerpo del POST. Una petición a admin-ajax.php puede no llevar “bricksforge” en el log. En ese caso, cruza por IP y hora. La señal más fuerte es un GET con éxito a un archivo .php dentro de uploads, con código 200.

#Cuándo restaurar WordPress desde una copia de seguridad

Un archivo PHP en uploads que no sabes explicar, o una cuenta de administrador desconocida, bastan para dar el sitio por comprometido. El código que se ejecutó en el servidor tuvo acceso a la base de datos, a los archivos y al wp-config.php. Borrar un archivo a mano no te dice si era el único.

El orden que funciona:

1. Guarda el estado actual, archivos y base de datos, como prueba antes de borrar nada.
2. Restaura los archivos desde una copia anterior a la primera entrada sospechosa en los logs. Si los logs no llegan tan atrás, elige una copia anterior al 3 de septiembre y vuelve a meter a mano el contenido posterior.
3. Actualiza Bricksforge a la 3.1.8.10 o a la 4.0.1 antes de que el sitio vuelva a estar en línea. La copia restaurada trae la versión antigua y vulnerable.
4. Cambia las contraseñas de la base de datos, del SFTP y de todos los administradores, genera claves nuevas en wp-config.php (wp config shuffle-salts) y revoca las contraseñas de aplicación.

Los formularios de Pro Forms suelen recoger nombres, correos y mensajes. Si el atacante tuvo acceso a la base de datos, puede tratarse de una violación de la seguridad de los datos personales según el artículo 33 del RGPD, que se notifica a la AEPD en un plazo de 72 horas desde que tuviste constancia, salvo que sea improbable que suponga un riesgo para los afectados. Documenta lo que encuentres, aunque al final no haga falta notificar.

Si la revisión no encuentra nada, no hace falta restaurar. Anota qué revisaste y cuándo.

#Cuarta vulnerabilidad en Bricksforge en 2026

La lista de Wordfence muestra entradas anteriores del mismo año: CVE-2026-14956 (hasta la 3.1.8.6, escalada de privilegios sin autenticación mediante Pro Forms, 9.8), CVE-2026-18030 (hasta la 3.1.8.7, escalada de privilegios sin autenticación mediante el restablecimiento de contraseña, 9.8) y CVE-2026-84814 (hasta la 3.1.8.8, escalada de privilegios desde suscriptor, 6.3). Tres de las cuatro tocan formularios o la lógica de inicio de sesión.

No es motivo para quitar el plugin con prisas. Es motivo para que alguien revise Bricksforge cada semana en los sitios de clientes, no una vez por trimestre.

#Cómo un contrato de mantenimiento detecta un fallo así

Un fallo explotado sin autenticación te deja días, a veces horas. Un contrato de mantenimiento WordPress debería cubrir las tres cosas que aquí deciden el resultado:

• un inventario de plugins y versiones por sitio, comerciales incluidos, porque el aviso de actualización del directorio no llega a los plugins de fuera de WordPress.org,
• avisos de vulnerabilidades (Patchstack, Wordfence, NVD) cruzados con ese inventario, para que la alerta de Bricksforge llegue a alguien que sabe que lo usas,
• logs de acceso guardados más de unos pocos días, porque sin ellos la pregunta “entró alguien antes de actualizar” se queda sin respuesta.

Si no tienes claro que tu sitio haya salido limpio de esta semana, una auditoría de seguridad WordPress cubre justo los pasos de esta lista: uploads, cuentas, cron, sumas de verificación y logs.

Última actualización: 10 de octubre de 2026. Fuentes: artículo y entrada en la base de datos de Patchstack (7 y 8 de octubre de 2026), registro de Wordfence Intelligence, registro de NVD para CVE-2026-85097, registro de cambios de Bricksforge, artículo 33 del RGPD.