Metade do diretório de plugins está abandonada

#Introdução

Medimos o diretório de plugins do WordPress.org a 10 de agosto de 2026. De 69 286 plugins, 35 696 não recebiam atualização há pelo menos dois anos, ou seja 51,5 por cento. Este número não foi copiado do relatório de ninguém, porque tal relatório não existe. Segue-se o método, os resultados em quatro limiares e o que daí decorre para quem mantém sites de terceiros.

#Em resumo

• 35 696 de 69 286 plugins sem atualização há dois anos, 51,5 por cento do diretório.
• 28 146, ou 40,6 por cento, sem atualização há cinco anos.
• 20 242, ou 29,2 por cento, sem atualização há oito anos.
• Numa amostra de 5250 plugins abandonados, 5,9 por cento têm mil ou mais instalações ativas, o que dá cerca de 2100 em toda a cauda.
• Os números que circulam, 43,8 por cento e 59 por cento, não têm fonte primária. Verifiquei ambos. A verdade fica entre eles.
• O método está documentado e repete-se com um comando, porque um número que não se pode verificar vale exatamente o mesmo que aqueles dois.

#Porque medi, afinal

Ia escrever um texto assente no número de 43,8 por cento de plugins abandonados. Antes de o usar, procurei a fonte. Não existe.

Procurei uma alternativa e encontrei 59 por cento, repetido em muitos sítios ao lado de um número de cerca de 34 000 plugins. Parece mais sólido por vir com um valor absoluto. Li o texto que o introduz e também aí não há atribuição. O autor cita o WordPress.org e a WPExperts, mas para o total de plugins, e para a própria percentagem de abandonados não apresenta nada.

Este é o ciclo de vida habitual de uma estatística nesta área. Alguém publica um número sem fonte, o seguinte cita o primeiro com uma ligação, um terceiro cita o segundo, e um ano depois aquilo lê-se como conhecimento comum. Entre nós vigora uma regra desde 31 de julho de 2026, depois de termos retirado do nosso próprio site todos os valores que não conseguíamos sustentar. Publicar aquele número tê-la-ia quebrado de forma direta.

Restava um caminho honesto: contar.

#O método, para que possa ser repetido

O WordPress.org disponibiliza uma API pública do diretório em api.wordpress.org/plugins/info/1.2/. O modo browse=updated devolve os plugins ordenados por data da última atualização, do mais recente para o mais antigo.

Como a lista está ordenada, a resposta à pergunta sobre quantos plugins são mais antigos do que dois anos é simplesmente a posição do primeiro plugin anterior ao limiar. Encontrá-la não exige descarregar o diretório inteiro, basta uma pesquisa binária pelas páginas. Nove pedidos em vez de setecentos.

Toda a medição está no nosso repositório como npm run measure:plugin-abandonment e repeti-la demora menos de um minuto. Se ler isto daqui a seis meses e os números parecerem outros, não é porque algum de nós esteja errado. É porque o diretório está vivo.

#Resultados em quatro limiares

O diretório tinha 69 286 plugins no momento da medição, e a atualização mais recente tinha minutos.

O interessante é a forma desta distribuição, não um número isolado. Entre o limiar de dois e o de oito anos caem apenas cerca de 15 000 plugins, ou seja, a maioria dos plugins abandonados não foi abandonada recentemente. Quase três décimos de todo o diretório são código que ninguém toca há oito anos: antes do Gutenberg, antes do PHP 7.2, antes dos blocos.

#O número que importa na prática

A percentagem de plugins abandonados é, por si só, uma curiosidade. O diretório pode conter qualquer quantidade de código morto sem prejudicar ninguém, desde que ninguém o utilize.

Por isso medi uma segunda coisa: quantos desses plugins abandonados continuam a correr em sites. Retirei uma amostra sistemática da cauda do diretório, a cada sétima página de resultados, 5250 plugins, e contei as instalações ativas.

Transpor os 5,9 por cento para toda a cauda dá cerca de 2100 plugins que não recebem atualização há dois anos e ainda assim correm em mil sites ou mais cada um.

É este o número a reter em vez da percentagem. Dois mil pedaços de código, cada um em pelo menos mil sites, cada um sem responsável há dois anos.

Deixo claro: isto é uma amostra, não um recenseamento. Foi retirada de forma sistemática e não aleatória, portanto se as instalações ativas se dispusessem na cauda segundo um padrão regular com período de sete páginas, o resultado ficaria enviesado. Não vejo razão para que assim seja, mas registo-o em vez de fingir que contei todos os 35 696.

#O que esta medição não vê

Três coisas que o método exclui por construção. Menciono-as porque sem elas os 51,5 por cento pareceriam mais precisos do que são.

Não vê plugins fora do diretório. Qualquer plugin premium comprado diretamente ao autor ou num marketplace está fora desta API e não aparece em nenhum dos números acima. Uma loja WooCommerce típica corre vários deles, muitas vezes os mais sensíveis, porque tocam em pagamentos, expedição e dados de clientes. O seu estado tem de ser verificado à mão, um a um, e esse trabalho não é substituído por uma consulta única.

