Bricksforge: falla crítica explotada (CVE-2026-85097)

En pocas palabras: La vulnerabilidad CVE-2026-85097 de Bricksforge permite a cualquiera, sin iniciar sesión, subir y ejecutar código PHP en sitios con la versión 3.1.8.9 o anterior. Patchstack registró los primeros intentos de explotación el 7 de octubre de 2026 a las 21:47 UTC. La solución es actualizar a la 3.1.8.10.

La Bricksforge vulnerabilidad (CVE-2026-85097) permite a cualquiera, sin iniciar sesión, subir y ejecutar código PHP en sitios WordPress con Bricksforge 3.1.8.9 o anterior. Patchstack registró los primeros intentos de explotación el 7 de octubre de 2026 a las 21:47 UTC. La versión 3.1.8.10 la corrige.

Bricksforge es un plugin de WordPress que extiende Bricks Builder, un constructor visual de sitios, con formularios avanzados, animaciones, interacciones personalizadas y gestión de datos dinámicos. El CVE-2026-85097 es una falla de subida arbitraria de archivos sin autenticación (CWE-434) en sus versiones hasta la 3.1.8.9: el plugin valida el tipo de archivo al subirlo, pero después confía en los metadatos que manda el cliente al enviar el formulario.

Bricksforge vulnerabilidad: ¿qué versiones están afectadas?

Están afectadas todas las versiones de Bricksforge hasta la 3.1.8.9 inclusive, y la 3.1.8.10 trae la corrección, según Patchstack. El ataque no requiere cuenta ni sesión. Patchstack le asigna CVSS 10.0, mientras que las fichas de Strix y psirt publican 9.8, con el mismo vector: red, complejidad baja, sin privilegios ni interacción del usuario.

La diferencia de 0,2 puntos no cambia la lectura. (Mi suposición, que ninguna fuente confirma: el 10.0 sale de marcar el alcance como cambiado en el vector CVSS 3.1.) Para saber qué tenés instalado, entrá a Plugins, Plugins instalados, y mirá el número de versión debajo de Bricksforge. Si dice 3.1.8.9 o menos, estás en la lista.

Las fuentes no aclaran si hace falta tener publicado un formulario con subida de archivos para que el sitio sea explotable. Hasta que alguien lo documente, tratá cualquier instalación en esas versiones como expuesta. Relacionado: comparamos MalCare y Patchstack para detectar vulnerabilidades.

¿Cómo funciona la subida arbitraria de archivos en Bricksforge?

Bricksforge revisa el tipo MIME del archivo cuando se sube por primera vez, pero al enviar el formulario confía en los metadatos que manda el cliente y no valida el campo url dentro del parámetro temporaryFileUploads. Esa grieta le da al atacante cuatro pasos hasta ejecutar código, según el análisis técnico de Patchstack.

1. Pide un nonce. El endpoint AJAX bricksforge_regenerate_nonce se lo entrega a un visitante anónimo.
2. Sube un políglota GIF/PHP. Es una imagen válida que además lleva código PHP; pasa la validación MIME y queda en el directorio temporal de subidas.
3. Envía un formulario con metadatos falsos. El campo file apunta a la imagen ya validada, pero la url termina en una extensión PHP.
4. Pide el archivo PHP. Bricksforge confió en la url y puso el contenido de la imagen en esa ubicación, así que el servidor ejecuta el código al recibir la solicitud.

Un archivo políglota se lee como dos formatos a la vez: para el validador es un GIF, para el intérprete de PHP es un script. RCE (ejecución remota de código) significa que el atacante corre sus propias instrucciones en tu servidor. Desde ahí, dice Patchstack, puede desplegar web shells, modificar contenido, leer datos sensibles y dejar acceso persistente.

¿Se está explotando activamente la falla de Bricksforge?

Sí. La telemetría de Patchstack muestra intentos de explotación desde el 7 de octubre de 2026 a las 21:47:17 UTC y 63 IPs de origen únicas. Las seis más activas generaron cerca del 46% de las solicitudes.

El patrón apunta a automatización. En un grupo, 44 IPs mandaron 56 solicitudes con payloads idénticos con segundos de diferencia; en otro, tres IPs probaron 25 variaciones de extensiones y codificaciones contra el mismo archivo temporal. Todas las solicitudes menos una fueron a POST /wp-json/bricksforge/v1/form_submit, y la restante usó /wp-admin/admin-ajax.php con la acción bricksforge_form_submit. En el 95% de las solicitudes capturadas, la ruta del servidor terminaba en .gif o .png. Sobre eso hablamos en una falla crítica que arrastra WordPress desde 2016.

