En pocas palabras: Un plugin abandonado deja de recibir parches, aunque siga activo en tu sitio. Cruzalo contra bases como WPVulnerability o Patchstack: si tiene un CVE sin fix, removelo ya. En 2025 el 46% de las 11.334 vulnerabilidades de WordPress no tenía parche al divulgarse.
El 46% de las vulnerabilidades divulgadas en el ecosistema WordPress durante 2025 no tenía parche disponible al momento de hacerse públicas, según el informe State of WordPress Security in 2026 de Patchstack. Auditar plugins abandonados de WordPress es la única forma de detectar ese riesgo antes de que un bot lo explote.
Un plugin abandonado es un complemento de WordPress que dejó de recibir actualizaciones de su desarrollador original, aunque siga instalado y activo en el sitio. Auditar plugins abandonados vulnerables en WordPress significa cruzar cada complemento contra bases de datos como WPVulnerability o Patchstack para detectar un CVE sin parche antes de que alguien lo aproveche.
En este artículo:
- En 30 segundos
- ¿Qué es un plugin abandonado en WordPress y cómo se identifica?
- ¿Por qué los plugins abandonados son el mayor riesgo de seguridad en WordPress?
- ¿Qué es un CVE y cómo se aplica a los plugins de WordPress?
- ¿Cómo auditar plugins abandonados vulnerables en WordPress con la API de WPVulnerability?
- ¿Qué hacer cuando un plugin abandonado tiene una vulnerabilidad activa sin parche?
- ¿Qué otras herramientas complementan la auditoría de plugins vulnerables?
- ¿Cómo prevenir que un plugin abandonado comprometa tu sitio a futuro?
- Errores comunes al auditar plugins abandonados
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- Patchstack registró 11.334 vulnerabilidades nuevas en WordPress durante 2025, un salto del 42% frente a las 7.966 de 2024.
- El 91% de esas fallas apareció en plugins, apenas 9% en temas y solo 6 casos de baja severidad en el core.
- El 46% de las vulnerabilidades de 2025 no tenía parche al momento de divulgarse, contra 33% el año anterior.
- La API gratuita de WPVulnerability suma 49.441 vulnerabilidades en 16.684 plugins, sin necesidad de API key, al 1 de septiembre de 2026.
- El tiempo mediano entre la divulgación de un CVE y el primer intento de explotación es de 5 horas, según Patchstack.
¿Qué es un plugin abandonado en WordPress y cómo se identifica?
Un plugin se considera abandonado cuando pasaron más de 12 meses sin una actualización registrada en el repositorio oficial. Pasados los 2 años sin novedades, según el criterio que describe este análisis de auditoría de software deprecado, el riesgo pasa directamente a la categoría alta.
Las señales concretas son estas:
- Fecha de «última actualización» vencida. Se ve en la ficha del plugin en el directorio de WordPress.org.
- Aviso de incompatibilidad. El mensaje «no se ha probado con tu versión actual de WordPress» indica que el autor dejó de validar contra el core nuevo.
- Silencio en el foro de soporte. Tickets abiertos sin respuesta durante meses son un indicador tan confiable como la fecha de update.
- Banner de cierre. WordPress.org cierra plugins por fallas de seguridad sin parchear o por pedido del propio desarrollador.
Ojo con algo que casi nadie chequea: wp-admin no avisa cuando un plugin fue cerrado del repositorio. Si no hay una versión nueva publicada, el panel sigue mostrando «actualizado» aunque el complemento ya no exista para descarga. La única excepción documentada fue el banner manual que WordPress.org empujó durante el incidente de Essential Plugin en abril de 2026, y fue una respuesta puntual, no una función que podés dar por garantizada.
¿Por qué los plugins abandonados son el mayor riesgo de seguridad en WordPress?
Porque concentran la mayoría de las vulnerabilidades y porque nadie las va a parchear. El 91% de las 11.334 fallas divulgadas en 2025 apareció en plugins, según Patchstack, y casi la mitad de esas fallas salió a la luz sin fix disponible.
El problema no es solo el CVE en sí. Es la ventana de tiempo. Patchstack mide un tiempo mediano de 5 horas entre la publicación de una vulnerabilidad y el primer intento de explotación: el 20% de las fallas más buscadas se explota dentro de las 6 horas, el 45% dentro de las 24 horas y el 70% dentro de los siete días. Si el plugin está abandonado, esa ventana no se cierra nunca, porque no hay parche que la cierre.
¿Y si confiás en que el hosting te cubre? No del todo. En pruebas de pentesting que Patchstack corrió sobre entornos de hosting reales durante 2025, los stacks tradicionales de WAF bloquearon apenas el 12% de los ataques contra vulnerabilidades conocidas en una prueba acotada, y 26% en una más amplia, con el mejor proveedor llegando a 61% y al menos uno bloqueando cero. Ya lo cubrimos antes en activar 2FA en tus plugins de WordPress.
El caso más claro de todo esto pasó en abril de 2026. A comienzos de 2025, un comprador adquirió el portfolio «Essential Plugin» (más de 30 plugins con una década de historial y más de 400.000 instalaciones combinadas) a través del marketplace Flippa, presuntamente por una suma de seis cifras. El primer commit del nuevo dueño plantó un backdoor de deserialización PHP. Quedó dormido ocho meses (sí, en serio, ocho meses) hasta que el 5 y 6 de abril de 2026 se activó, descargó un archivo disfrazado de core de WordPress e inyectó código malicioso directo en wp-config.php, uno de los archivos más sensibles de cualquier instalación. El atacante sirvió spam SEO camuflado a Googlebot mientras los dueños de los sitios no veían nada raro. WordPress.org cerró los 31 plugins de esa cuenta el 7 de abril de 2026 y empujó un update forzado, pero ese parche cortó el mecanismo de comunicación del backdoor sin eliminar el código malicioso ya instalado. Investigadores de seguridad estimaron más de 20.000 instalaciones comprometidas. La misma semana apareció un segundo compromiso de cadena de suministro, en Smart Slider 3 Pro, con más de 800.000 instalaciones activas.
¿Qué es un CVE y cómo se aplica a los plugins de WordPress?
Un CVE (Common Vulnerabilities and Exposures) es un identificador único que se asigna a una vulnerabilidad de software conocida y documentada públicamente. Cada CVE lleva además un puntaje CVSS de severidad, de 0 a 10, donde 9.0 o más se considera crítico.
Cuando un investigador encuentra una falla en un plugin específico, la reporta, se le asigna un CVE con su CVSS correspondiente y queda registrada en bases como el NVD, WPScan o WPVulnerability. El problema aparece cuando ese CVE se publica y el desarrollador del plugin ya no existe, ya no responde, o directamente vendió el proyecto sin avisar. Ahí el CVE queda flotando, visible para cualquiera, sin fix a la vista.
¿Cómo auditar plugins abandonados vulnerables en WordPress con la API de WPVulnerability?
Se hace consultando la API abierta de WPVulnerability por el slug de cada plugin instalado, sin necesidad de API key, y comparando el resultado con lo que tenés corriendo en producción. La API devuelve el CVE, el puntaje CVSS y la versión donde se corrigió la falla, si es que existe alguna.
El proyecto lo mantiene un grupo de contribuidores encabezado por Javier Casares, y la base de datos escaló bastante: al 1 de septiembre de 2026 acumula 49.441 vulnerabilidades registradas sobre 16.684 plugins y 4.197 sobre 2.331 temas. También cubre software de infraestructura (PHP, Apache, nginx, MySQL, MariaDB, ImageMagick, entre otros), lo cual sirve si además administrás el servidor y no solo el WordPress.
La lógica práctica es esta: exportás la lista de slugs de plugins activos del sitio, armás un script simple que pegue cada slug contra el endpoint de plugins de la API, y filtrás los resultados que traigan un CVE sin «fixed version». Esos son los candidatos a revisión inmediata. Es la misma lógica que describe el SOP de auditoría trimestral de software abandonado: repositorio, fecha de update, base de vulnerabilidades y registro de hallazgos, en ese orden.
¿Qué hacer cuando un plugin abandonado tiene una vulnerabilidad activa sin parche?
Si el CVE es crítico y no hay parche, la acción es eliminar el plugin, no solo desactivarlo. Desactivar deja el código en el servidor y varias técnicas de explotación (LFI, deserialización, acceso directo a archivos) no necesitan que el plugin esté activo para funcionar. Más contexto en tener backups a prueba de ransomware.
| Nivel de riesgo | Señal detectada | Acción recomendada |
|---|---|---|
| Bajo | Actualizado hace menos de 6 meses, sin CVE abierto | Mantener, revisar en la próxima auditoría trimestral |
| Medio | Sin actualizar entre 12 y 24 meses, o aviso de incompatibilidad con la versión actual | Poner en lista de seguimiento, empezar a buscar alternativa |
| Alto | Sin actualizar hace más de 2 años, o cerrado en el repositorio oficial | Desactivar y eliminar, migrar la funcionalidad |
| Crítico | CVE activo sin parche, exploit público conocido | Eliminar de inmediato, aislar con reglas de WAF si la migración no es inmediata |
Si el plugin es imprescindible y todavía no encontraste reemplazo, la única salida temporal es aislar la funcionalidad con reglas específicas de firewall a nivel de aplicación mientras armás la migración. Tomalo como parche de emergencia, no como solución.
¿Qué otras herramientas complementan la auditoría de plugins vulnerables?
WPScan es el complemento lógico de WPVulnerability: es un scanner que cruza tu instalación contra su propia base de vulnerabilidades de WordPress y detecta versiones desactualizadas en tiempo real. Ninguna de las dos herramientas reemplaza el hardening general del sitio (2FA, roles bien definidos, mínimo de usuarios admin).
Hay un punto ciego que casi nadie audita: el software premium comprado fuera del repositorio oficial, en marketplaces como Envato o directo con la agencia que lo desarrolló. Patchstack registró 1.983 reportes válidos de vulnerabilidades en componentes premium y freemium durante su investigación de 2026, el 29% de todos los reportes del año. De esos, 59% fue de prioridad alta (explotable en ataques automatizados masivos) y otro 17% de prioridad media, lo que deja un 76% realmente explotable. «Pago» no es sinónimo de «auditado»: el código premium recibe menos revisión independiente simplemente porque los investigadores tienen menos acceso a él.
Sobre el hosting: como vimos, un WAF genérico bloquea poco frente a exploits conocidos. Si estás por migrar un sitio con historial de plugins abandonados, priorizá un proveedor que tenga protección real a nivel de infraestructura y soporte que entienda WordPress, como los planes gestionados de donweb.com. Pero eso no reemplaza la auditoría: es una capa más, no la única.
¿Cómo prevenir que un plugin abandonado comprometa tu sitio a futuro?
Con una auditoría trimestral fija, no esporádica. Fijate esto: agencia que audita «cuando se acuerda» es agencia que se entera del problema por el cliente, no antes. Sobre eso hablamos en configurar la autenticación en dos pasos.
La rutina que funciona tiene cuatro pasos: revisar estado del repositorio, chequear fecha de última actualización y compatibilidad con el core, cruzar contra bases de vulnerabilidades como WPVulnerability o WPScan, y registrar los hallazgos con fecha de próxima revisión. Sumale un criterio simple: cuantos menos plugins instalados, menos superficie de ataque. Antes de sumar un complemento nuevo, fijate cuántos años de historial de commits tiene y si el autor sigue activo en el foro de soporte.
Hay un dato regulatorio que le cambia el peso a todo esto desde este mes. Bajo la Cyber Resilience Act de la Unión Europea, los fabricantes de «productos con elementos digitales» (una categoría que incluye software open source comercial como plugins y temas) tienen que reportar vulnerabilidades activamente explotadas a ENISA y al CSIRT nacional dentro de las 24 horas de tomar conocimiento. Esa obligación, bajo el Artículo 14 de la CRA, entró en vigencia el 11 de septiembre de 2026. No cambia lo que tenés que hacer día a día, pero sí sirve como termómetro: un autor de plugin que ya dejó de responder tickets de soporte difícilmente vaya a cumplir con reportes de este tipo tampoco.
Errores comunes al auditar plugins abandonados
- Desactivar en vez de eliminar. El código sigue en el servidor y varias técnicas de explotación no necesitan que el plugin esté activo.
- Confiar en que wp-admin te va a avisar. Un plugin cerrado en el repositorio sigue mostrando «actualizado» porque no hay versión nueva que marcar como pendiente.
- Asumir que «premium» significa «seguro». El 76% de las vulnerabilidades reportadas en componentes premium en 2026 es realmente explotable, según Patchstack, y reciben menos auditoría independiente que el código gratuito del repositorio.
- Dejar la seguridad entera en manos del hosting. Los WAF genéricos bloquearon apenas entre 12% y 26% de los ataques contra vulnerabilidades conocidas en las pruebas de Patchstack de 2025.
Preguntas Frecuentes
¿Cómo sé si un plugin de WordPress dejó de recibir actualizaciones?
Revisá la fecha de «última actualización» en la ficha del plugin dentro del directorio oficial de WordPress.org. Si pasaron más de 12 meses es señal de alerta, y si pasaron más de 2 años se considera alto riesgo de abandono.
¿Qué es un CVE y cómo afecta a mi sitio WordPress?
Un CVE es un identificador único asignado a una vulnerabilidad de software documentada públicamente, con un puntaje CVSS de severidad de 0 a 10. Si el plugin afectado está abandonado, ese CVE queda expuesto de forma indefinida porque nadie va a publicar un parche. Cubrimos ese tema en detalle en reforzar las cabeceras HTTP de seguridad.
¿Cómo reviso si mis plugins instalados tienen vulnerabilidades conocidas?
Cruzás el slug de cada plugin activo contra la API gratuita de WPVulnerability o contra WPScan, ambas sin costo y sin necesidad de API key en el caso de WPVulnerability. El resultado te muestra el CVE, el CVSS y si existe una versión con la falla corregida.
¿Qué hago si el plugin vulnerable no tiene reemplazo?
Aislás la funcionalidad afectada con reglas específicas de firewall a nivel de aplicación mientras evaluás una migración a código propio o a un plugin equivalente mantenido. Es una solución temporal, no un reemplazo del parche.
¿Es seguro solo desactivar un plugin abandonado en vez de eliminarlo?
No. Desactivar deja los archivos del plugin en el servidor, y varias técnicas de explotación (acceso directo a archivos, deserialización) no requieren que el plugin esté activo para funcionar. La acción correcta es eliminarlo por completo.
Conclusión
El número que resume todo esto es el 46%: casi la mitad de las vulnerabilidades divulgadas en WordPress durante 2025 salió sin parche disponible, y el caso de Essential Plugin mostró que ni siquiera hace falta una falla técnica nueva, alcanza con que alguien compre un plugin popular y espere ocho meses. La respuesta no es un plugin de seguridad más. Es una rutina: auditoría trimestral, cruce contra WPVulnerability o WPScan, y el criterio simple de eliminar en vez de desactivar cuando aparece un CVE crítico sin parche. Arrancá hoy por los plugins que no tocaste en el último año, esos son los candidatos más probables.