CVE-2026-3359 es una vulnerabilidad de SQL Injection sin autenticación en el plugin Form Maker by 10Web para WordPress, que afecta todas las versiones hasta la 1.15.42 inclusive. Un atacante remoto puede manipular el parámetro inputs para inyectar consultas SQL arbitrarias y extraer información sensible de la base de datos sin necesidad de tener ninguna cuenta en el sitio.
En 30 segundos
- Plugin afectado: Form Maker by 10Web, versiones hasta 1.15.42 incluida
- Tipo de ataque: SQL Injection sin autenticación (CVSS 7.5, impacto a confidencialidad: Alto)
- Vector: el parámetro
inputsno escapa correctamente los datos del usuario antes de armarlos en una consulta SQL - Consecuencia: cualquier visitante puede extraer datos sensibles de tu base de datos WordPress
- Solución: actualizar al parche disponible en el repositorio oficial de WordPress (changeset 3518461)
Wordfence es un plugin de seguridad para WordPress que detecta y bloquea malware, intrusiones y vulnerabilidades. Desarrollado por Wordfence Security, monitorea en tiempo real la actividad del sitio para prevenir ataques.
¿Qué es CVE-2026-3359?
CVE-2026-3359 es el identificador oficial de una vulnerabilidad de tipo SQL Injection (CWE-89) descubierta en Form Maker by 10Web, un plugin de creación de formularios de contacto para WordPress. El problema fue publicado y documentado por Wordfence Threat Intelligence, que la clasifica como crítica en términos de riesgo práctico.
La vulnerabilidad permite que un atacante no autenticado —es decir, cualquier persona con acceso a internet, sin usuario ni contraseña— inyecte consultas SQL adicionales en las que ya ejecuta el plugin. El resultado: puede leer tablas enteras de tu base de datos. Credenciales de usuarios, correos, tokens de sesión, datos de clientes si usás WooCommerce. Todo lo que esté en la base.
El plugin tiene más de 700.000 instalaciones activas. No es un plugin de nicho.
Riesgo técnico y puntuación CVSS
El vector CVSS v3.1 es AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, con una puntuación base de 7.5. Traducido al castellano:
- AV:N (Network) — el ataque se ejecuta de forma remota, por red
- AC:L (Low complexity) — no requiere condiciones especiales ni timing preciso
- PR:N (No privileges) — ningún privilegio en el sitio, ni siquiera una cuenta de suscriptor
- UI:N (No user interaction) — el atacante no necesita que la víctima haga nada
- C:H (Confidentiality: High) — impacto total sobre la confidencialidad de los datos
- I:N / A:N — no permite modificar datos ni tirar el sitio (al menos no directamente)
La combinación PR:N más AC:L es lo que hace que esto sea especialmente grave. ¿Por qué? Porque significa que podés automatizar el ataque con herramientas como SQLMap y apuntarla a miles de sitios en paralelo. No es un ataque que requiere conocimiento específico del objetivo ni paciencia. Es un script y a correr.
Eso sí: el impacto en integridad y disponibilidad es nulo según el vector CVSS. El atacante lee, pero no escribe ni borra (al menos con este vector). Eso no significa que no sea grave —leer credenciales de administrador es todo lo que necesitás para escalar después.
Parámetro vulnerable y cómo funciona el ataque
Ponele que tenés un formulario de contacto armado con Form Maker by 10Web en tu sitio. Cuando alguien lo completa, los datos de los campos viajan al servidor en el parámetro inputs. El plugin toma ese parámetro y lo incorpora en una consulta SQL para guardar o procesar la respuesta.
El problema, según la descripción oficial de INCIBE-CERT, es doble: escaping insuficiente sobre el parámetro que manda el usuario, más falta de preparación adecuada en la consulta SQL existente. Sin prepared statements y sin escape correcto, un atacante puede cerrar la consulta original e inyectar la suya propia.
El mecanismo es el clásico de inyección por append: la consulta del plugin dice algo como SELECT ... WHERE id = '$inputs', y si $inputs llega sin sanitizar, el atacante puede mandar ' UNION SELECT user_login, user_pass FROM wp_users-- y obtener los hashes de contraseñas de todos los usuarios del sitio.
¿Alguien verificó que esto funciona en la práctica sin autenticación? Wordfence lo confirmó con evidencia suficiente como para publicarlo en su base de datos de inteligencia de amenazas, que tiene reputación bastante sólida en el ecosistema WordPress.
Versiones afectadas y parche disponible
| Versión | Estado | Acción recomendada |
|---|---|---|
| Hasta 1.15.42 (inclusive) | Vulnerable | Actualizar de inmediato |
| 1.15.43 o superior | Parcheada | Verificar que actualizaste |
El parche está disponible en el repositorio oficial de WordPress. El changeset 3518461 en el Trac del plugin muestra exactamente qué se cambió en el código para corregir el escaping y la preparación de la consulta. Si tenés curiosidad técnica, vale mirarlo.
Si instalaste el plugin hace tiempo y no activaste las actualizaciones automáticas, es probable que estés en una versión vulnerable. WordPress no actualiza plugins automáticamente salvo que lo configurés explícitamente o uses alguna herramienta de gestión masiva.
Pasos para parchear y actualizar
El proceso es directo:
- Paso 1: Antes de cualquier cambio, hacé un backup completo —archivos y base de datos. WPVivid, UpdraftPlus, o lo que uses. No salteés esto.
- Paso 2: Entrá a Escritorio → Plugins → Plugins instalados y buscá «Form Maker by 10Web». Fijate la versión que figura.
- Paso 3: Si dice «1.15.42» o menos, vas a ver el link de actualización disponible. Hacé clic en «Actualizar ahora».
- Paso 4: Una vez actualizado, verificá que la versión nueva aparezca correctamente (1.15.43 o superior).
- Paso 5: Probá que los formularios sigan funcionando. Mandá un formulario de prueba y verificá que llega bien.
Si tenés un entorno de staging, aplicá la actualización ahí primero y testeá con una versión de producción de la base de datos. Los formularios a veces tienen lógica condicional o integraciones con CRMs que pueden comportarse distinto después de un update del plugin.
Mitigación temporal si no podés actualizar ahora
Hay casos donde actualizar de inmediato no es opción: staging congelado, proceso de aprobación corporativo, miedo a romper un formulario crítico en producción. Si ese es tu caso, estas medidas bajan el riesgo mientras resolvés:
- WAF activo: Wordfence en modo «Extended Protection» bloquea payloads SQL comunes. Si ya lo tenés instalado, verificá que las reglas estén actualizadas. La versión gratuita tiene un delay de 30 días en las reglas nuevas; la Premium las recibe en tiempo real.
- Reglas ModSecurity: Si tu hosting tiene ModSecurity (OWASP Core Rule Set), activá las reglas de SQL Injection (ruleset 942xxx). Podés hacerlo desde el panel de tu proveedor de hosting.
- Restricción por IP: Si tus formularios solo los usan usuarios de regiones específicas, configurá geoblocking para el endpoint del formulario desde el firewall.
- Monitoreo de logs: Activá logging detallado en Wordfence o en tu WAF y buscá peticiones al endpoint del formulario con caracteres como
',--,UNION,SELECT.
Nada de esto reemplaza el parche. Son medidas de contención, no de solución.
Cómo detectar si tu sitio ya fue atacado
Acá viene lo importante si tenés dudas de si alguien ya explotó esto antes de que parcheés:
Revisá los access logs de tu servidor buscando peticiones POST al endpoint del plugin con contenido anómalo. Las señales típicas son presencia de caracteres SQL en el body (UNION, SELECT, comillas simples, doble guión), peticiones de fuentes IP que no son usuarios normales de tu sitio, y tiempos de respuesta inusualmente largos en esas requests (las queries por UNION a veces tardan más).
También podés usar el escáner de Wordfence (opción «Scan» → «Start New Scan») con la opción de escaneo de base de datos activada. Si alguien insertó datos maliciosos via la inyección, puede aparecer ahí.
Otro punto a revisar: la tabla wp_users. Si hay usuarios administradores que no reconocés, es posible que la explotación haya escalado más allá de la lectura. En ese caso, el protocolo es más serio: cambio de todas las contraseñas, revisión de archivos del servidor, y potencialmente restaurar desde backup limpio.
Errores comunes al manejar esta vulnerabilidad
Error 1: Asumir que «no tengo datos importantes» en los formularios. Los formularios de contacto guardan nombres, mails, mensajes, y a veces más. Si usás WooCommerce y los formularios interactúan con la tienda, la superficie es mucho mayor. La base de datos siempre tiene más de lo que parece.
Error 2: Confiar en que el firewall de tu hosting alcanza. Los firewalls de nivel de hosting bloquean tráfico genérico, pero sin reglas específicas para este CVE, van a dejar pasar payloads bien armados. Un WAF específico para WordPress como Wordfence tiene contexto que un firewall de red no tiene.
Error 3: Actualizar el plugin sin hacer backup primero. Raro pero pasa: actualizás, el plugin tira un error de compatibilidad con el tema o con otro plugin, y ahora tenés el formulario roto y sin copia de la configuración anterior. El backup cuesta dos minutos y salva horas de trabajo.
Para entender mejor este tema, mirá nuestro análisis de CVE-2026-3359.
Para más detalles, mirá nuestro artículo sobre CVE-2026-3359.
Preguntas Frecuentes
¿Qué es CVE-2026-3359 y cómo afecta mi WordPress?
CVE-2026-3359 es una vulnerabilidad de SQL Injection en el plugin Form Maker by 10Web que afecta a todas las versiones hasta la 1.15.42. Un atacante sin cuenta en tu sitio puede explotar el parámetro inputs del formulario para inyectar consultas SQL y leer datos sensibles de tu base de datos, incluyendo usuarios y contraseñas hasheadas.
¿Cuál es la versión segura de Form Maker by 10Web?
La versión parcheada está disponible a partir del changeset 3518461 del repositorio oficial de WordPress. Actualizá a la última versión disponible del plugin desde tu panel de WordPress; cualquier versión superior a 1.15.42 incluye la corrección.
¿Puedo explotar esta vulnerabilidad sin ser usuario del sitio?
Sí. El vector CVSS tiene PR:N (sin privilegios requeridos) y UI:N (sin interacción del usuario). Cualquier persona que pueda acceder al endpoint del formulario en tu sitio puede intentar el ataque. No se necesita cuenta de WordPress de ningún tipo.
¿Cómo detectar si mi sitio fue atacado por CVE-2026-3359?
Revisá los access logs del servidor buscando peticiones POST con caracteres SQL sospechosos (UNION, SELECT, comillas simples) en el body. También podés correr el escáner de Wordfence con análisis de base de datos activado y revisar si hay usuarios administradores desconocidos en wp_users.
¿Tengo que desactivar el plugin mientras lo actualizo?
No es necesario si la actualización va a tardar menos de un minuto. Si tu sitio tiene mucho tráfico y los formularios están bajo uso activo, podés poner el sitio en modo mantenimiento brevemente para evitar envíos durante el update. En la mayoría de los casos, la actualización directa desde el panel es suficiente.
Conclusión
CVE-2026-3359 SQL Injection es el tipo de vulnerabilidad que no da señales de aviso antes de ser explotada. No rompe el sitio, no tira errores visibles; simplemente deja que alguien lea tu base de datos en silencio. Con más de 700.000 instalaciones del plugin y un vector sin autenticación, es un target atractivo para escaneos automatizados.
La solución está disponible. El parche está en el repositorio oficial, el proceso de actualización toma minutos, y el riesgo de no hacerlo supera cualquier miedo a romper algo. Hacé el backup, actualizá, verificá que los formularios funcionan. Si ya tenés Wordfence con reglas actualizadas, corré un escaneo y revisá los logs de las últimas semanas.
Para sitios que manejan datos de clientes o ecommerce, si tenés dudas sobre si la vulnerabilidad fue explotada antes de que actualizaras, el paso conservador es cambiar contraseñas de administrador e invalidar sesiones activas. No es paranoia; es protocolo razonable cuando el vector de ataque es público y no requiere autenticación.