Las variantes incluyen .php5, .php7, .php8, .phtml, .pht, .phtm y .phps, mayúsculas mezcladas y extensiones codificadas como %2ephp. Algunos payloads buscaban dejar archivos login_admin_*.php en la carpeta normal de subidas, por ejemplo /wp-content/uploads/2026/10/, y no solo en la temporal.

Qué decisión podés tomar con esto: la infraestructura es mixta (datacenters, nubes, VPN, proxies y hasta un ISP de línea fija de Brasil), así que bloquear IPs sirve de poco. Qué no podés concluir: cuántos sitios cayeron. Nadie publicó esa cifra, y Patchstack aclara que los patrones no atribuyen la actividad a un único actor.

¿Cómo actualizar Bricksforge a la versión 3.1.8.10?

Actualizá a la 3.1.8.10 o posterior desde el panel de WordPress, con un backup hecho antes. Patchstack lo resume así (traducción nuestra): «Actualizá Bricksforge a la versión 3.1.8.10 o posterior. Eso cierra la vulnerabilidad.»

• Hacé el backup primero. Archivos y base de datos, guardados fuera del servidor.
• Actualizá desde el panel. En Plugins, Plugins instalados, usá el botón de actualización si aparece.
• Si el panel no la ofrece, subí el plugin por SFTP. Reemplazá la carpeta de Bricksforge por la de la 3.1.8.10.
• Verificá el número. Tiene que decir 3.1.8.10 o superior.
• Si hoy no podés actualizar, desactivá el plugin. Es mi recomendación, no un paso de las fuentes: sin el plugin activo, sus endpoints no deberían responder (probalo igual).

Patchstack tiene además una regla de mitigación, RapidMitigate, que bloquea estos intentos en la capa de tráfico, y afirma que estaba activa antes del primer ataque. Es dato del proveedor de la regla, así que tomalo con pinzas. En cualquier caso no reemplaza la actualización. Más contexto en las fallas críticas en Kirki y Burst Statistics.

¿Cómo saber si mi sitio WordPress ya fue comprometido?

Buscá archivos PHP que no reconozcas en las carpetas de subidas, en especial los llamados login_admin_*.php, y revisá los logs por solicitudes a /wp-json/bricksforge/v1/form_submit. Son los indicadores que cita Patchstack, junto con llamadas a bricksforge_regenerate_nonce seguidas de una subida y un envío de formulario.

Una verificación que te propongo (criterio editorial, no de la fuente): listá los PHP dentro de uploads, donde en un sitio sano casi no debería haber ninguno.

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

Ojo con los falsos positivos: algunos plugins dejan un index.php inofensivo, así que abrí cada resultado. Y un matiz: los logs de acceso comunes no guardan el cuerpo de un POST, por lo que el parámetro temporaryFileUploads solo lo vas a ver en el log de un WAF o de la aplicación. Si no tenés eso, buscá un POST a form_submit seguido de un GET a un PHP nuevo en uploads.

Completá con lo de siempre: administradores nuevos, archivos modificados fuera de fechas de actualización, tareas programadas raras y plugins que no instalaste. Actualizar no elimina una web shell ya subida.

¿Qué hacer si mi WordPress fue hackeado por un plugin vulnerable?

Poné el sitio en mantenimiento, restaurá un backup limpio y cambiá todas las credenciales antes de volver a publicarlo. Un backup «limpio» es el anterior al 7/10/2026, pero ese día es solo el primer intento que vio Patchstack en su telemetría; si tenés uno más viejo y confiable, mejor. Para más detalles técnicos, mirá plugin de citas que expone datos de clientes.

• Restaurá desde un backup anterior al ataque y actualizá Bricksforge a la 3.1.8.10 antes de reactivar el sitio.
• Eliminá las web shells que encuentres y revisá que no queden puertas traseras en el tema o en otros plugins.
• Rotá credenciales: usuarios de WordPress, base de datos, SFTP y las claves (salts) de wp-config.php.
• Auditá de nuevo usuarios, archivos y tareas programadas, y mirá los logs de los días siguientes.

Si el sitio es de un cliente o de tu negocio y no tenés a quién llamar, conviene un hosting con backups diarios y soporte ante incidentes. Para alojamiento en Argentina podés mirar donweb.com.

¿Cómo evitar que un plugin vulnerable comprometa mi WordPress?

Reducí la superficie y acortá los tiempos: menos plugins, actualizaciones rápidas y una capa que frene lo que se escape. Acá el primer intento que registró Patchstack es del 7 de octubre, un día antes de la fecha de publicación del CVE (8/10/2026). La ventana para reaccionar fue cortísima. Más sobre esto en benchmark que evalúa la seguridad de la IA.

