Vulnerabilidad en Bricksforge (Bricks): qué hacer hoy

Si tu web usa Bricks Builder y tiene instalado el plugin Bricksforge, esto va contigo. Y si no sabes si lo tiene, también: se comprueba en dos minutos.

El 8 de octubre de 2026, Patchstack publicó un aviso sobre un fallo en Bricksforge, catalogado como CVE-2026-85097. Permite a cualquier desconocido, sin contraseña, subir un archivo PHP a tu servidor y ejecutarlo. Es lo que en seguridad se llama ejecución remota de código: quien lo consigue puede hacer en tu web casi lo que quiera.

Patchstack registró los primeros intentos de ataque el 7 de octubre a las 21:47 UTC. Es decir, el fallo se explotaba antes de que existiera el aviso público.

Dos aclaraciones antes de seguir, porque en los titulares se mezclan:

• El fallo está en Bricksforge, no en Bricks. Bricksforge es un plugin aparte que se instala encima del constructor. Actualizar el tema Bricks no lo arregla.
• La gravedad depende de quién la puntúe. Patchstack le pone un 10,0 sobre 10. La ficha del NVD, con los datos de Wordfence, un 9,8. En la práctica da igual: es crítico y se está explotando.

Qué versiones están afectadas

Versión de Bricksforge	Situación
3.1.8.9 y anteriores	Vulnerable a CVE-2026-85097
3.1.8.10 y 4.0.0	Corrigen este fallo, según el registro de cambios del propio plugin
4.0.1 (8-10-2026)	Corrige un problema de seguridad adicional en la subida de archivos de Pro Forms
4.0.2 (13-10-2026)	Endurece varios endpoints REST. Es la más reciente que figura en el registro de cambios al escribir esto

Mi consejo es ir directamente a la última versión, no quedarse en la 3.1.8.10. El registro de cambios dice de la 4.0.1 que su corrección afecta a «todos los sitios con Pro Forms activo, incluso los que no tienen campos de subida de archivos». Y el salto a la 4.x es grande, así que conviene probarlo (más abajo, cómo).

Cómo saber si tu web usa Bricksforge

1. En el panel de WordPress, entra en Plugins > Plugins instalados y busca «Bricksforge». Fíjate en la versión.
2. Si está instalado pero desactivado, no lo dejes ahí: o lo actualizas o lo borras. Un plugin desactivado no se ejecuta, pero sigue ocupando sitio en el servidor y se te olvida.
3. Si no sabes si tu web usa Bricks, el tema activo aparece en Apariencia > Temas.

¿Hace falta tener formularios con subida de archivos para estar expuesto? Patchstack no lo concreta: dice que el código vulnerable está en el módulo de formularios Pro Forms y que afecta a todas las versiones hasta la 3.1.8.9. Y el fabricante, como hemos visto, habla de todos los sitios con Pro Forms activo. Mientras no haya una confirmación mejor, trátalo como si te afectara por el mero hecho de tener el plugin.

Cómo funciona el ataque (en corto)

Sirve para entender qué buscar después. Según Patchstack, el ataque tiene cuatro pasos:

1. El atacante pide un código de seguridad (nonce) a una función pública del plugin, sin identificarse.
2. Sube una imagen GIF que en realidad lleva código PHP dentro. El plugin comprueba que parece una imagen y la acepta.
3. Envía un formulario donde la ruta apunta a esa imagen, pero la dirección de destino acaba en .php. El plugin no valida ese destino.
4. El servidor copia el contenido a un archivo PHP. Basta con visitarlo para que el código se ejecute.

Por eso las pistas son archivos PHP donde no deberían estar.

Qué revisar si tu versión era vulnerable

Actualizar cierra la puerta, pero no echa a quien ya entró. Esto lo dice Patchstack tal cual: si la web no estaba protegida, hay que revisar el servidor y los registros.

Las pistas concretas que publica Patchstack:

• Archivos PHP en /wp-content/uploads/bricksforge/tmp/.
• Archivos con nombre login_admin_*.php, en la carpeta de subidas (alguna carga útil apuntaba a /wp-content/uploads/2026/10/).
• Extensiones camufladas: .php5, .php7, .php8, .phtml, .pht, .phtm, .phps, o mayúsculas mezcladas (.pHp).
• En los registros del servidor, peticiones POST a /wp-json/bricksforge/v1/form_submit, o a admin-ajax.php con la acción bricksforge_form_submit o bricksforge_regenerate_nonce.

Revisiones generales (no son de Patchstack, pero son lo habitual tras cualquier subida de PHP):

