Imagine chegar numa segunda de manhã e encontrar a fechadura da loja trocada por outra pessoa. No site, isso tem nome técnico e data: em 12 de agosto o WordPress liberou a versão 7.0.4 para tapar um buraco que permite a um invasor rodar o próprio código dentro do servidor onde o seu site mora. Se o seu negócio usa o site para receber pedido, orçamento ou contato, isso mexe direto com o seu faturamento.
A correção já existe e leva poucos minutos para aplicar. O problema é que ela não chega sozinha a todo site, e cada dia rodando a versão antiga é um dia com a porta destrancada. Abaixo está o caminho, na ordem, para fechar essa porta hoje sem derrubar a página no meio do expediente.
Passo 1: saiba qual versão do WordPress está rodando no seu site
Você não fecha uma porta sem saber se ela está aberta. Entre no painel do WordPress e olhe o rodapé da tela inicial, onde aparece o número da versão, ou vá em Painel e depois Atualizações. Se o número for menor que 7.0.4, o seu site está na faixa de risco, a menos que a atualização automática já tenha rodado (o Passo 4 mostra como confirmar isso).
Vale um sinal de quanto a coisa é séria: o WordPress não corrigiu só a versão nova. A equipe levou a mesma correção para ramos antigos do sistema, incluindo uma linha lançada há quase dez anos. Quando os mantenedores voltam tão atrás para tapar um buraco, é porque ele merece pressa.
Passo 2: entenda o que a falha CVE-2026-65640 abre no seu servidor
A falha corrigida tem código de registro CVE-2026-65640. Na prática, ela deixa um usuário com acesso de autor ou superior enviar um arquivo preparado que faz o servidor executar comandos que não deveria. Ela aparece em sites que usam duas ferramentas comuns de tratamento de imagem, o Imagick e o Ghostscript, presentes em boa parte das hospedagens.
O detalhe importante é quem consegue explorar isso. Não é qualquer pessoa que passa na rua: é preciso já ter um login de autor no seu WordPress. O ponto é que esse login existe com mais frequência do que se imagina, o freelancer que escreveu uns textos, o estagiário que saiu, a conta com senha fraca que vazou em outro lugar. Com esse pé dentro, a falha vira controle do servidor. E servidor sob controle de outra pessoa é o cenário em que o site que vende trabalha contra você:
- copiar a base de clientes e os dados deixados nos formulários de contato;
- trocar o seu checkout por uma página de pagamento falsa;
- desviar para outro endereço quem chega pelo Google;
- derrubar a página e pedir dinheiro para devolver o acesso.
Nenhum desses itens é hipótese distante para quem vive de vender pela internet. É por isso que a falha, mesmo dependendo de um login já existente, entrou como atualização de segurança e não como melhoria opcional.
Passo 3: faça backup do site antes de aplicar a 7.0.4
Antes de mexer em qualquer atualização, salve uma cópia do site, arquivos e banco de dados juntos. É um seguro barato: se a nova versão brigar com um tema ou plugin mais antigo e alguma coisa sair do lugar, o backup é o seu botão de desfazer. A maioria dos painéis de hospedagem gera esse backup em um clique, e quem tem alguém cuidando do site pode pedir a cópia antes de seguir. Leva minutos e evita a pior versão do problema, que é consertar a correção.
Passo 4: aplique a atualização e confirme que o site voltou no ar
Com o backup na mão, vá em Painel, Atualizações e aplique a versão 7.0.4. O WordPress avisou que sites com atualização automática ativada começariam a receber a correção pouco depois do lançamento, mas confirmar é seu, não do automático: abra o painel e veja o número mudar. Depois de atualizar, não pare no aviso verde de sucesso.
Abra o site numa janela anônima e também no celular, e teste o que dá dinheiro: o formulário envia, o botão de contato responde, o carrinho fecha, o WhatsApp abre. É esse teste, e não a tela de administração, que diz se o cliente que chegar daqui a uma hora vai conseguir comprar.
Passo 5: transforme a atualização em rotina para não repetir o susto
Repare por que isso virou emergência: o site ficou entregue à sorte até uma falha grave forçar a correção às pressas. Dá para sair desse ciclo com pouca coisa. Deixe as atualizações de segurança em modo automático, marque um horário fixo por semana para olhar o painel, e mantenha só os plugins que você realmente usa, porque cada plugin parado é mais uma porta para trancar. Um site que recebe essa atenção contínua não vira notícia de invasão; ele segue vendendo enquanto você cuida do resto do negócio.
A conta fecha fácil: a atualização custa dez minutos hoje; o site invadido custa os dias fora do ar mais cada venda que não entrou enquanto a porta ficou aberta. Entre as duas contas, a barata é a de agora.
