Atualizar os plugins do WordPress: o que acontece se você não fizer isso

Em quase todo painel do WordPress existe um número pequeno ao lado de Plugins. Ele não incomoda ninguém. Você fecha o aviso porque naquele momento outra coisa é mais urgente e, no login seguinte, o número está maior. O curioso é que não acontece nada. A página carrega, o formulário de contato envia, a loja recebe. É exatamente aí que está o problema. O custo de não fazer nada é invisível até deixar de ser, e aí ele chega de uma vez só.

Este artigo explica o que de fato acontece entre o aviso de atualização e o incidente, do ponto de vista de quem escreve essas atualizações. Nós mesmos construímos plugins para WordPress, publicamos as atualizações de que se fala aqui e vemos o que acontece depois.

Por que um aviso de atualização não é um pedido de arrumação

1. Uma atualização de segurança é o que torna a falha pública

Esse é o ponto que quase ninguém conhece e ele inverte a intuição. Enquanto uma falha de segurança dorme sem ser descoberta dentro de um plugin, ninguém sabe dela. No momento em que o desenvolvedor a fecha e publica a nova versão, surge algo novo: uma comparação pública entre o antes e o depois. Plugins do WordPress estão sob a GPL, o código é aberto e cada versão continua disponível no diretório. Colocar duas versões lado a lado e ver qual linha mudou é trabalho de rotina.

Publicar uma atualização de segurança é, portanto, publicar também o caminho até a falha na versão antiga. Isso não é um argumento contra atualizações, é o argumento mais forte a favor de atualizar rápido. O período mais perigoso na vida de uma falha de segurança não começa quando ela é escrita, começa quando ela é corrigida. Quem atualiza três semanas depois manteve por três semanas uma fraqueza documentada em operação.

2. Ninguém ataca você, alguma coisa varre você

A objeção mais comum é que o site é pequeno demais para alguém se dar ao trabalho. Isso pressupõe que do outro lado existe uma pessoa que escolhe. Não existe. O que roda são varreduras automáticas que processam listas de endereços procurando impressões digitais: caminhos que só um plugin específico cria, indicações de versão em arquivos legíveis publicamente, respostas que entregam uma versão determinada.

Para esse processo tanto faz se o seu site tem dez ou dez mil visitantes. O que interessa não é o seu alcance, e sim o servidor, a caixa de saída para disparo de spam e o espaço para redirecionamentos. Um site pequeno não é um alvo pior, apenas menos chamativo. Essa é, aliás, a razão de muitas invasões passarem meses sem ser notadas.

3. Um plugin é mais do que o código que o desenvolvedor escreveu

Quase todo plugin maior traz bibliotecas de terceiros: para gerar PDF, tratar imagens, conectar pagamentos, desenhar gráficos. Elas ficam na pasta do plugin e são entregues junto. Se em uma dessas bibliotecas aparece uma falha, depende unicamente do fornecedor do plugin se a versão corrigida chega até você. Essas dependências não aparecem no painel e você também não consegue atualizá-las por conta própria.

Do lado de quem desenvolve, essa é uma boa parte do nosso trabalho de atualização e ela fica completamente invisível de fora. Uma versão cujo changelog diz apenas que dependências foram atualizadas parece não ser nada e ainda assim pode ser a mais importante do trimestre.

4. O plugin mais perigoso é o abandonado

Um plugin que há dois anos não recebe atualização não é inofensivo porque nada aconteceu. Ele é perigoso porque nada mais vai acontecer. Se uma falha for encontrada ali, nenhuma atualização virá e, em regra, você não vai ficar sabendo.

O quanto isso é comum nós vimos em uma pesquisa própria. Para o nosso panorama de mercado analisamos artigos comparativos e conferimos na fonte os plugins recomendados. Em um artigo atual com vinte recomendações, cinco deles estavam fechados no diretório do WordPress. O artigo continua recomendando, e quem os instalou vê na lista de plugins exatamente o mesmo de antes: um nome, um número de versão, nenhum aviso. Um plugin fechado não some do seu site, ele apenas para de entregar atualizações.

Como isso funciona do nosso lado

Nós estamos do outro lado desse processo, então aqui vai a parte sem glamour.

É preciso ter um endereço para onde alguém possa escrever. Quem encontra uma falha precisa poder relatá-la sem passar por um formulário de contato que cai no comercial. Para isso mantemos um endereço de segurança próprio. Não é nada grandioso, mas é a diferença entre um aviso que chega e um aviso que acaba se tornando público porque ninguém respondeu.

