Investigadores de seguridad han detectado explotación activa de una vulnerabilidad crítica en el plugin Bricksforge para WordPress que permite ejecución remota de código (RCE) por parte de atacantes no autenticados. La falla afecta a versiones anteriores a la corrección publicada y su explotación permite subir y ejecutar archivos PHP arbitrarios en servidores que alojan sitios WordPress con el plugin vulnerable.
Qué falla y cómo se explota
El problema se debe a una validación insuficiente de un campo de tipo URL dentro del parámetro temporaryFileUploads durante la presentación de formularios gestionados por la API REST de Bricksforge o por la acción AJAX equivalente. En la práctica, el plugin verifica el tipo MIME del archivo cuando se sube inicialmente, pero más tarde confía en metadatos enviados por el cliente al procesar el formulario.
El flujo de explotación observado sigue estos pasos generales: obtener un nonce válido mediante el endpoint AJAX de Bricksforge, subir un archivo con doble interpretación (por ejemplo, un GIF que también contiene código PHP) a la carpeta temporal donde sí se realiza la comprobación MIME, y después enviar el formulario con temporaryFileUploads apuntando al archivo validado mientras la URL manipulada termina en una extensión PHP. Esa discrepancia permite que el servidor ejecute el payload PHP.
Los atacantes han empleado técnicas para evadir filtros por extensión, usando variantes como .php5, .phtml, mayúsculas mixtas (.PHP) y codificaciones URL de la extensión. Además, los patrones del tráfico indican actividad automatizada distribuida desde múltiples orígenes.
Impacto para sitios y servidores
Si la explotación tiene éxito, el atacante puede ejecutar código PHP arbitrario en el servidor web, lo que facilita la instalación de web shells, lectura de archivos sensibles, creación de cuentas, persistencia y, en definitiva, el control total del sitio WordPress afectado. La presencia de un web shell o de plugins maliciosos puede permanecer oculta y permitir reinfecciones incluso tras parchear el plugin, si no se limpia la intrusión.
Qué deben hacer administradores y propietarios
- Actualizar el plugin: instale la versión del plugin que incorpora la corrección lo antes posible en todos los sitios afectados.
- Auditar indicios de compromiso: revise solicitudes al endpoint /wp-json/bricksforge/v1/form_submit y a /wp-admin/admin-ajax.php con la acción correspondiente, buscando parámetros temporaryFileUploads sospechosos, múltiples envíos repetidos o intentos con extensiones PHP atípicas.
- Buscar archivos y cambios inusuales: compruebe la carpeta temporal de subidas del plugin (/wp-content/uploads/bricksforge/tmp/ u equivalente), busque archivos PHP inesperados y revise los logs web para identificar accesos y patrones de explotación.
- Revisar usuarios y plugins: verifique la existencia de cuentas administrativas ocultas en la base de datos, inspeccione el directorio de plugins obligatorios (must-use) y desactive o elimine plugins no autorizados.
- Restaurar desde copia limpia si es necesario: si hay indicios claros de compromiso persistente, considere restaurar desde un backup anterior a la intrusión y cambiar credenciales.
Prevención y buenas prácticas
Además de aplicar el parche, es recomendable endurecer configuraciones: limitar permisos de escritura en carpetas de subida, usar un firewall de aplicaciones web que filtre cargas sospechosas, habilitar escaneos periódicos de integridad y mantener WordPress y todos los componentes actualizados. Estas medidas ayudan a bloquear intentos automatizados antes de que lleguen al punto de explotación.
Nota: la corrección evita la explotación conocida, pero no elimina artefactos dejados por atacantes que ya comprometieron sitios. Una respuesta forense y la limpieza completa son necesarias en caso de infección.
Lee también:
- WordPress corrige siete vulnerabilidades en 7.1.3; recompensas por bugs superan los 90.000 dólares en 90 días
- WordPress como «fuente de la verdad»: block themes, IA y flujos de trabajo para agencias
Fuente: The Hacker News
