Fallo en el popular plugin Pods permitió a cualquier persona cambiar la contraseña de administrador en 100.000 sitios WordPress

Se podía cambiar la contraseña de un administrador de un sitio WordPress sin iniciar sesión. Una vulnerabilidad crítica en el popular plugin Pods permitía a un usuario no autorizado eludir varios niveles de verificación y acceder a funciones administrativas. Según Wordfence, en el peor de los casos el atacante podía tomar el control total del sitio.

Pods ayuda a los propietarios de WordPress a crear tipos de contenido personalizados, campos y taxonomías, así como a relacionar distintas entradas entre sí. El plugin cuenta con más de 100 000 instalaciones activas. El problema afecta a las ramas de Pods desde la 2.8 hasta la 3.3.9 inclusive.

La vulnerabilidad recibió el identificador CVE-2026-19598 (9,8). Para explotarla, el atacante no necesita una cuenta, acceso previo al sitio ni interacción por parte del administrador. El ataque puede realizarse de forma remota a través de la red, por lo que se clasificó como de nivel crítico.

El problema residía en el enrutador AJAX pods_admin, a través del cual el plugin accede a funciones administrativas internas. Antes de ejecutar una petición, Pods debe comprobar el método permitido, la presencia de autorización, el código de protección de un solo uso y los permisos del usuario. Si cualquiera de las comprobaciones fallaba, el programa llamaba a la función pods_error(), que debía interrumpir el procesamiento de la solicitud.

Cuando se procesaba JSON en uno de los modos, la función se comportaba de forma diferente. En lugar de detenerse de inmediato, pods_error() registraba un mensaje en el registro de PHP y devolvía el valor false. El código del enrutador no tenía en cuenta el resultado devuelto y continuaba ejecutándose. Como resultado, la petición continuaba adelante incluso después de que la comprobación de inicio de sesión, del código de protección o de permisos no se superara.

Especialistas de Wordfence demostraron que tal fallo daba acceso a métodos internos de Pods. A través de la función que guarda al usuario, el atacante podía indicar una cuenta existente y reemplazar su contraseña. Al elegir al administrador del sitio, el atacante obtenía de forma efectiva el control total de WordPress. El error no solo afectaba la gestión de usuarios. Al eludir las comprobaciones de seguridad, el atacante también podía realizar otras operaciones administrativas: modificar archivos, borrar datos y ejecutar acciones que podrían llevar a la ejecución de código PHP.

El especialista en seguridad Nien Pham descubrió la vulnerabilidad y el 10 de agosto entregó la información a través del programa de recompensas de Wordfence. La empresa confirmó el problema el 12 de agosto y el mismo día lo comunicó a los desarrolladores de Pods. Por el hallazgo el autor recibió $3900. El 14 de agosto el equipo del proyecto ya publicó las compilaciones corregidas.

Los desarrolladores indicaron en la actualización oficial que en 36 horas revisaron adicionalmente varias porciones de código relacionadas y solucionaron otros problemas potenciales. En la versión 3.3.9.1 introdujeron 16 cambios orientados a reforzar la seguridad. Para las ramas antiguas prepararon correcciones retroactivas con 13 cambios principales.

Se consideran seguras las versiones Pods 3.3.9.1, 3.2.8.3, 3.1.4.2, 3.0.10.4, 2.9.19.4 y 2.8.23.4. Los desarrolladores de Pods y el equipo de WordPress.org forzaron que las instalaciones vulnerables se actualizaran obligatoriamente a la versión corregida de la rama correspondiente. Este enfoque debería reducir el número de sitios no protegidos; sin embargo, se recomienda a los administradores que comprueben por sí mismos la versión instalada, ya que la actualización automática podría no haberse aplicado en todos los sistemas.

El peligro ya ha trascendido el escenario teórico. La página de Wordfence informa sobre 28 540 intentos bloqueados de explotar CVE-2026-19598 en las últimas 24 horas. A los propietarios de sitios con Pods les conviene comprobar la versión del plugin lo antes posible, incluso si WordPress informó previamente que la actualización automática se realizó.