Não vê plugins encerrados. Quando um plugin é retirado do diretório desaparece da API, portanto não entra nem no numerador nem no denominador. Paradoxalmente, isso significa que os plugins encerrados por razões de segurança melhoram a estatística, porque saem do conjunto. Os 51,5 por cento são uma quota entre os que continuam listados.

As instalações ativas são apresentadas pelo WordPress.org em escalões, não com exatidão. Por isso a tabela usa intervalos e não somas. Um plugin marcado com mil instalações pode ter mil e duzentas ou mil e novecentas, e o diretório não distingue. Para a conclusão que retiro essa resolução chega, para algo mais fino não chegaria.

#O que significam concretamente oito anos sem atualização

O número de 20 242 plugins intocados há oito anos permanece abstrato até se recordar como era o WordPress nessa altura.

Agosto de 2018 é o WordPress 4.9. O Gutenberg ainda não estava no núcleo, chegou apenas em dezembro com o 5.0. O editor de blocos, com que hoje se produz praticamente todo o conteúdo, é para este código um futuro que nunca chegou. Um plugin dessa época nada sabe de blocos, de register_block_type, de theme.json, de edição do site completo.

Do lado do PHP o retrato é o mesmo. O PHP 7.0 e o 7.1 eram comuns, e muito alojamento corria ainda 5.6. Desde então chegaram propriedades tipadas, argumentos nomeados, expressões match, atributos e, sobretudo, o PHP 8 transformou muitos avisos em erros fatais. Código que em 2018 escrevia um aviso no registo pode hoje deitar um site abaixo.

Nada disto significa que cada um desses plugins esteja estragado. Significa que ninguém verificou, e que a distância entre os seus pressupostos e o ambiente atual é de oito anos.

#O que o número não significa

Um plugin abandonado não é automaticamente vulnerável, e não quero que este texto se leia como alarmismo.

Um plugin que acrescenta um shortcode e não aceita dados externos pode correr uma década sem atualização e ser completamente seguro. A ausência de atualizações também pode querer dizer que o código está terminado, o que soa estranho num mundo de lançamentos semanais, mas é verdade em ferramentas realmente pequenas.

O risco não vem da idade, vem da superfície de ataque. Sobe onde um plugin aceita dados do utilizador, regista endpoints REST, trata carregamentos, constrói consultas à base de dados a partir de parâmetros ou toca em pagamentos e dados pessoais. A idade é aí um multiplicador, não uma causa: código antigo de manipulação de ficheiros é perigoso não por ser antigo, mas porque o PHP e as técnicas de ataque avançaram e ele não.

Há o reverso disto. Um plugin atualizado semanalmente também pode ser vulnerável, e de forma recente. A data da última atualização é um sinal sobre manutenção, não sobre qualidade do código.

#Como verificar os seus sites em quinze minutos

Três passos, por esta ordem, nenhum exige ferramenta paga.

Construa a lista. Extraia os slugs de todos os plugins de cada instalação que mantém. Um site resolve-se no painel, dezenas exigem WP-CLI e um ciclo. O resultado deve ser uma lista, não vinte separadores.

Consulte o diretório. Para cada slug, obtenha da API a data da última atualização e o número de instalações ativas. É um pedido por plugin e pode fazer-se em massa. Os plugins fora do diretório, ou seja os premium e os feitos à medida, não devolvem nada, e essa ausência é em si um resultado: nunca aparecerão em nenhuma lista destas, e são normalmente eles que tocam em pagamentos.

Ordene por risco, não por data. Uma coluna de datas por si só nada diz. O que interessa é a interseção de três coisas: longo tempo sem manutenção, toca em dados ou pagamentos, difícil de desligar sem prejuízo para o cliente. Um plugin que cumpra as três é trabalho para esta semana, não para um dia qualquer.

Já com a lista aberta, acrescente uma coluna para indicar qual o plugin que se pode desligar durante uma hora sem consequências. Essa informação não tem preço no dia de um incidente, e recolhê-la nessa altura é o pior momento possível.

#O que fazer quando um plugin está mesmo abandonado

Do mais barato ao mais caro, porque a primeira opção resolve mais casos do que se espera.

Verifique se ainda é preciso. Boa parte dos plugins abandonados em sites de clientes faz algo que já ninguém usa: um formulário de uma campanha de há três anos, uma integração com um serviço encerrado, um widget num rodapé entretanto reconstruído. Remover é então a solução completa e demora um minuto.

Verifique se o núcleo já faz isso. O WordPress absorveu nos últimos anos bastante do que antes exigia um plugin: lazy loading, WebP, parte do trabalho com blocos, mapas do site em XML. Um plugin de 2017 é muitas vezes simplesmente redundante.

Procure um substituto mantido. Avalie-o pela cadência de lançamentos e por saber se o autor responde no fórum de suporte, não pelo número de instalações. Um plugin com um milhão de instalações e o último lançamento há um ano é pior escolha do que um com cinco mil e um lançamento no mês passado.

