La mitad del directorio de plugins está abandonada

#Introducción

Medimos el directorio de plugins de WordPress.org el 10 de agosto de 2026. De 69 286 plugins, 35 696 no recibían actualización desde hacía al menos dos años, es decir el 51,5 por ciento. Esa cifra no está copiada del informe de nadie, porque tal informe no existe. A continuación, el método, los resultados en cuatro umbrales y lo que se deduce de ellos para quien mantiene sitios ajenos.

#En resumen

• 35 696 de 69 286 plugins sin actualización desde hace dos años, el 51,5 por ciento del directorio.
• 28 146, el 40,6 por ciento, sin actualización desde hace cinco años.
• 20 242, el 29,2 por ciento, sin actualización desde hace ocho años.
• En una muestra de 5250 plugins abandonados, el 5,9 por ciento tiene mil o más instalaciones activas, lo que da unos 2100 en toda la cola.
• Las cifras que circulan, 43,8 por ciento y 59 por ciento, no tienen fuente primaria. Comprobé ambas. La verdad queda entre ellas.
• El método está documentado y se repite con un comando, porque una cifra que no puedes verificar vale exactamente lo mismo que aquellas dos.

#Por qué medí, en realidad

Iba a escribir un texto apoyado en la cifra del 43,8 por ciento de plugins abandonados. Antes de usarla, busqué la fuente. No existe.

Busqué una alternativa y encontré el 59 por ciento, repetido en muchos sitios junto a una cifra de unos 34 000 plugins. Parece más sólido porque viene con un número absoluto. Leí el texto que lo introduce y allí tampoco hay atribución. El autor cita a WordPress.org y a WPExperts, pero para el total de plugins, y para el porcentaje de abandonados no aporta nada.

Este es el ciclo de vida habitual de una estadística en este sector. Alguien publica una cifra sin fuente, el siguiente cita al primero con un enlace, un tercero cita al segundo, y un año después se lee como conocimiento común. Entre nosotros rige una regla desde el 31 de julio de 2026, después de retirar de nuestro propio sitio todas las cifras que no podíamos sostener. Publicar aquel número la habría roto de forma directa.

Quedaba un camino honesto: contar.

#El método, para que se pueda repetir

WordPress.org ofrece una API pública del directorio en api.wordpress.org/plugins/info/1.2/. El modo browse=updated devuelve los plugins ordenados por fecha de última actualización, del más reciente al más antiguo.

Como la lista está ordenada, la respuesta a cuántos plugins son más antiguos que dos años es simplemente la posición del primer plugin anterior al umbral. Encontrarla no exige descargar el directorio entero, basta una búsqueda binaria por las páginas. Nueve peticiones en lugar de setecientas.

Toda la medición está en nuestro repositorio como npm run measure:plugin-abandonment y repetirla lleva menos de un minuto. Si lees esto dentro de seis meses y las cifras se ven distintas, no es porque alguno de los dos se equivoque. Es porque el directorio está vivo.

#Resultados en cuatro umbrales

El directorio tenía 69 286 plugins en el momento de la medición, y la actualización más reciente tenía minutos.

Lo interesante es la forma de esta distribución, no una cifra aislada. Entre el umbral de dos y el de ocho años solo desaparecen unos 15 000 plugins, así que la mayoría de los plugins abandonados no se abandonaron hace poco. Casi tres décimas partes de todo el directorio son código que nadie ha tocado en ocho años: antes de Gutenberg, antes de PHP 7.2, antes de los bloques.

#La cifra que importa en la práctica

El porcentaje de plugins abandonados es en sí mismo una curiosidad. El directorio puede contener cualquier cantidad de código muerto sin dañar a nadie, mientras nadie lo use.

Por eso medí una segunda cosa: cuántos de esos plugins abandonados siguen funcionando en sitios. Tomé una muestra sistemática de la cola del directorio, cada séptima página de resultados, 5250 plugins, y conté las instalaciones activas.