Preferimos publicar pequeno e com frequência a publicar grande e raramente. Um exemplo desta semana: em 17 de agosto saiu a nossa versão 2.3.0 e em 18 de agosto a 2.3.1, porque o banner de consentimento voltava a ser exibido para visitantes que já haviam decidido. Não era falha de segurança, era incômodo. Mesmo assim uma coisa dessas sai na hora e não espera o próximo pacote grande. O motivo é concreto: uma versão que muda uma coisa pode ser verificada. Uma versão que muda oito coisas não permite mais a ninguém rastrear a única mudança que quebrou o layout.

E a parte que fornecedores escrevem de má vontade: às vezes atualizações dão errado. Isso não é teoria, é o nosso dia a dia tanto quanto o seu. Quem afirma que suas atualizações são livres de risco tem poucos usuários ou memória curta. A resposta certa para isso não é atualizar com menos frequência, é manter cada atualização pequena e reversível. Se depois de uma atualização aparecer uma tela branca no seu site, isso é chato e se resolve em dez minutos. Uma invasão não.

A frase never touch a running system vem de um mundo em que o sistema ficava numa sala e a porta era trancada. A sua instalação do WordPress fica na internet. O ambiente dela muda todo dia mesmo que você não encoste em nada: versões do PHP, navegadores, o núcleo do WordPress e as ferramentas de quem procura versões antigas. Um sistema que não se move não fica mais estável nesse ambiente, ele apenas fica mais velho.

O que o Cyber Resilience Act muda em 11 de setembro

O Cyber Resilience Act é um regulamento da União Europeia para produtos com elementos digitais, e software é um deles. A partir de 11 de setembro de 2026 valem as obrigações de notificação: vulnerabilidades ativamente exploradas e incidentes graves de segurança precisam ser comunicados. O restante das obrigações vem de forma escalonada.

Para fornecedores brasileiros isso não é assunto distante. O regulamento se aplica a produtos com elementos digitais colocados no mercado da União Europeia. Quem vende um plugin, um tema ou um serviço para clientes na UE entra no alcance do CRA, independentemente de onde a empresa está sediada. O contraponto brasileiro que muita gente já conhece, a LGPD, trata de dados pessoais e não substitui isso: o CRA trata de segurança do produto, e as duas coisas valem em paralelo.

Para fabricantes, no essencial são três coisas que antes eram voluntárias: tratar vulnerabilidades de forma ordenada, disponibilizar atualizações de segurança por um período declarado e ter um ponto de contato acessível para isso. Quem já tentou alguma vez falar com o desenvolvedor de um plugin que não é atualizado desde 2021 entende na hora qual problema está sendo endereçado.

Duas ressalvas fazem parte disso, por honestidade. A primeira: quem conta como fabricante no caso de software livre e de código aberto é justamente o ponto que segue em disputa. Aqui nós descrevemos, não decidimos por você. Este artigo é uma orientação e não aconselhamento jurídico, e para o seu caso concreto não há caminho que dispense uma análise profissional. A segunda: o CRA não atualiza o seu site. Ele muda o que você pode esperar de um fornecedor, não quem instala a atualização. Isso continua sendo tarefa sua, e se você cuida de sites para clientes, vira tarefa contratual.

Na prática, para a escolha: um plugin que não indica nem endereço de segurança nem período de suporte não é automaticamente ruim. Mas ele diz alguma coisa sobre quanta estrutura existe por trás, e essa informação você passa a receber sem precisar perguntar.

Na prática: atualizar sem derrubar o próprio site

Um backup que você já restaurou pelo menos uma vez. Um backup que nunca foi restaurado não é uma proteção, é uma esperança. Teste uma vez e você vai saber quanto tempo leva e se funciona. Quais ferramentas servem para isso está no artigo sobre plugins de backup para WordPress.

Atualizações automáticas para versões de segurança, manuais para o resto. O WordPress consegue atualizar plugins sozinho. Para versões corretivas pequenas essa é a configuração certa, porque ali o que mais conta é o tempo entre a publicação e a instalação. Em saltos grandes de versão que trazem funções novas, vale a olhada manual.

Trinta segundos no changelog. Se estiver escrito security fix, o assunto é urgente e não é negociável. Se estiver descrita uma função nova de que você não precisa, pode esperar até o fim de semana.

Um ambiente de teste assim que o site gera dinheiro. Para um blog um backup basta. Para uma loja ou uma área de membros você quer ter visto a atualização em outro lugar antes de os clientes verem.

Duas vezes por ano, um balanço. Todo plugin de que você não precisa mais é superfície de ataque sem contrapartida. Desativar não basta, porque os arquivos continuam no servidor. Apague.

Como reconhecer um plugin que vai deixar você na mão

Perguntas frequentes