CVE-2026-10818 en WPForms Pro: qué revisar además de actualizar

Resumen: CVE-2026-10818 permite escribir archivos sin autenticación en sitios que usan WPForms Pro 1.10.1.1 o una versión anterior. Wordfence y WPScan sitúan la corrección en WPForms Pro 2.0.0. Si gestionas una cartera WordPress, el trabajo no consiste en buscar “WPForms” a secas: hay que distinguir Lite de Pro, confirmar versiones y revisar si aparecieron archivos inesperados antes de actualizar.

El nombre WPForms invita a usar una cifra llamativa. Su página comercial habla de más de seis millones de usuarios y WordPress.org muestra más de cinco millones de instalaciones activas para WPForms Lite. Pero la vulnerabilidad publicada afecta a WPForms Pro, cuyo número de instalaciones no está disponible en el repositorio público. Presentar todos esos sitios como vulnerables sería incorrecto.

Esa distinción no reduce el riesgo. Lo hace más operativo: una agencia necesita saber en qué webs está instalada la edición Pro, qué versión ejecuta cada una y cuáles aceptan archivos de visitantes. Un inventario que solo registra “WPForms” puede ocultar precisamente las instalaciones que requieren atención.

Qué se ha confirmado sobre CVE-2026-10818

El registro CVE-2026-10818, publicado el 25 de julio de 2026, describe un fallo en la finalización de subidas por fragmentos. La validación del tipo de archivo se producía después de que los metadatos y el contenido ya se hubieran escrito en disco, y el archivo ensamblado no se eliminaba cuando la validación fallaba.

Según el aviso de Wordfence y la ficha de WPScan, un atacante sin cuenta puede conseguir que el servidor escriba un archivo que podría ser ejecutable. Eso hace posible una ejecución remota de código, pero no significa que cualquier subida termine automáticamente en ejecución: también influyen la petición construida por el atacante y la configuración del servidor.

• Producto afectado: WPForms Pro, no la edición Lite indicada de forma genérica.
• Versiones afectadas: hasta la 1.10.1.1 incluida.
• Versión corregida: 2.0.0 o posterior.
• Acceso necesario: ninguno.
• Impacto: escritura arbitraria de archivos; puede desembocar en ejecución de código si el archivo llega a ejecutarse en el servidor.
• Severidad: CVSS 8,1, alta, con complejidad de ataque alta.
• Explotación activa: no hemos encontrado confirmación en una fuente primaria y la CVE no figuraba en el catálogo KEV de CISA durante esta revisión. No debe presentarse como una campaña confirmada.

El changelog oficial de WPForms fecha la versión 2.0.0 el 14 de julio. La divulgación pública llegó después. Ese margen es útil para reducir exposición si las licencias y actualizaciones Pro funcionaron, pero no demuestra que todas las instalaciones recibieran la versión corregida.

El primer error sería buscar solo el plugin Lite

WPForms Lite se distribuye desde WordPress.org y su versión aparece en los inventarios habituales. WPForms Pro se entrega mediante licencia comercial. En una cartera con compras descentralizadas, licencias caducadas, paquetes de mantenimiento diferentes o copias instaladas manualmente, ambas ediciones pueden no tener la misma visibilidad ni el mismo ritmo de actualización.

Por eso no basta con comprobar que “WPForms está actualizado” en un panel general. Registra por sitio la edición exacta, la versión que realmente se está ejecutando, el estado de la licencia y la fecha del último cambio. Si el inventario no distingue Lite de Pro, este incidente ya ha revelado una carencia de proceso.

Qué debe revisar una agencia WordPress ahora

1. Localiza WPForms Pro en toda la cartera

Busca la edición Pro en archivos, listado de plugins y herramientas de gestión remota. No infieras su presencia porque exista WPForms Lite ni su ausencia porque el panel central muestre un nombre abreviado. Separa cuatro estados: Pro 2.0.0 o posterior, Pro 1.10.1.1 o anterior, edición Lite y versión o edición no verificable.

Actualiza las instalaciones Pro afectadas a la versión estable más reciente. Si una licencia impide descargarla, no dejes el sitio en una cola indefinida: desactiva temporalmente el componente vulnerable cuando el proceso del cliente lo permita y escala la renovación o sustitución.

2. Identifica qué sitios aceptan archivos y dónde terminan

Haz un mapa de los formularios con campos de subida: candidaturas, soporte, presupuestos, documentación, imágenes o adjuntos. Anota extensiones permitidas, tamaño máximo, usuarios que reciben los archivos, carpeta de destino y si el servidor puede ejecutar PHP u otros formatos en ese directorio.

Esta información no sirve para decidir si la versión es vulnerable —eso lo determina la versión de WPForms Pro—, sino para priorizar impacto y endurecer el entorno. Un directorio de subidas no debería ejecutar scripts. Confirma esa protección en la configuración real del servidor, no solo en la interfaz del formulario.

3. Busca archivos y peticiones anómalas antes de cerrar el aviso

Conserva primero los logs y metadatos disponibles. Revisa las peticiones relacionadas con subidas fragmentadas de WPForms durante el periodo en que el sitio ejecutó una versión afectada. Busca secuencias inusuales, picos de peticiones, errores repetidos y orígenes que no coincidan con el uso normal de los formularios.

En el sistema de archivos, localiza elementos nuevos o modificados en carpetas de subida y temporales. Presta atención a archivos PHP, extensiones dobles, nombres engañosos y contenido que no corresponda a envíos legítimos. Compara fechas y hashes con copias fiables cuando existan. No borres una muestra sospechosa antes de preservar la evidencia necesaria.

La ausencia de un hallazgo en logs incompletos no prueba que no hubiera actividad. Documenta desde qué fecha existe evidencia y qué rutas has podido revisar. Una conclusión limitada es más útil que una falsa certeza.

4. Si aparece un archivo sospechoso, trata el sitio como un posible incidente

Aísla el sitio según el plan del cliente, conserva evidencia y comprueba persistencia: plugins o usuarios nuevos, tareas programadas, cambios en archivos de WordPress, claves añadidas y conexiones salientes. Rota las credenciales que pudieran haber quedado accesibles desde el servidor y reconstruye desde una base fiable si no puedes acotar la modificación.

Actualizar WPForms Pro cierra la vía conocida, pero no elimina una puerta trasera que ya se hubiera escrito. El criterio de cierre debe ser por sitio: versión corregida, superficie de subida revisada, archivos y logs comprobados, hallazgos resueltos y limitaciones anotadas.

La lección para carteras: inventario de producto, edición y licencia

Este caso muestra por qué una lista plana de nombres de plugins es insuficiente. La misma familia de producto puede tener ediciones con código, distribución y actualizaciones diferentes. Para componentes premium, el inventario útil incluye edición, versión, licencia, responsable y capacidad sensible: subir archivos, gestionar identidad, procesar pagos o almacenar datos.

Si necesitas ordenar ese trabajo, nuestra guía sobre cómo mantener un inventario vivo cuando administras muchos WordPress explica qué información debe estar disponible antes de que llegue una alerta urgente.

Una vista centralizada de señales de seguridad y hardening para varios WordPress ayuda a coordinar la respuesta y reducir puntos ciegos entre sitios. Vulnity no detecta CVE-2026-10818 ni identifica por sí sola qué instalación de WPForms Pro es vulnerable; esa comprobación exige revisar edición y versión en cada web.