Cómo saber si tu plugin de WordPress tiene un CVE activo

En pocas palabras: Instalá WPVulnerability, un plugin gratuito que compara tus plugins con una base abierta de 50.642 vulnerabilidades en 16.833 plugins (dato del 1 de octubre de 2026) y las marca en wp-admin, sin API key ni enviar datos de tu sitio.

Para detectar vulnerabilidades de un plugin de WordPress, instalá WPVulnerability, un plugin gratuito que compara tus plugins con una base abierta de 50.642 vulnerabilidades en 16.833 plugins (dato del 1 de octubre de 2026) y las marca en wp-admin. Sin API key y sin enviar datos de tu sitio.

WPVulnerability es un proyecto abierto, liderado por Javier Casares, que tiene dos piezas: una API de vulnerabilidades de WordPress, gratuita y sin API key, y un plugin que consulta esa API desde tu panel. Cubre el core, los plugins y los temas, y también PHP, Apache, nginx, MariaDB, MySQL, ImageMagick, curl, Memcached, Redis y SQLite.

¿Qué es un CVE y por qué no alcanza con buscarlo en Google?

Un CVE es un identificador público y único, con formato CVE-AÑO-NÚMERO, que se asigna a una vulnerabilidad de seguridad conocida. Buscarlo en Google no alcanza porque, según Javier Casares en WordPress Málaga, los CVE publican la información, pero no de una forma que sirva para saber de manera automática si tu WordPress concreto es vulnerable.

Ponele que un cliente te escribe: «leí que el plugin de formularios tiene un CVE, ¿estamos en riesgo?» (ejemplo hipotético, pero seguro te tocó algo parecido). Abrís el CVE y encontrás un párrafo técnico que habla de versiones hasta cierto número. Ahora te toca averiguar qué versión corre en cada sitio, si ya salió una corregida y si el plugin sigue vivo en el repositorio. Con diez sitios, eso es una tarde.

Casares cuenta que en abril de 2022 empezó a preguntarse si la información de vulnerabilidades de WordPress no se estaba privatizando, y de esa duda salió WPVulnerability. Un matiz que cambia todo: un CVE puede afectar solo a ciertas versiones del plugin. Si tenés una posterior a la corregida, el CVE existe pero a vos no te toca.

Falta el plazo. Según esa misma nota, las vulnerabilidades suelen tener unos 3 meses para corregirse antes de anunciarse. ¿Y si el desarrollador no la corrige? Queda una vulnerabilidad pública, sin parche, que puede afectar a miles de sitios.

¿Qué es WPVulnerability y de dónde saca los datos?

WPVulnerability es una API de vulnerabilidades de WordPress, abierta y gratuita, con un lema claro: «Democratizing WordPress security information». Según la ficha del plugin en wordpress.org, la información sale de distintas fuentes, entre ellas los CVE, y el proyecto la reúne en un solo lugar para que la consultes por componente.

Las cifras, con fecha: según las estadísticas del sitio oficial al 1 de octubre de 2026, la base tiene 50.642 vulnerabilidades en 16.833 plugins y 4.219 en 2.334 temas. En infraestructura aparecen MySQL con 1.649, ImageMagick con 772 y PHP con 734.

Para ubicar el crecimiento: la nota de WordPress Málaga (no pude confirmar su fecha de publicación, así que tomala como una cifra anterior a las actuales) hablaba de casi 9.000 plugins con 28.000 vulnerabilidades y cerca de 1.000 temas con 2.000. Las formas de contar pueden no ser idénticas, pero el orden de magnitud creció más de un 80%.

Ojo con la cifra: la publica el propio proyecto y no encontré una verificación independiente de cuánta cobertura tiene. ¿Eso la invalida? No, pero tomala como el tamaño de la base y no como el total de problemas que existen en el ecosistema.

Un cambio que vale mirar: según las novedades del sitio oficial del proyecto, WPVulnerability sumó datos de ataques a la cadena de suministro con un modelo llamado SupplyChainEntry, que cubre secuestros de plugins por cambio de dueño y abuso del canal de actualizaciones, incidentes que caen fuera del molde tradicional de la vulnerabilidad con CVE. Las fuentes no precisan la fecha exacta de esa incorporación. Relacionado: configurar la autenticación en dos pasos.

¿Cómo verificar vulnerabilidades de un plugin de WordPress desde el panel?