• Actualizá apenas salga el parche, sobre todo en plugins con formularios o subidas.
• Borrá los plugins que no usás. Desactivados también ocupan lugar en el servidor.
• Seguí avisos de vulnerabilidades de los plugins que tenés, con un servicio de alertas.
• Poné un WAF. Frena patrones conocidos mientras llegás a actualizar.
• Bloqueá la ejecución de PHP en uploads. En teoría el archivo se subiría pero no correría; no lo probamos con este exploit.
• Ajustá permisos de archivos y guardá backups externos.
• Revisá roles y usuarios cada tanto, como parte de una auditoría de seguridad periódica.

¿Qué está confirmado y qué no sobre la falla de Bricksforge?

Confirmado

• Versiones afectadas hasta la 3.1.8.9 y corrección en la 3.1.8.10 (Patchstack, Strix, psirt).
• Mecánica en cuatro pasos y explotación activa desde el 7/10/2026 a las 21:47:17 UTC, según la telemetría de Patchstack.
• Debilidad CWE-434 y CVSS 3.1 de 9.8 en las fichas de Strix y psirt.

Sin confirmar

• Cuántos sitios fueron comprometidos y quién está detrás: no hay datos públicos.
• El estado en NVD: Strix lo muestra como «Deferred», con análisis pendiente.
• Los indicadores de agregadores están desfasados con la realidad: Strix estima un EPSS de 0.31%, psirt marca 0% y exploit público «No», y a la vez Patchstack ve ataques. Un riesgo «bajo» en esos números no te «protege» de nada.
• Si hace falta un formulario publicado para ser explotable.

Errores comunes al responder a esta vulnerabilidad

• Actualizar y dar el tema por cerrado. Si el sitio ya recibió un archivo PHP malicioso, sigue ahí después del parche. Buscalo.
• Guiarse por el EPSS o por «sin exploit público». Esos campos van detrás de la telemetría de campo. Patchstack ya ve ataques.
• Bloquear las IPs del informe. Son 63 y rotan entre proxies, VPN y nubes. Tapa una fuga con un dedo.
• Revisar solo la carpeta temporal. Algunos payloads apuntaban a /wp-content/uploads/2026/10/, así que mirá todo uploads.
• Restaurar un backup sin saber de cuándo es. Si es posterior a la intrusión, restaurás la web shell con él.

Preguntas Frecuentes

¿Qué es la vulnerabilidad CVE-2026-85097 de Bricksforge?

Es una falla de subida arbitraria de archivos sin autenticación en Bricksforge hasta la versión 3.1.8.9. Permite ejecutar código PHP en el servidor y tiene CVSS 10.0 según Patchstack (9.8 en otras fichas). La corrige la versión 3.1.8.10. Mirá también los CVEs de 2026 en MCP stdio.

¿Qué es un archivo políglota GIF/PHP?

Es un archivo que es una imagen GIF válida y a la vez contiene código PHP. Pasa la validación de tipo MIME como imagen, pero si el servidor lo guarda con extensión .php, ejecuta el código incrustado.

¿Cómo actualizo Bricksforge a la versión 3.1.8.10?

Hacé un backup y actualizá desde Plugins, Plugins instalados; si el panel no la ofrece, reemplazá la carpeta del plugin por SFTP. Después confirmá que la versión diga 3.1.8.10 o superior.

¿Alcanza con actualizar si mi sitio ya recibió un ataque?

No alcanza. La actualización cierra la falla, pero no elimina archivos PHP maliciosos ya subidos ni accesos que el atacante haya creado. Buscá archivos como login_admin_*.php en uploads y revisá usuarios y tareas programadas.

Conclusión

La Bricksforge vulnerabilidad pasó de un aviso a un ataque en curso: según Patchstack, los intentos empezaron el 7 de octubre de 2026, antes de que el CVE figurara publicado. Si usás Bricksforge, actualizá hoy a la 3.1.8.10. Después, buscá PHP sospechoso en uploads y en los logs, porque el parche no limpia lo que ya entró.

Los datos de explotación son de una sola telemetría, la de Patchstack, que además vende una mitigación para este caso. Es una fuente creíble y detallada, pero conviene que verifiques en tu propio servidor antes de dar el sitio por limpio.

Fuentes

• Patchstack – informe técnico con indicadores, payloads y fecha del primer ataque
• Strix – ficha de CVE-2026-85097 con CVSS 9.8 y EPSS
• psirt – ficha de CVE-2026-85097 con vector CVSS y estado de exploit
• Bricksforge – changelog de versiones, citado como aviso del proveedor en Patchstack (no lo revisamos para este artículo)