Introdução
O WordPress.org retém hoje cada novo lançamento de plugin até seis horas antes de chegar às atualizações automáticas. A Patchstack mede em cinco horas a mediana do tempo entre a divulgação pública de uma vulnerabilidade e a sua exploração em massa. Ambos os números estão no registo público desde julho e ninguém os colocou lado a lado.
Em resumo
- Seis horas é a espera atual de um lançamento de plugin ou tema no âmbito da iniciativa Protect the Shire. Arrancou a 5 de junho de 2026 com até 24 horas e foi reduzida para seis antes de 18 de julho de 2026.
- Cinco horas é a mediana até à exploração em massa de uma vulnerabilidade de elevado impacto, segundo o relatório Patchstack, State of WordPress Security in 2026, de 25 de fevereiro de 2026.
- 46 por cento das vulnerabilidades não têm correção no momento da divulgação pública. O número vem do mesmo relatório e muda o sentido dos dois anteriores.
- O registo público não diz se um patch de segurança está isento da espera. O anúncio refere cada novo lançamento e não estabelece distinção.
- A redução para seis horas foi anunciada apenas no Slack. Os autores de plugins souberam ao lançar.
- 11 334 novas vulnerabilidades no ecossistema em 2025, mais 42 por cento do que no ano anterior, e as facilmente exploráveis subiram 113 por cento.
- 12 por cento dos ataques conhecidos ao WordPress são travados por configurações comuns de alojamento e WAF. Este número corta o conselho que eu próprio dou mais abaixo.
De onde veio a espera
Em abril de 2026 saíram do diretório, de uma só vez, trinta e um plugins de uma mesma marca. Todos tinham um backdoor. Nada foi arrombado: alguém comprou os plugins no Flippa, herdou com eles o acesso SVN e publicou uma única atualização maliciosa disfarçada de correção de compatibilidade com o WordPress 6.8.2.
Vale a pena decompor este ataque em passos, porque cada um é legal isoladamente e só em conjunto formam um comprometimento. Comprar um plugin num marketplace é legal. Herdar com ele a conta do repositório está dentro das regras, porque é assim que se apresenta uma mudança de proprietário. Publicar uma atualização é o ato normal de um autor. Identificá-la como correção de compatibilidade para um lançamento concreto do WordPress é plausível, porque essas correções saíam de facto nessa altura. O alcance foi reportado em até 400 000 sites.
Nenhum elo desta cadeia parece suspeito por si só, e é esse o ponto. Um controlo assente em quem publica o código não tinha nada para detetar, porque quem o publicou foi o legítimo proprietário. Detetável era apenas o que estava lá dentro.
Este é um ataque à cadeia de fornecimento na sua forma mais pura, e o diretório não tinha resposta, porque todo o modelo de confiança assentava no pressuposto de que quem tem acesso de commit é quem diz ser. O Protect the Shire responde exatamente a este cenário. Entre o commit e a distribuição insere uma janela em que uma análise automática e um humano podem olhar para o que está prestes a seguir para milhões de instalações.
Como resposta àquele ataque, a espera faz sentido, e quero dizê-lo com clareza antes de passar à objeção. Seis horas entre um commit malicioso e a atualização automática são seis horas que antes não existiam.
Onde estas seis horas deixam de ajudar
A espera é neutra face ao conteúdo do lançamento. Não sabe se lá dentro vai uma funcionalidade nova, a correção de uma gralha ou um patch para uma vulnerabilidade sob exploração ativa. O anúncio de 5 de junho refere cada novo lançamento e não estabelece qualquer distinção. Também não encontrei fonte que descreva uma via acelerada para lançamentos de segurança.
Quero ser preciso aqui, porque é neste ponto que é fácil escrever algo falso. Não afirmo que não exista uma via acelerada. Afirmo algo mais fraco e verificável: não está documentada onde um autor de plugin a procuraria, ou seja, no anúncio e nas publicações públicas que se lhe seguiram. Para um autor que acabou de receber um relatório de vulnerabilidade e prepara um lançamento de emergência, uma via não documentada é, na prática, o mesmo que nenhuma via.
E é aqui que entra o segundo número. A Patchstack aponta uma mediana de cinco horas até à exploração em massa de uma vulnerabilidade de elevado impacto, contadas a partir da divulgação pública. Mediana, não média, portanto metade dos casos anda mais depressa.
Colocar os dois números lado a lado exige cuidado, porque medem coisas diferentes. Seis horas são um atraso na distribuição de uma atualização. Cinco horas são o tempo entre a divulgação e o ataque à escala. Não se sobrepõem com exatidão, e não afirmo que cada correção chegue uma hora atrasada. Afirmo que a janela de proteção do diretório é da mesma ordem de grandeza que a janela de ataque, e nessa proporção reter um lançamento deixa de ser gratuito.
O número que muda os dois anteriores
O mesmo relatório da Patchstack indica que 46 por cento das vulnerabilidades não tinham correção no momento da divulgação pública.
Este número desloca toda a discussão. Em quase metade dos casos não há nada para reter, porque ainda não existe lançamento. A espera não custa nada aí, mas também nada dá, e a única coisa que protege um site é uma camada que não espera pelo diretório: uma regra de WAF, uma funcionalidade desligada, um plugin desativado.
Na prática, o debate sobre as seis horas abrange pouco mais de metade dos casos. Para os restantes a pergunta é outra, e o diretório não é parte nela.
A escala que torna seis horas relevantes
Seis horas parecem inofensivas até se confrontarem com o número de acontecimentos que atravessam essa janela.
A Patchstack contou 11 334 novas vulnerabilidades no ecossistema WordPress em 2025, mais 42 por cento do que no ano anterior. São, em média, mais de trinta por dia. O aumento de volume só por si seria suportável se fosse uniforme, mas não é: as vulnerabilidades classificadas como facilmente exploráveis subiram 113 por cento de um ano para o outro, ou seja, mais do que duplicaram.
Em conjunto, estes dois números mudam a natureza do problema. Não é apenas haver mais falhas. É que a parte que mais cresce é a que se explora sem esforço, portanto em massa e por máquina. Com este perfil, uma mediana de cinco horas até à exploração em massa deixa de ser uma curiosidade estatística e passa a descrever um dia normal.
Nessa luz, uma espera do lado do diretório é uma das poucas alavancas que funcionam à escala. Uma análise automática que olha para cada lançamento escala melhor do que qualquer processo dependente de um autor de plugin ou de um administrador reagir a tempo. Por isso considero a direção acertada, e a discussão é apenas sobre se a janela deve continuar cega ao conteúdo do lançamento.
Uma correção ao meu próprio conselho
Escrevi acima que se deve construir uma camada que não espera pelo diretório, e apontei para uma regra de WAF. O mesmo relatório da Patchstack traz um número que corta esse conselho de forma significativa, e não o vou esconder.
Em testes de intrusão, as configurações comuns de alojamento e WAF bloquearam 12 por cento dos ataques conhecidos e ativamente explorados específicos do WordPress, e 26 por cento de um conjunto de teste mais amplo. Oito em cada dez ataques reais passam por aquilo que a maioria das agências considera a sua camada de proteção.
A distinção que salva o conselho é concreta e merece ser nomeada. Um WAF genérico de alojamento filtra padrões genéricos, tentativas grosseiras de injeção SQL e varrimentos de caminhos. Uma vulnerabilidade num plugin concreto raramente se parece com um ataque genérico. Parece um pedido válido a um endpoint válido, com um parâmetro definido de forma que o autor não previu. Uma regra genérica não vê isso.
Uma regra escrita contra um CVE concreto e já divulgado é outra coisa, aquilo a que o setor chama patching virtual. Não precisa de compreender uma classe de ataque, basta-lhe a assinatura deste caso. É essa a camada de que falava, e quero ser preciso: o objetivo não é ter um WAF, é ter um processo para acrescentar uma regra em horas a contar da divulgação. Ter simplesmente um WAF vale menos do que se assume.
Fica também uma ressalva honesta quanto à fonte. A Patchstack vende patching virtual, pelo que um número que mostra os WAF genéricos como fracos lhe é conveniente. Isso não o torna falso, e a metodologia está descrita no relatório como testes de intrusão contra um conjunto conhecido de exploits. Significa apenas que o número deve ser lido sabendo quem o publica. Menciono-o para que ninguém tenha de o descobrir sozinho.
O lado do autor do plugin, que é metade do problema
Até aqui escrevi da posição de quem mantém sites de terceiros. O autor de um plugin tem o mesmo problema invertido, e a sua versão é mais dura, porque é ele que está contra o relógio.
O cenário é este. Recebe um relatório de vulnerabilidade, normalmente através de um programa de bug bounty ou diretamente de um investigador. Combinam uma data de divulgação, prepara o patch, testa, publica o lançamento. Até junho de 2026 iam minutos entre o commit e a distribuição. Agora vão até seis horas, e não existe forma publicamente documentada de encurtar isso.
A consequência prática é que a data combinada com o investigador precisa de folga. Se combinar a divulgação para segunda-feira às nove, o lançamento tem de sair no domingo à noite, e não na segunda às oito. Contra uma mediana de cinco horas até à exploração em massa, essa hora é real.
A segunda consequência tem que ver com turnos. O programador Lopo resumiu-o melhor: descobrir só depois do lançamento que era preciso reorganizar turnos para acompanhar a distribuição. Quem publica um plugin com meio milhão de instalações precisa de alguém a olhar para os relatos nas horas em que a atualização se propaga de facto. Com uma janela móvel e não anunciada publicamente, isso não se planeia.
A terceira é mais subtil. A espera altera o significado de um número de versão. Até agora, publicar a 2.4.1 significava que a 2.4.1 estava em circulação. Agora significa que virá a estar, e entretanto o que circula é a 2.4.0, ou seja, a versão vulnerável que já é publicamente conhecida como vulnerável. As notas de lançamento têm de contar com isso, senão “corrigido na 2.4.1” é verdadeiro e enganador ao mesmo tempo.
Gandalf, ou a confiança deslocada, não eliminada
A espera, por si, não verifica nada. Conta o que acontece durante ela, e no anúncio esse papel cabe a uma análise automática chamada Gandalf.
Vale a pena reparar no que mudou realmente no modelo de confiança. Até abril, o diretório confiava em quem detinha o acesso SVN. Depois de abril sabe-se que esse acesso é por vezes comprado juntamente com o plugin, pelo que a confiança foi retirada desse lugar. Não foi eliminada, foi deslocada para uma análise automática que avalia o conteúdo do lançamento.
É a melhor solução, e digo-o com clareza, porque uma análise automática não se compra no Flippa. Mas levanta duas perguntas novas a que o registo público não responde.
A primeira é sobre erros no sentido contrário. Um scanner que deixa passar um lançamento malicioso é o problema óbvio. Um scanner que bloqueia um lançamento legítimo é o problema mais silencioso e, para o autor, mais doloroso, porque não se sabe a quem recorrer nem quanto tempo demora. Não encontrei descrição de um procedimento de recurso.
A segunda é quanto tempo demora a própria análise. Se demorar vinte minutos, a janela de seis horas é noventa e cinco por cento reserva e não trabalho, e a proposta de dispensar a espera com resultado limpo resolve praticamente o problema todo. Se demorar cinco horas, é o inverso. Esse único número muda a conclusão e não está publicado.
O Slack não é um canal de anúncios
A redução de 24 para seis horas entrou sem publicação pública. Ajay D’Souza deu por ela ao lançar um plugin antes de 18 de julho de 2026. Enrico Battocchi perguntou diretamente como deveriam ficar a saber de tais mudanças e se haveria uma publicação. Um programador de nome Lopo descreveu o custo operacional.
Este é um problema separado da espera em si e, na minha opinião, o mais grave. Um autor de plugin planeia um lançamento de emergência em torno de um atraso conhecido. Se o atraso muda sem aviso, o planeamento falha nos dois sentidos. Umas vezes espera mais do que orçamentou, outras sai mais cedo e ninguém acompanha a distribuição.
Existe uma proposta em rascunho para dispensar a espera quando a análise Gandalf nada encontra. A versão analisada deixa então de esperar e passa a ser servida. Isso resolveria a maior parte do problema, porque uma análise limpa é a esmagadora maioria dos lançamentos. A proposta está em apreciação e não foi implementada.
O que fazer do lado do site
Se mantém sites de clientes, a espera no diretório é uma variável que não controla. Há quatro que controla.
Não desligue as atualizações automáticas como reação a esta mudança. É o reflexo mais comum e é o contrário do que os números sustentam. A espera custa horas. Clicar à mão custa dias e, em seis idiomas e dezenas de sites, custa semanas. Como metade das falhas críticas é explorada nas primeiras 24 horas, o seu próprio tempo de resposta é o risco maior.
Ajuda ver a aritmética. A espera acrescenta no máximo seis horas. Atualizar à mão uma vez por semana dá um atraso médio de cerca de oitenta e quatro horas, catorze vezes mais. Mesmo atualizar à mão todos os dias dá uma média de doze horas, ainda o dobro da janela do diretório. Quem argumenta que a espera é demasiado arriscada e por isso passa ao modo manual troca seis horas por várias dezenas.
Construa o processo de acrescentar uma regra, não apenas o WAF. Depois da correção acima, este conselho lê-se de forma diferente do habitual. Ter um WAF de alojamento trava doze por cento dos ataques conhecidos ao WordPress, segundo os testes da Patchstack. O valor está em conseguir acrescentar uma regra para um CVE concreto e acabado de divulgar em poucas horas. É a diferença entre um produto e um procedimento, e aqui decide o procedimento.
Tenha por cliente uma lista dos plugins críticos para o negócio e saiba qual deles pode desligar durante uma hora. Desativar um plugin de formulários até chegar a correção é barato. Desativar uma gateway de pagamentos não é. Essa distinção pertence a um documento escrito antes do incidente, não durante. Na prática é uma coluna numa folha de cálculo, preenchida uma vez no arranque.
Saiba por onde vai saber de uma vulnerabilidade antes de a monitorização o dizer. O canal de informação conta aqui tanto como a camada técnica, porque contra uma mediana de cinco horas a diferença entre saber de manhã e à noite é a diferença entre uma correção e um incidente. Um feed de vulnerabilidades lido diariamente é mais barato do que qualquer ferramenta e define o teto da rapidez com que consegue sequer reagir.
O que esta mudança não resolve
Vale a pena dizer com clareza o que a espera não toca, porque é fácil sobrestimá-la.
Não toca em plugins fora do diretório. Um plugin premium comprado diretamente ao autor ou num marketplace atualiza-se pelo seu próprio canal, e nenhum período de espera o abrange. Uma loja WooCommerce típica corre vários desses, muitas vezes os mais sensíveis, porque tocam em pagamentos, expedição e dados de clientes.
Também não toca em temas e plugins instalados à mão a partir de um ficheiro ZIP, nem no código do plugin de funcionalidades do próprio cliente. E é precisamente aí que costuma estar a maior dívida, em código escrito à pressa e não tocado durante anos.
Por fim, não toca no caso em que o problema não é sequer o código, mas a configuração: permissões demasiado amplas, uma conta de administrador sem segundo fator, uma chave de API num repositório. O diretório não tem aqui qualquer papel, e a proporção destes casos nos incidentes reais é elevada.
O que não sei
Três coisas ficam em aberto, porque não tenho fonte para elas e não vou adivinhar.
Não sei se os lançamentos de segurança têm uma via acelerada que não esteja documentada publicamente. Não sei quanto tempo demora de facto uma análise Gandalf completa, pelo que não sei que parte das seis horas é trabalho e que parte é reserva. Não sei quando, ou se, a proposta de dispensar a espera com análise limpa será implementada.
Assim que alguma delas for documentada publicamente, atualizo este artigo e dato a alteração.
Fontes
- Protect The Shire, WordPress News, 5 de junho de 2026
- Patchstack, State of WordPress Security in 2026, 25 de fevereiro de 2026
- A redução para seis horas e a reação dos programadores
Última verificação: 10 de agosto de 2026.