Instalá WPVulnerability desde Plugins > Añadir nuevo, activalo y mirá tres lugares: la lista de plugins, Site Health y el widget del escritorio. La ficha de wordpress.org muestra capturas de esas tres vistas y aclara que el reporte cubre core, plugins, temas, PHP y software de servidor, sin pedirte configuración previa.

1. Instalalo. En el panel, buscá «wpvulnerability» en Plugins > Añadir nuevo. Si preferís la vía manual, subí el contenido del ZIP a /wp-content/plugins/wpvulnerability/.
2. Revisá la lista de plugins. Las vulnerabilidades aparecen en cada fila afectada. Casares menciona también una columna que indica si el plugin está cerrado o cuándo se actualizó por última vez, así que fijate si la ves en tu versión.
3. Abrí Site Health. En Herramientas > Salud del sitio aparece el mismo listado, útil si el cliente mira esa pantalla y no la de plugins.
4. Configurá los avisos. Según la ficha, el período de notificación puede ser never, daily o weekly, y los destinatarios van separados por coma.
5. Ajustá el caché si hace falta. Por defecto los datos de la API se guardan 12 horas, así que un aviso nuevo puede tardar en aparecer. Podés bajarlo a 1, 6 o 24 horas.

Requisitos: la versión 5.1.6, del 22 de agosto de 2026, declara compatibilidad con WordPress 4.7 a 7.1 y PHP 7.0 a 8.5 según su changelog. Si tu sitio viejo corre PHP 5.6, queda fuera de lo declarado (y justo esos sitios suelen ser los que más necesitan el chequeo).

Privacidad: el plugin declara que no recopila información de tu sitio, de tu identidad ni de tus plugins, temas o contenido. Casares explica que la información de vulnerabilidades se guarda en local y que la CDN anonimiza las consultas, sin ver siquiera la IP.

Si tu política de seguridad no quiere comandos de shell, el plugin detecta ImageMagick, Redis, Memcached y SQLite primero con extensiones PHP y usa shell como respaldo. En wp-config.php podés poner el modo estricto (solo extensiones PHP, menos precisión) o desactivar la detección por completo:

define( 'WPVULNERABILITY_SECURITY_MODE', 'strict' );
define( 'WPVULNERABILITY_DISABLE_SHELL_EXEC', true );

Dos advertencias honestas. Una de las 19 reseñas en wordpress.org cuenta que el mail «automático» no le llegó aunque el de prueba sí; es un solo caso, pero si dependés de los avisos, probalos y no dejes de mirar el panel. Y una ironía útil: el propio plugin tuvo una vulnerabilidad, corregida en la 4.2.2.1, que afectaba a las versiones 3.3.0 a 4.2.1. Si lo instalaste hace tiempo y nunca actualizaste, empezá por ahí.

¿Cómo consultar la API de WPVulnerability por el slug de un plugin?

El slug es el nombre del plugin en su URL de wordpress.org (wordpress.org/plugins/{slug}/) y también el nombre de su carpeta dentro de wp-content/plugins. Con ese slug consultás la API de WPVulnerability, que devuelve JSON y no pide API key, sin instalar nada en tu sitio.

La ruta por slug tendría la forma /plugin/{slug}, pero no pude contrastarla contra docs.wpvulnerability.com al escribir esto. Verificá ahí la ruta exacta y los nombres de los campos antes de copiar nada a un script. Una pista de que la ruta plural no es la correcta: el changelog de la 5.1.6 corrigió pruebas que apuntaban a rutas plurales inexistentes y devolvían HTTP 404.

Qué buscar en la respuesta (esto es lo que se espera de una entrada de vulnerabilidad, no un formato confirmado):

• Identificador: el CVE u otro ID de la fuente.
• Versiones afectadas: el rango donde existe el problema y, si figura, desde qué versión se corrigió.
• Gravedad: el puntaje CVSS, cuando la entrada lo trae.
• Referencias: los enlaces a las fuentes originales.

Si parseás la respuesta con un script, revisá las novedades de la API: el proyecto anunció una actualización de los datos de impacto con bloques estructurados nuevos y la baja del formato anterior. Un script armado contra el formato viejo puede romperse. Sobre eso hablamos en reforzar la seguridad de tus formularios.

Con el plugin ya instalado tenés dos vías más, ambas documentadas en su ficha. WP-CLI da la salida en tabla o en JSON:

