CVE-2026-9843: borrado de archivos en Database for Contact Form 7 Entries

Actualizacion rapida: CVE-2026-9843 afecta al plugin Database for Contact Form 7, WPforms, Elementor forms para WordPress. La vulnerabilidad permite borrado arbitrario de archivos en versiones hasta la 1.5.1, con severidad CVSS 8.1 High segun el registro CVE publicado por Wordfence.

El plugin se usa para guardar en la base de datos envios de Contact Form 7, WPForms, Elementor Forms y otros formularios. La pagina oficial de WordPress.org muestra 60.000+ instalaciones activas, version estable 1.5.3 y una actualizacion reciente. El changelog confirma que la version 1.5.2 corrige el problema de Unauthenticated Arbitrary File Deletion y que la 1.5.3 corrige ademas un XSS.

Que paso

Segun el registro CVE, el fallo esta relacionado con una validacion insuficiente de rutas de archivo en la funcion view_page. Un atacante no autenticado puede preparar una entrada de formulario con una ruta manipulada. La explotacion requiere que un administrador vea o edite esa entrada en el panel de WordPress; en ese momento, el procesado de la entrada puede terminar borrando el archivo indicado.

El impacto puede ser serio porque el borrado de archivos sensibles, como wp-config.php, puede dejar el sitio inestable y abrir la puerta a compromiso posterior. No hay que tratarlo como un simple fallo de formulario: afecta a una zona donde muchos sitios almacenan leads, adjuntos y datos operativos.

A quien afecta

El riesgo aplica a sitios WordPress con Database for Contact Form 7, WPforms, Elementor forms en version 1.5.1 o anterior. La vulnerabilidad no requiere una cuenta de usuario, pero si depende de interaccion posterior de un administrador con la entrada manipulada. CISA ADP marca la explotacion como none en su enriquecimiento del CVE, asi que no conviene afirmar explotacion activa si no hay otra evidencia publica fuerte.

Que hacer ahora

• Actualizar el plugin a 1.5.3 o superior. Como minimo, no quedarse por debajo de 1.5.2.
• Revisar sitios con formularios que acepten archivos o que reciban mucho spam, porque aumentan la superficie de entradas maliciosas.
• Comprobar si hay entradas recientes sospechosas antes de que un administrador las abra o edite.
• Verificar backups y restauracion de archivos clave, especialmente wp-config.php y configuraciones de plugins criticos.
• Si el plugin no es necesario en algun sitio, retirarlo en vez de dejarlo instalado “por si acaso”.

Como priorizarlo en carteras multi-sitio

Para agencias y equipos que mantienen muchas webs WordPress, la prioridad deberia ir primero a sitios con formularios publicos, formularios con subida de archivos, alto volumen de spam o clientes donde una caida por borrado de archivos tenga impacto comercial inmediato. Despues conviene revisar el resto de instalaciones y dejar documentado que version quedo aplicada en cada sitio.

Este caso tambien muestra un patron operativo frecuente: no basta con saber que “hay formularios”. Hay que saber que plugin guarda entradas, que versiones hay desplegadas y donde una accion rutinaria del administrador podria activar un flujo vulnerable.

Fuentes

• CVE.org / CVE API: CVE-2026-9843
• NVD: CVE-2026-9843
• WPScan: Database for Contact Form 7, WPforms, Elementor forms < 1.5.2
• WordPress.org: pagina oficial del plugin
• WordPress.org SVN: changelog del plugin

Lectura Vulnity

Vulnity no detecta automaticamente este CVE ni corrige vulnerabilidades de plugins. Lo que si aporta en un entorno multi-sitio es visibilidad centralizada, alertas operativas, revision de hardening, vigilancia de actividad sospechosa, bloqueo de IPs maliciosas cuando aplica y una forma mas rapida de documentar que sitios fueron revisados, actualizados o priorizados.