Trasladar el 5,9 por ciento a toda la cola da unos 2100 plugins que no reciben actualización desde hace dos años y aun así funcionan en mil sitios o más cada uno.

Esa es la cifra que conviene recordar en vez del porcentaje. Dos mil piezas de código, cada una en al menos mil sitios, cada una sin responsable desde hace dos años.

Lo digo con claridad: esto es una muestra, no un censo. Se tomó de forma sistemática y no aleatoria, así que si las instalaciones activas se ordenaran en la cola siguiendo un patrón regular con periodo de siete páginas, el resultado quedaría sesgado. No veo motivo para que así sea, pero lo anoto en lugar de fingir que conté los 35 696.

#Lo que esta medición no ve

Tres cosas que el método excluye por construcción. Las menciono porque sin ellas el 51,5 por ciento parecería más preciso de lo que es.

No ve plugins fuera del directorio. Cualquier plugin premium comprado directamente al autor o en un marketplace queda fuera de esta API y no aparece en ninguna de las cifras anteriores. Una tienda WooCommerce típica ejecuta varios, a menudo los más sensibles, porque tocan pagos, envíos y datos de clientes. Su estado hay que comprobarlo a mano, uno por uno, y ese trabajo no lo sustituye una sola consulta.

No ve plugins cerrados. Cuando un plugin se retira del directorio desaparece de la API, así que no entra ni en el numerador ni en el denominador. Paradójicamente eso significa que los plugins cerrados por motivos de seguridad mejoran la estadística, porque salen del conjunto. El 51,5 por ciento es una cuota entre los que siguen listados.

Las instalaciones activas las publica WordPress.org por tramos, no de forma exacta. Por eso la tabla usa intervalos y no sumas. Un plugin etiquetado con mil instalaciones puede tener mil doscientas o mil novecientas, y el directorio no distingue. Para la conclusión que extraigo esa resolución basta, para algo más fino no bastaría.

#Qué significan en concreto ocho años sin actualización

La cifra de 20 242 plugins intactos desde hace ocho años sigue siendo abstracta hasta que uno recuerda cómo era WordPress entonces.

Agosto de 2018 es WordPress 4.9. Gutenberg aún no estaba en el núcleo, llegó en diciembre con la 5.0. El editor de bloques, con el que hoy se escribe prácticamente todo el contenido, es para este código un futuro que nunca llegó. Un plugin de aquella época no sabe nada de bloques, de register_block_type, de theme.json, de la edición del sitio completo.

En PHP el retrato es el mismo. PHP 7.0 y 7.1 eran comunes, y mucho alojamiento seguía en 5.6. Desde entonces llegaron propiedades tipadas, argumentos con nombre, expresiones match, atributos y, sobre todo, PHP 8 convirtió muchos avisos en errores fatales. Código que en 2018 escribía un aviso en el registro puede hoy tumbar un sitio.

Nada de esto significa que cada uno de esos plugins esté roto. Significa que nadie lo ha comprobado, y que la distancia entre sus supuestos y el entorno actual es de ocho años.

#Lo que la cifra no significa

Un plugin abandonado no es automáticamente vulnerable, y no quiero que este texto se lea como alarmismo.

Un plugin que añade un shortcode y no acepta datos externos puede funcionar una década sin actualizarse y ser completamente seguro. La falta de actualizaciones también puede querer decir que el código está terminado, algo que suena ajeno en un mundo de lanzamientos semanales, pero que es cierto en herramientas realmente pequeñas.

El riesgo no viene de la edad, viene de la superficie de ataque. Sube donde un plugin acepta datos del usuario, registra endpoints REST, gestiona subidas, construye consultas a la base de datos a partir de parámetros o toca pagos y datos personales. La edad es ahí un multiplicador, no una causa: el código antiguo de manejo de ficheros es peligroso no por ser antiguo, sino porque PHP y las técnicas de ataque avanzaron y él no.