wp wpvulnerability plugins
wp wpvulnerability plugins --format=json

Y el endpoint REST del plugin, que usa Application Passwords en el encabezado de autorización:

curl -X GET https://example.com/wp-json/wpvulnerability/v1/plugins -u username:application_password

¿Qué método conviene para chequear un plugin: panel, WP-CLI, REST o API directa?

Si no tocás la terminal, usá el plugin en wp-admin. Si administrás varios sitios, WP-CLI o REST. Si querés revisar un plugin antes de instalarlo, la API por slug. La tabla resume lo que documentan las fuentes; la columna de nivel técnico es mi estimación.

Un ejemplo hipotético: una agencia con 15 sitios podría correr WP-CLI con salida JSON en cada uno y juntar los resultados en una planilla, mientras que el cliente final se queda con el email semanal. Sirve para armar un proceso, no para reemplazar el criterio de quien lo revisa.

¿Cómo sé si mi versión del plugin está afectada y qué hago?

Compará la versión instalada (Plugins > Plugins instalados, o wp plugin list) con el rango afectado. Si tu versión cae adentro y existe una corregida, actualizá. Si el rango no incluye tu versión, ese CVE no te afecta. Si cae adentro y no hay parche, desactivá o reemplazá el plugin.

Distinguí dos frases que parecen iguales: «afectada hasta la versión X» y «corregida en la versión X». Con la primera, la X todavía es vulnerable. Con la segunda, ya no.

Cuando hay parche, el orden es backup, staging, actualización y prueba de lo crítico (formularios, checkout, login). Insisto con esto porque el escenario típico es este: instalás el plugin, aparece un aviso rojo, actualizás sin mirar, el sitio del cliente deja de mostrar el formulario de contacto porque la nueva versión cambió un shortcode, nadie tenía un backup reciente y terminás restaurando a mano un sábado a la noche. En qué es un feature plugin gratuito profundizamos sobre esto.

El FAQ del plugin arranca con un consejo sensato: calma, investigá qué es la vulnerabilidad y confirmá que tenés la última versión.

Sin parche, las opciones son pocas. Casares recomendaba reemplazar el plugin por otro con las mismas funciones. Si no podés, desactivalo hasta que haya corrección. Como criterio general (no sale de las fuentes), restringí quién puede usar la función afectada mientras decidís.

Para priorizar mirá el puntaje CVSS: de 0 a 10, y por convención 9.0 a 10 es crítica, 7.0 a 8.9 alta, 4.0 a 6.9 media y 0.1 a 3.9 baja. Una crítica sin parche en un plugin que corre en la home pesa más que una media en uno que usás para un widget perdido.

Un plugin cerrado o abandonado casi nunca va a recibir parche. Ahí no hay que esperar: reemplazalo.

Y si el CVE es de PHP, MySQL o nginx, no lo arreglás desde WordPress. El FAQ del plugin recomienda contactar a tu proveedor de hosting.

¿Si un plugin no figura en la base de vulnerabilidades, significa que es seguro?

No. Una base de datos solo registra lo que ya se reportó, así que un plugin sin entradas puede estar limpio o simplemente no haber sido auditado. La documentación del plugin aclara que no hay responsabilidad de ningún tipo por la información y que la usás bajo tu propio riesgo.

Existen otras bases, como Patchstack, WPScan y Wordfence Intelligence. No las comparo acá porque las fuentes de esta nota no traen datos de ellas. Si tu sitio es crítico, cruzar más de una fuente es razonable. Ya lo cubrimos antes en recibir alertas automáticas de vulnerabilidades.

Tampoco confundas un chequeo de versiones con un escaneo de infecciones. Nada en la documentación de WPVulnerability indica que revise archivos o detecte malware, así que un plugin con CVE no prueba que te hayan hackeado, ni la ausencia de avisos prueba lo contrario.

Complementá con actualizaciones al día, backups, roles con los permisos mínimos y plugins con mantenimiento activo. El hosting cuenta: como dice Casares, «tener un hosting inseguro hace que tu WordPress también lo sea, aunque tengas todo al día». Un proveedor con soporte y backups (por ejemplo donweb.com) no evita que un plugin tenga un CVE, pero achica el daño y te deja a alguien a quien llamar cuando el problema está en el servidor.

¿Qué está confirmado y qué falta verificar sobre WPVulnerability?

