O que fazer no dia em que uma vulnerabilidade de plugin do WordPress é publicada

Quase todos os dias é publicada uma nova vulnerabilidade em um plugin de WordPress. A maioria não exige nada além da próxima atualização de rotina. Algumas exigem ação hoje: as que estão sendo exploradas ativamente, as que não precisam de login ou as que estão em um plugin que você usa em dezenas de sites de clientes. Este guia é uma rotina para esse dia: como decidir rápido se uma falha importa para você, como encontrar cada site afetado e o que fazer depois de atualizar.

Passo 1: decida em cinco minutos se é urgente

Leia o próprio aviso (Patchstack, Wordfence ou WPScan), não só a manchete. Quatro perguntas decidem a velocidade com que você age:

• Está sendo explorada? Um aviso que diz que há ataques acontecendo vai para o topo do seu dia.
• Precisa de login? Uma falha que um visitante anônimo pode usar é muito mais perigosa do que uma que exige uma conta de administrador.
• O que um atacante pode fazer? Enviar arquivos, executar código ou criar contas de administrador é pior do que um XSS refletido que precisa de um clique.
• Em quantos dos seus sites ele está? Um site é uma tarefa; quarenta sites são um projeto com prazo.

Se a resposta às duas primeiras perguntas for sim, trate como urgente: sites afetados hoje, não na próxima rodada de manutenção.

Passo 2: encontre cada site afetado

Você precisa de dois dados por site: o plugin está instalado (ativo ou não) e em qual versão. Plugins inativos também contam. O código vulnerável continua no servidor e muitas vezes ainda pode ser acessado diretamente.

Com o WP-CLI isso leva segundos por site:

wp plugin list --name=ninja-forms --fields=name,status,version

Sem WP-CLI, confira em Plugins no wp-admin ou a versão no readme.txt do plugin. Anote o resultado em uma única lista: site, instalado sim ou não, versão, versão corrigida. Essa lista é seu checklist para o resto do dia e depois sua prova para o cliente.

Passo 3: atualize os sites afetados, os mais expostos primeiro

Comece pelos sites que mais importam se forem atingidos: lojas virtuais, sites com muitos formulários ou contas de usuário e sites com muito tráfego. Antes de cada atualização, garanta que existe um backup recente que você realmente consegue restaurar.

Atualizações de segurança costumam ser pequenas, mas nem sempre. Alguns fornecedores entregam a correção em uma versão maior, com outras mudanças. Se a versão corrigida for um salto grande, ou se o plugin cuida de formulários ou do checkout, teste primeiro em uma cópia do site quando puder e confira as páginas principais depois.

Se não puder atualizar hoje, por exemplo porque a correção ainda não saiu ou a atualização quebra algo, reduza o risco: desative o plugin se o site aguentar um dia sem ele, ou bloqueie o endpoint vulnerável no firewall se o aviso o indicar. Conte ao cliente o que você fez e por quê.

Passo 4: teste o que o plugin faz

Uma atualização bem-sucedida não é o mesmo que um site funcionando. Depois de atualizar, teste aquilo para que o plugin serve. Em um plugin de formulários, envie um envio de teste real e veja se o e-mail chega. Em um plugin de loja, faça um pedido de teste até o pagamento. Um formulário que para de enviar em silêncio pode custar a um cliente uma semana de contatos antes que alguém perceba.

Passo 5: verifique se o site já foi atingido

Atualizar fecha o buraco. Não remove nada que um atacante tenha deixado antes. Se a falha foi explorada antes do patch, verifique em cada site afetado:

• contas de administrador que você não reconhece;
• arquivos PHP na pasta uploads, que deveria conter apenas mídia;
• arquivos alterados recentemente em plugins e temas que você não atualizou;
• tarefas agendadas desconhecidas ou redirecionamentos que você não configurou.

Se encontrar sinais de invasão, restaure um backup anterior ao período do ataque, atualize imediatamente e troque todas as senhas e as chaves de segurança no wp-config.php. Só aplicar o patch não basta.

Passo 6: avise o cliente, de forma breve

Clientes raramente leem notícias de segurança, mas percebem quando a agência estava atenta. Uma nota curta basta: qual era o problema, se o site deles foi afetado ou não, o que você fez e quando. Isso transforma uma tarefa invisível em valor visível, e também entra no seu próximo relatório de manutenção.

Seja mais rápido da próxima vez

• Mantenha uma lista de quais plugins rodam em quais sites, para que o passo 2 leve minutos.
• Acompanhe uma ou duas fontes de avisos, não dez.
• Garanta que cada site tenha um backup que você já restaurou de verdade pelo menos uma vez.
• Combine antes com os clientes que atualizações de segurança urgentes acontecem fora do calendário normal.

Como a Verploy lida com vulnerabilidades em plugins

A Verploy mostra as vulnerabilidades conhecidas nos plugins e temas de cada site conectado, para você ver na hora quais sites foram afetados. Cada atualização é verificada, e as arriscadas são testadas primeiro em uma cópia, incluindo os formulários e o checkout. Os backups noturnos vêm com um teste de restauração, e se um site quebrar depois de ir ao ar, a Verploy o reverte. Saiba mais sobre monitoramento de vulnerabilidades do WordPress.