BrunoP.Blog

Un plugin con eval() está secuestrando sitios WordPress: el caso Everest Forms y cómo protegerte

Una falla crítica (CVSS 9.8) en el plugin Everest Forms Pro permite que cualquiera ejecute PHP en tu servidor — y los ataques se dispararon en mayo. El error es de manual: input del usuario entrando directo en un eval(). Te muestro cómo funciona y un checklist de 5 minutos para blindar tu WordPress.

Una vulnerabilidad crítica en el plugin Everest Forms (WordPress, +100 mil instalaciones) permitía a cualquier visitante ejecutar código arbitrario en el servidor a través de un campo de formulario no saneado. La causa es el clásico eval() con input del usuario. Este post analiza el caso y muestra cómo blindar tu WordPress en cinco minutos.

Cada tanto llega a mi bandeja el mismo mensaje, en pánico: "Bruno, mi sitio WordPress está raro — apareció un usuario admin que no soy yo". La raíz casi siempre es la misma: un plugin desactualizado. El caso de esta semana tiene nombre y apellido — y una lección que sirve para cualquiera que tenga un sitio.

¿Qué pasó con el plugin Everest Forms?

Everest Forms Pro, un plugin de formularios con cientos de miles de instalaciones, recibió una falla crítica: la CVE-2026-3300, nota 9.8 de 10. Permite que cualquier visitante, sin login, ejecute código PHP en el servidor — lo que prácticamente entrega el sitio.

El parche salió en marzo (versión 1.9.13; afecta todo hasta la 1.9.12). Aun así, los ataques empezaron el 13 de abril y explotaron: Wordfence registró más de 29.000 intentos bloqueados, con un pico de ~17.900 en un solo día (16 de mayo). La firma del ataque: crear un administrador pirata (apodado diksimarina) y tomar el panel.

¿Por qué usar eval() con input del usuario es tan peligroso?

El complemento de cálculo del plugin toma lo que la persona escribe en un campo del formulario, arma una cadena de PHP y la ejecuta con eval(). El sanitize_text_field() de WordPress "limpia" el texto — pero no escapa las comillas. Así, el atacante cierra la cadena e inyecta su propio código.

// MAL — dato del usuario convertido en código
$expr = sanitize_text_field($_POST['campo']); // no escapa comillas
eval('$total = ' . $expr . ';');
// entrada maliciosa:  1; system($_GET['c']); //
// queda:  $total = 1; system($_GET['c']); //';

El resultado: un campo de formulario inofensivo se vuelve una terminal abierta a todo internet.

¿Por qué este tipo de fallo sigue ocurriendo en 2026?

eval() es el pecado original del PHP: potente, cómodo — y por eso sigue apareciendo en código que corre en miles de sitios. La regla es vieja y simple, y se la repito a cada cliente: el dato del usuario nunca se vuelve código. Ni con eval(), ni con system(), ni concatenado en un SQL.

Cómo lo haría yo (y cómo debería ser)

Para sumar dos números no hace falta un intérprete de código. Se valida la entrada y se calcula con operaciones normales:

// BIEN — valida y calcula, sin ejecutar código del usuario
$n = filter_var($_POST['campo'], FILTER_VALIDATE_FLOAT);
$total = ($n !== false) ? $n * 2 : 0;

Menos "ingenioso", infinitamente más seguro. En la base de datos, la misma lógica: prepared statements (PDO), nunca concatenar. Así escribo PHP — y es el tipo de revisión que hago cuando asumo el mantenimiento de un sistema.

Blinda tu WordPress en 5 minutos

  • Actualiza todos los plugins y activa la actualización automática. Si usas Everest Forms, ve a 1.9.13+ ahora.
  • Elimina plugins y temas que no usas — cada uno es una puerta más.
  • Revisa los administradores (Usuarios > Todos los usuarios): ¿hay alguno que no creaste? Bórralo y cambia todas las contraseñas.
  • Usa un WAF (Wordfence y similares) — bloquea la mayoría de estos intentos automáticamente.
  • Ten copias de seguridad automáticas fuera del servidor, para restaurar rápido si pasa lo peor.

Quiero una auditoría de mi sitio

¿Encontraste un admin extraño, o quieres revisar la seguridad de tu sitio antes de que sea un problema? Es justo el tipo de cosa que resuelvo — hablemos.

Fuentes

The Hacker News · Infosecurity Magazine · SentinelOne (CVE-2026-3300)