Hay un reverso. Un plugin actualizado cada semana también puede ser vulnerable, y de forma reciente. La fecha de la última actualización es una señal sobre mantenimiento, no sobre calidad del código.

#Cómo revisar tus propios sitios en quince minutos

Tres pasos, en este orden, ninguno requiere herramienta de pago.

Construye la lista. Extrae los slugs de todos los plugins de cada instalación que mantengas. Un sitio se resuelve en el panel, decenas exigen WP-CLI y un bucle. El resultado debe ser una lista, no veinte pestañas.

Consulta el directorio. Para cada slug, obtén de la API la fecha de la última actualización y el número de instalaciones activas. Es una petición por plugin y puede hacerse en bloque. Los plugins fuera del directorio, es decir los premium y los hechos a medida, no devolverán nada, y esa ausencia es en sí un resultado: nunca aparecerán en un listado así, y suelen ser justo los que tocan pagos.

Ordena por riesgo, no por fecha. Una columna de fechas por sí sola no dice nada. Lo que interesa es la intersección de tres cosas: largo tiempo sin mantenimiento, toca datos o pagos, difícil de desactivar sin perjuicio para el cliente. Un plugin que cumpla las tres es trabajo de esta semana, no de algún día.

Ya que tienes la lista abierta, añade una columna para indicar qué plugin puede apagarse una hora sin consecuencias. Esa información no tiene precio el día de un incidente, y recogerla entonces es el peor momento posible.

#Qué hacer cuando un plugin está realmente abandonado

De lo más barato a lo más caro, porque la primera opción resuelve más casos de los que se espera.

Comprueba si aún hace falta. Buena parte de los plugins abandonados en sitios de clientes hace algo que ya nadie usa: un formulario de una campaña de hace tres años, una integración con un servicio cerrado, un widget en un pie que se rehízo. Eliminarlo es entonces la solución completa y lleva un minuto.

Comprueba si el núcleo ya lo hace. WordPress ha absorbido en los últimos años bastante de lo que antes exigía un plugin: lazy loading, WebP, parte del trabajo con bloques, mapas del sitio en XML. Un plugin de 2017 es a menudo sencillamente redundante.

Busca un reemplazo mantenido. Júzgalo por la cadencia de lanzamientos y por si el autor responde en el foro de soporte, no por el número de instalaciones. Un plugin con un millón de instalaciones y el último lanzamiento hace un año es peor elección que uno con cinco mil y un lanzamiento el mes pasado.

Escríbelo tú mismo si la función es pequeña. Un plugin que hace una cosa en cincuenta líneas pertenece más veces a tu propio plugin de funcionalidades, como cincuenta líneas, que a una dependencia de alguien que desapareció. Es trabajo real, pero termina el problema en lugar de pasárselo al siguiente responsable.

Mantenlo y vigílalo, de forma consciente. A veces no hay reemplazo y reescribir sale demasiado caro. Es una decisión legítima, siempre que quede escrita: quién la tomó, cuándo, y qué pasa cuando aparezca un CVE. La diferencia entre deuda técnica y desorden es que la deuda está documentada.

#Tres casos de la práctica, uno por decisión

Para no quedarnos en los principios, tres situaciones típicas que llevan a tres conclusiones distintas.

Un plugin de galería, última actualización hace cinco años, unas mil instalaciones, usado en una página. La comprobación lleva un minuto: ¿lo hace ya el núcleo? Las galerías en bloque manejan hoy disposiciones, lightbox e imágenes responsivas, así que la respuesta suele ser sí. La vía más barata, quitarlo y pasar el contenido a un bloque, cierra el asunto sin buscar reemplazo.

Un plugin de formularios, última actualización hace tres años, decenas de miles de instalaciones, que gestiona el formulario de contacto y el alta en la newsletter. Aquí la edad cuenta, porque un formulario acepta datos externos y los escribe en la base de datos, justo la superficie que peor envejece. El alto número de instalaciones no tranquiliza, al contrario: convierte al plugin en un objetivo atractivo. Es candidato a sustitución por un equivalente mantenido, con migración de los envíos guardados, y eso es medio día de trabajo, no un minuto.