• Cualquier archivo .php dentro de wp-content/uploads. Ahí no debería haber código. Ojo: algunos plugins dejan un index.php casi vacío para evitar listados de carpetas; ese suele ser inofensivo, pero míralo.
• Usuarios administradores que no reconozcas en Usuarios.
• Plugins instalados que tú no instalaste.
• Archivos modificados recientemente en la raíz de WordPress y en wp-content.
• Tareas programadas (cron) y avisos de seguridad en Search Console.

Si tienes acceso por SSH, esta orden lista los PHP de la carpeta de subidas:

find wp-content/uploads -type f \( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.pht" -o -iname "*.phps" \)

Patchstack describe la actividad como automatizada, con 63 direcciones IP distintas y sin atribuirla a un único actor. Hablan de una campaña masiva, no de alguien que te haya elegido a ti. Pero eso significa también que no hace falta ser un objetivo interesante para recibir la visita.

Y una cosa más: no hay forma de saberlo sin mirar. Que la web «funcione normal» no prueba nada; un web shell no avisa.

Si encuentras algo

Con calma y por orden. Lo primero es no borrar a ciegas: destruyes las pistas de cómo entraron.

1. Guarda una copia de la web tal como está (archivos y base de datos) y de los registros del servidor.
2. Actualiza Bricksforge a la última versión, o desactívalo y bórralo si no lo usas.
3. Cambia las credenciales: la contraseña del hosting, la de los administradores de WordPress y las claves de la base de datos. Si el atacante ejecutó código, pudo leer wp-config.php. Además, el fabricante recomienda en su versión 4.0.2 renovar las claves de API guardadas en los ajustes de Bricksforge.
4. Revisa usuarios, plugins y archivos con la lista de arriba.
5. No restaures una copia a ciegas. Si es posterior al 7 de octubre, puede traer la puerta trasera de vuelta. Averigua desde cuándo está dentro.
6. Valora ayuda profesional si hay archivos que no entiendes. Limpiar a medias es peor que no limpiar: el atacante suele dejar más de una entrada.

Qué hacer según tu caso

Tu caso	Qué hacer hoy
No tienes Bricksforge	Nada que hacer por este fallo. Comprueba tus otros plugins
Lo tienes y estás en 3.1.8.9 o anterior	Copia, actualiza a la última versión y revisa las pistas de arriba. Prioridad máxima
Lo tienes en 3.1.8.10 o 4.0.0	Actualiza a la última. Este fallo ya está corregido ahí, pero revisa igualmente las pistas de arriba si no sabes cuándo actualizaste
No puedes actualizar ahora mismo	Desactiva el plugin hasta que puedas. Patchstack menciona una regla de bloqueo propia (RapidMitigate) para sus clientes; un WAF puede ayudar, pero no sustituye a la actualización
Tienes archivos sospechosos	Sigue la lista de «Si encuentras algo»

Sobre la actualización: Bricksforge pasó de la 3.x a la 4.x. Si puedes, hazla primero en una copia de pruebas (staging), mira que los formularios, las animaciones y las plantillas siguen bien, y entonces súbela a producción. Si la web es una tienda o recibe contactos, prueba un envío de formulario completo. Pero no retrases la actualización por eso más de un día: hay ataques activos.

Qué sabemos y qué no

• Confirmado: CVE-2026-85097, versiones afectadas, versión de corrección, primeros ataques el 7 de octubre, rutas y archivos que publica Patchstack.
• A fecha de hoy no figura en el catálogo KEV de la CISA (la lista de fallos explotados que mantiene la agencia de ciberseguridad de EE. UU.), según su archivo del 23 de octubre. Eso no quiere decir que no se explote: Patchstack sí lo observa.
• Sin confirmar: cuántas webs han sido comprometidas de verdad. Patchstack habla de intentos bloqueados, no de hackeos consumados.
• No sabemos qué hacen los atacantes después de subir el archivo, más allá de que ejecutan código. No lo cuentan las fuentes que he podido contrastar.

Y ahora, qué

Entra en el listado de plugins, mira si aparece Bricksforge y qué versión tiene. Si lo tienes, copia, actualiza y busca archivos PHP en uploads. Son diez minutos y te quitan la duda.

Si encuentras algo raro y prefieres que lo mire alguien, en AGENCIA RSE hacemos limpieza de malware en WordPress: primero revisamos qué ha pasado, y luego limpiamos. También tienes algunas pruebas gratuitas para revisar tu web desde fuera.

Si ves un dato desactualizado, escríbenos y lo corregimos.