Confirmado según las fuentes oficiales:

• Acceso: la API es abierta, gratuita, devuelve JSON y no requiere API key.
• Cifras: 50.642 vulnerabilidades en 16.833 plugins y 4.219 en 2.334 temas al 1 de octubre de 2026.
• Plugin: versión 5.1.6 del 22 de agosto de 2026, con WordPress 4.7 a 7.1 y PHP 7.0 a 8.5.
• Herramientas: comandos WP-CLI, endpoints REST con Application Passwords y avisos por email.

No verificado o sin dato en las fuentes:

• Ruta y campos de la API: no los contrasté contra la documentación.
• Cobertura real: no hay una medición independiente de qué porcentaje de las vulnerabilidades existentes está en la base.
• Frecuencia de actualización de la base: las fuentes no la precisan.
• Fechas de publicación de la nota de WordPress Málaga y de la incorporación de SupplyChainEntry: las fuentes no las precisan.
• Pruebas propias: esta nota resume documentación pública, no un test mío del plugin en un sitio real.

Errores comunes al verificar vulnerabilidades de plugins

• Buscar por el nombre comercial y no por el slug. Dos plugins pueden tener nombres parecidos. Tomá el slug de la URL de wordpress.org o de la carpeta en wp-content/plugins.
• Leer el CVE y no el rango de versiones. Entrar en pánico por un CVE que afecta versiones que ni tenés es perder el tiempo, y ignorar uno que sí te toca es peor.
• Actualizar en producción sin backup. Ya viste el escenario del sábado a la noche. Backup primero, staging si podés.
• Dejar el aviso en never y no mirar el panel. Sin email y sin revisión manual, la herramienta no sirve de nada.
• Tomar la ausencia de resultados como certificado. La base registra lo reportado, no lo que nadie encontró todavía.

Preguntas Frecuentes

¿Cómo sé si un plugin de WordPress tiene una vulnerabilidad?

Instalá el plugin WPVulnerability: marca las vulnerabilidades conocidas en tu lista de plugins, en Site Health y en el widget del escritorio. Si querés chequear un plugin sin instalar nada, consultá la API de WPVulnerability con su slug.

¿Dónde puedo buscar el CVE de un plugin de WordPress?

En la API de WPVulnerability, que reúne CVE y otras fuentes y se consulta por slug, o desde el reporte del plugin en tu panel. Buscar el CVE suelto te da el texto técnico, pero no te dice si tu versión está afectada.

¿Es gratis WPVulnerability y necesita una API key?

Es gratis y la API no necesita API key, según el sitio oficial del proyecto. Si sos una empresa grande o tus usuarios van a consultarla de forma intensiva, el proyecto pide que la uses con criterio y que hagas una donación.

¿Qué hago si mi plugin tiene una vulnerabilidad y todavía no tiene parche?

Reemplazalo por otro plugin con la misma función, que es lo que recomienda Casares, o desactivalo hasta que salga la corrección. Mientras decidís, limitá quién puede usar la función afectada y tené un backup reciente a mano.

¿Cómo veo las vulnerabilidades de mis plugins desde el panel de WordPress?

Con WPVulnerability activo, entrá a Plugins > Plugins instalados y vas a ver las vulnerabilidades en cada plugin afectado. También aparecen en Herramientas > Salud del sitio y en el widget del escritorio.

Conclusión

Saber si tu plugin tiene un CVE activo dejó de ser una tarea manual. Con WPVulnerability, que al 1 de octubre de 2026 tenía 50.642 vulnerabilidades en 16.833 plugins, instalás un plugin gratuito y ves el estado en tu propio panel, o consultás la API por slug sin API key.

Lo que tenés que hacer hoy: instalar el plugin, activar el aviso semanal, anotar la versión de cada plugin crítico y comparar con el rango afectado cuando salte un aviso. Con parche, backup y actualización. Sin parche, reemplazo. Y no confundas silencio con seguridad, porque la base registra lo reportado y nada más.

Fuentes

• WPVulnerability – sitio oficial con la API, estadísticas y novedades del proyecto
• WPVulnerability Docs – documentación de la API
• WPVulnerability en wordpress.org – ficha, comandos WP-CLI, endpoints REST y changelog
• WordPress Málaga – por qué WordPress necesita una base de datos de vulnerabilidades, por Javier Casares