Una integración con una empresa de transporte, última actualización hace dos años, unos cientos de instalaciones, sin reemplazo, conectada al checkout. El caso más difícil, porque ni se apaga ni se sustituye. La única decisión honesta es mantenerlo y escribirlo: quién decidió, cuándo, qué ocurre ante un CVE y quién revisa cada trimestre si el autor ha vuelto. Sin ese registro, dentro de un año nadie recordará que fue una decisión y no un descuido.

El denominador común es que la fecha de la última actualización nunca es por sí sola una conclusión. Es una entrada a una ponderación en la que también cuentan la superficie de ataque, el coste de apagar y la existencia de reemplazo.

#Por qué esto no se arregla solo

El directorio no tiene un mecanismo que retire un plugin solo por falta de actualizaciones, y está bien, porque tal mecanismo borraría también código terminado y funcional. Sí tiene un mecanismo para cerrar plugins por motivos de seguridad, y ese funciona.

El problema es que ambos hechos juntos producen un paisaje en el que el estado por defecto de un plugin es permanecer. El autor deja de responder, el plugin se queda. Las instalaciones bajan despacio, porque los sitios rara vez quitan nada. Ocho años después hay veinte mil plugins en el directorio y nadie al otro lado.

Súmese la cifra que Patchstack indica en State of WordPress Security in 2026: el 46 por ciento de las vulnerabilidades no tenía parche en el momento de la divulgación pública. En un plugin mantenido, la falta de parche es cuestión de horas o días. En uno abandonado no habrá parche nunca, porque no hay quien lo escriba.

No voy a terminar con una apelación al directorio, porque el directorio no es aquí el actor principal. La única parte que puede hacer algo con un plugin abandonado en un sitio concreto es la persona que mantiene ese sitio.

#Cómo se relaciona esto con las seis horas de espera

Hace unos días escribí sobre la iniciativa Protect the Shire, que retiene cada nuevo lanzamiento de plugin hasta seis horas para que un análisis automático pueda mirar lo que está a punto de llegar a las actualizaciones automáticas. Poner aquel texto junto a esta medición da una conclusión que ninguno de los dos da por separado.

La espera protege frente a un lanzamiento malicioso. Para que funcione, tiene que existir un lanzamiento. Todo su valor atañe por tanto a plugins que alguien sigue publicando, es decir, a la mitad del directorio que tiene responsable.

La otra mitad, la medida aquí, queda por completo fuera de ese mecanismo. Un plugin intacto desde hace ocho años no publicará un lanzamiento malicioso, pero tampoco publicará un parche. No hay nada que retener, porque no viene nada. El riesgo se desplaza de lo que llega a lo que ya está instalado.

Son dos problemas distintos con una palabra común en el nombre, y conviene no confundirlos. El primero le toca resolverlo al directorio, y lo está resolviendo cada vez mejor. El segundo el directorio no puede resolverlo, porque la solución consiste en que alguien mire un sitio concreto y decida sobre un plugin concreto.

#Repite la medición tú mismo

El script está público en nuestro repositorio y se ejecuta con un comando. Consulta solo la API pública de WordPress.org, no necesita clave y hace menos de cincuenta peticiones para toda la medición.

Si te sale un resultado distinto al mío, escríbeme. Prefiero que me corrijan con una cifra a que me citen sin comprobar, porque es precisamente de la falta de comprobación de donde salieron el 43,8 y el 59 por ciento con los que empecé.

#Fuentes

• API del directorio de plugins de WordPress.org, modo browse=updated, medición del 10 de agosto de 2026
• Patchstack, State of WordPress Security in 2026, 25 de febrero de 2026

Última verificación: 10 de agosto de 2026.