Escreva-o você mesmo se a funcionalidade for pequena. Um plugin que faz uma coisa em cinquenta linhas pertence mais vezes ao seu próprio plugin de funcionalidades, como cinquenta linhas, do que a uma dependência de alguém que desapareceu. É trabalho a sério, mas termina o problema em vez de o passar ao próximo responsável.

Mantenha e vigie, de forma consciente. Às vezes não há substituto e reescrever é demasiado caro. É uma decisão legítima, desde que fique escrita: quem a tomou, quando, e o que acontece quando surgir um CVE. A diferença entre dívida técnica e desarrumação é que a dívida está documentada.

#Três casos da prática, um por decisão

Para não ficar pelos princípios, três situações típicas que levam a três conclusões diferentes.

Um plugin de galeria, última atualização há cinco anos, cerca de mil instalações, usado numa página. A verificação demora um minuto: o núcleo já faz isto. As galerias em bloco tratam hoje de disposições, lightbox e imagens responsivas, portanto a resposta é normalmente sim. O caminho mais barato, remover e passar o conteúdo para um bloco, encerra o assunto sem procurar substituto.

Um plugin de formulários, última atualização há três anos, dezenas de milhares de instalações, a tratar do formulário de contacto e da inscrição na newsletter. Aqui a idade conta, porque um formulário aceita dados externos e escreve-os na base de dados, exatamente a superfície que envelhece pior. O elevado número de instalações não tranquiliza, pelo contrário: torna o plugin um alvo atraente. É candidato a substituição por um equivalente mantido, com migração das submissões guardadas, e isso é meio dia de trabalho, não um minuto.

Uma integração com uma transportadora, última atualização há dois anos, poucas centenas de instalações, sem substituto, ligada ao checkout. O caso mais difícil, porque não se desliga nem se substitui. A única decisão honesta é manter e escrever: quem decidiu, quando, o que acontece perante um CVE e quem verifica trimestralmente se o autor voltou. Sem esse registo, daqui a um ano ninguém se lembrará de que foi uma decisão e não um descuido.

O denominador comum é que a data da última atualização nunca é, por si só, uma conclusão. É uma entrada numa ponderação onde também contam a superfície de ataque, o custo de desligar e a existência de substituto.

#Porque isto não se resolve sozinho

O diretório não tem um mecanismo que retire um plugin apenas por falta de atualizações, e ainda bem, porque tal mecanismo apagaria também código terminado e a funcionar. Tem um mecanismo para encerrar plugins por razões de segurança, e esse funciona.

O problema é que os dois factos em conjunto criam uma paisagem em que o estado por omissão de um plugin é permanecer. O autor deixa de responder, o plugin fica. As instalações descem devagar, porque os sites raramente removem seja o que for. Oito anos depois há vinte mil plugins no diretório e ninguém do outro lado.

Some-se o número que a Patchstack indica no State of WordPress Security in 2026: 46 por cento das vulnerabilidades não tinham correção no momento da divulgação pública. Num plugin mantido, a falta de correção é uma questão de horas ou dias. Num abandonado nunca haverá correção, porque não há quem a escreva.

Não vou terminar com um apelo ao diretório, porque o diretório não é aqui o ator principal. A única parte que pode fazer alguma coisa quanto a um plugin abandonado num site concreto é a pessoa que mantém esse site.

#Como isto se relaciona com as seis horas de espera

Há uns dias escrevi sobre a iniciativa Protect the Shire, que retém cada novo lançamento de plugin até seis horas para que uma análise automática possa olhar para o que está prestes a chegar às atualizações automáticas. Colocar esse texto ao lado desta medição dá uma conclusão que nenhum deles dá sozinho.

A espera protege contra um lançamento malicioso. Para funcionar, tem de existir um lançamento. Todo o seu valor diz portanto respeito a plugins que alguém ainda publica, ou seja, a metade do diretório que tem responsável.

A outra metade, a medida aqui, fica inteiramente fora desse mecanismo. Um plugin intocado há oito anos não publicará um lançamento malicioso, mas também não publicará uma correção. Não há nada para reter, porque nada vem. O risco desloca-se do que chega para o que já está instalado.

São dois problemas diferentes com uma palavra comum no nome, e convém não os confundir. O primeiro cabe ao diretório resolver, e está a resolvê-lo cada vez melhor. O segundo o diretório não pode resolver, porque a solução consiste em alguém olhar para um site concreto e decidir sobre um plugin concreto.

#Repita a medição você mesmo

O script está público no nosso repositório e corre com um comando. Consulta apenas a API pública do WordPress.org, não precisa de chave e faz menos de cinquenta pedidos para toda a medição.

Se lhe der um resultado diferente do meu, escreva. Prefiro ser corrigido com um número a ser citado sem verificação, porque é precisamente da falta de verificação que nasceram os 43,8 e os 59 por cento com que comecei.

#Fontes

• API do diretório de plugins do WordPress.org, modo browse=updated, medição de 10 de agosto de 2026
• Patchstack, State of WordPress Security in 2026, 25 de fevereiro de 2026

Última verificação: 10 de agosto de 2026.