O tíquete WordPress nº 30465 foi aberto há 10 anos – 2025 será o ano em que finalmente será resolvido?

Em novembro de 2014, um desenvolvedor WordPress chamado Sergej Mueller levantou o que parecia ser uma preocupação razoável: os usuários não tinham como saber se um plugin que estavam usando havia sido removido do repositório oficial – mesmo que tenha sido removido por razões de segurança. Seu ticket – oficialmente #30465 – foi fechado pouco depois, mas sem resolução. Mal sabia Sergej que seria reaberto quase dez anos depois .

E aqui estamos, no início de 2025, comigo escrevendo uma atualização sobre isso.

Por que?

Por alguns motivos.

Primeiro, é altamente relevante para alguns eventos de segurança de plugins que aconteceram recentemente – outubro do ano passado, para ser exato. Falarei sobre isso em breve. E, em segundo lugar, a vontade e o ímpeto para resolver o problema têm ganhado força – a última atividade no ticket foi há menos de um mês:

Portanto, parece que a paciência de Sergej poderá finalmente dar frutos em breve…

Vamos começar reconstituindo o desenvolvimento do ticket. Então, podemos passar para o que tem acontecido nas últimas semanas:

De “não vou consertar” a subir ao palco no WCEU 2023 🙅‍♂️

Quando o ticket foi aberto pela primeira vez, ele recebeu algumas respostas, mas foi encerrado rapidamente pelo desenvolvedor líder do WordPress, Andrew Nacin. Ele fechou e marcou como “não vai consertar”, explicando que as remoções de plugins aconteceram por vários motivos, não apenas por questões de segurança:

Houve uma enxurrada de comentários depois disso, mas depois se transformou em comentários anuais (às vezes até menos que isso) de alguém tentando reviver o assunto.

Então, em março de 2023 , algo interessante aconteceu. Joost de Valk, uma figura conhecida na comunidade WordPress, reabriu oficialmente o ticket . Seu argumento era que o WordPress tem a responsabilidade de informar aos usuários se um plugin é mantido ou não.

Ele destacou ainda que o WordPress.org já mostrava essas informações na própria plataforma, mas somente após um período de espera de 60 dias. Sua sugestão foi trazer a mesma transparência para o backend do WordPress, onde os usuários realmente gerenciam seus plug-ins.

Isso desencadeou uma nova onda de entusiasmo em todo o segmento. O ingresso se tornou tão popular que Oliver Sild, CEO e cofundador da Patchstack, até o mencionou em seu discurso no WCEU 2023 :

Ele não apenas mencionou isso, mas incentivou os participantes do WCEU a deixar comentários no tópico usando o código QR personalizado que ele adicionou à sua apresentação. Ele também usou esse plug como um beco sem saída para um concurso que Patchstack sediaria no ano seguinte.

Evento Patchstack de outubro de 2024 🪲

Em outubro de 2024, Patchstack lançou um evento Bug Bounty como parte do Mês da Segurança Cibernética. Se a menção de Oliver ao ingresso # 30465 em seu discurso no WCEU fosse um beco sem saída, então os resultados deste evento seriam seu golpe decisivo.

Os pesquisadores de segurança que participaram do evento acabaram descobrindo um número impressionante de 1.571 relatórios válidos de vulnerabilidades de segurança em um único mês. Esses não foram apenas problemas menores – estamos falando sobre:

• 73 casos em que invasores puderam fazer upload de arquivos maliciosos.
• 67 Vulnerabilidades de injeção SQL que podem comprometer bancos de dados inteiros.
• 58 maneiras de os invasores aumentarem seus privilégios.
• 17 vulnerabilidades de execução remota de código (caramba!)

As consequências resultaram no fechamento temporário de quase 1.000 plug-ins. E quando o Patchstack tentou entrar em contato com desenvolvedores de plugins sobre esses problemas, quase 74% estavam completamente inacessíveis. Ou seus formulários de contato foram quebrados, seus e-mails foram devolvidos ou seus domínios expiraram.

O problema é que muitos desses plug-ins vulneráveis ​​estavam no repositório há 6 a 11 anos. Alguns datavam de 17 anos! E sim, ainda existem sites ativos dependendo desses plug-ins.

Desnecessário dizer que todos esses dados deram a Oliver uma vantagem no tópico para levar o ticket #30465 adiante até a conclusão. Felizmente, ele aproveitou a oportunidade e postou alguns detalhes duas semanas antes da publicação da postagem oficial do blog Patchstack discutindo o evento:

Da discussão à ação 🛠️

A atividade no tópico já estava crescendo como uma bola de neve quando Oliver adicionou seu comentário, então avaliar seu impacto individual é difícil. No entanto, não é absurdo supor que isso tenha acrescentado combustível a uma chama crescente. Especialmente com outros usuários (dos quais pelo menos um é funcionário do Patchstack) apoiando abertamente seus comentários.

Em resposta, o desenvolvedor líder do WordPress, Dion Hulse (@ dd32), deu algumas resistências em vários pontos, mas também intensificou-se enormemente ao criar um plugin experimental que implementa o recurso tão esperado:

A implementação é lindamente simples – quando um plugin é fechado no repositório do WordPress.org, os usuários veem uma notificação clara, mas medida. Sem alertas vermelhos que induzam ao pânico, apenas informações diretas sobre o status do plugin.

Alguém encontre Sergej e diga a ele: “mamãe, conseguimos!”

Bem... quase.

Ainda não faz parte do núcleo do WordPress, mas sinto que estamos perto da linha de chegada aqui!

Agora que foi demonstrado que isso é possível, o próximo passo é decidir sobre a implementação final. Então ele pode ser integrado ao núcleo do WordPress.

O que vem a seguir? 🎯

No momento em que este artigo foi escrito, o recurso estava sendo considerado para inclusão no WordPress 6.8 (de acordo com Dion Hulse), embora ainda existam alguns obstáculos a serem superados. Estes incluem:

• Finalizando o prazo de notificação (há discussão sobre a possibilidade de estender a janela de 60 dias).
• Padronizando a documentação do motivo do fechamento.
• Equilibrar a conscientização do usuário com a carga de suporte do desenvolvedor.
• Decidir a localização exata (a tela de integridade do site versus diretamente no plugin, conforme mostrado na captura de tela do exemplo do plugin).

O panorama geral 🌐

A evolução do ticket #30465 do WordPress nos diz algo fascinante sobre como a segurança do WordPress mudou na última década. O que antes era considerado um caso extremo tornou-se cada vez mais crítico à medida que o ecossistema cresceu e os desafios de segurança se multiplicaram.

Embora tenha demorado dez anos para chegar aqui, o plugin experimental sugere que estamos finalmente nos aproximando de uma solução que equilibra a consciência de segurança com a experiência do usuário. Com milhões de instalações do WordPress potencialmente afetadas por plug-ins vulneráveis, esse recurso não poderá chegar em breve.

Se você quiser acompanhar o desenvolvimento, confira o plugin experimental no GitHub ou fique de olho no ticket #30465. Este pode ser um daqueles raros momentos em que testemunhamos uma conversa de uma década se transformar em um resultado tangível. 💡

O que você acha desse recurso? Você acha que seria útil para você, como usuário do WordPress, ser informado de que um plugin foi fechado? Deixe-me saber nos comentários. Te vejo lá.