CSRF WordPress é um ataque que faz o navegador de um usuário logado executar uma ação sem que ele perceba. Segundo o WPScan (2024), falhas de CSRF estão entre os tipos mais reportados no ecossistema de plugins. A defesa nativa é o nonce, presente desde o WordPress 2.0.3. Entender o mecanismo evita o erro de tratar CSRF como XSS.

O CSRF (Cross-Site Request Forgery) é uma falha em que um site malicioso força o navegador da vítima a enviar uma requisição autenticada para o seu WordPress, abusando da sessão já aberta. Diferente do XSS, que injeta script na sua página, o CSRF não rouba dados: ele executa ações em nome de quem já está logado, como trocar um e-mail de admin ou aprovar um comentário. No WordPress, a porta de entrada quase sempre é um endpoint de plugin que processa um formulário ou uma chamada AJAX sem validar a origem da requisição. Quem cuida de vários sites, como a gente vê no suporte da FULL, encontra esse padrão em plugins antigos sem manutenção. Este guia faz parte do hub de vulnerabilidades WordPress da FULL.

O que é CSRF no WordPress: Definição operacional

O CSRF no WordPress explora a confiança que o servidor deposita no cookie de sessão, e basta 1 requisição forjada para concluir o ataque: se a vítima já tem um cookie de login válido, qualquer requisição que ela dispare chega autenticada, mesmo vinda de outra aba.

Um atacante hospeda um formulário oculto que aponta para uma URL do seu site; quando o admin visita a página armadilha, o navegador anexa o cookie e a ação acontece sem aviso. A OWASP, que mantém o catálogo de referência de ataques web, classifica o CSRF como falha de validação de intenção, não de identidade. Por isso senha forte e proteção contra XSS não resolvem CSRF sozinhas: o problema é o servidor aceitar uma requisição sem provar que o usuário realmente quis enviá-la.

Como o ataque CSRF funciona na prática

O fluxo de um CSRF no WordPress tem 4 passos e leva menos de 1 segundo no navegador da vítima: o admin faz login e o WordPress grava o cookie; o atacante o atrai para uma página externa com um formulário forjado; o navegador envia a requisição com o cookie anexado; e o servidor, sem checar a origem, executa a ação.

O ponto crítico é o gatilho: nenhum clique consciente é necessário. Uma tag com src apontando para uma URL GET vulnerável já dispara o ataque ao carregar a página armadilha. Por isso endpoints que mudam estado nunca devem aceitar GET, apenas POST. A documentação oficial de segurança do WordPress, mantida pelo time de core, é explícita: toda ação que altera dados precisa de um nonce WordPress validado no servidor. Entender esse mecanismo conecta diretamente ao conceito de CSRF como falha de intenção, e não como roubo de credencial.

Exemplo real: CVE de CSRF em plugins WordPress

CSRF não é teoria: ele aparece em CVEs reais de plugins com milhões de instalações, e 2 exemplos bastam para ver o padrão. O Contact Form 7, com mais de 5 milhões de instalações ativas, acumulou 12 CVEs ao longo dos anos, todas já corrigidas, o que indica manutenção ativa e auditoria constante, não abandono.

Um caso histórico relevante é a CVE-2023-6449, registrada no NVD do NIST, com CVSS 7.2, que afetava versões anteriores a 5.8.4 e foi corrigida no patch 5.8.4. No Elementor, que soma 61 CVEs históricas, a CVE-2023-48777 (CVSS 9.9) mostrou como uma falha de validação em versões anteriores a 3.18.2 permitia ações não autorizadas. Sobre catalogar essas falhas, a FULL fala com autoridade direta: é a única empresa brasileira credenciada como CVE Numbering Authority (CNA) sob a CISA desde maio de 2022, ou seja, atribui IDs CVE oficiais. Quem escreve aqui sobre vulnerabilidade literalmente cataloga vulnerabilidade.

Como detectar CSRF no seu WordPress

Detectar exposição a CSRF começa por mapear quais plugins processam ações sem verificar nonce, e isso é auditável em poucos minutos. A pista mais forte é um endpoint AJAX ou um formulário de admin que aceita requisição sem chamar check_admin_referer() ou wp_verify_nonce(). Ferramentas como Wordfence, WPScan e o próprio repositório de CVEs ajudam a cruzar a versão instalada com vulnerabilidades conhecidas. Esse cruzamento separa risco atual de CVE já corrigida.

Na prática, dois sinais merecem atenção imediata:

Plugins desatualizados com endpoint de escrita

Plugins sem atualização há mais de 12 meses concentram risco: se o autor parou de auditar, falhas de nonce ficam abertas. Verifique a data do último release no repositório oficial do WordPress.org antes de manter o plugin ativo, e considere a lista de ferramentas para verificar vulnerabilidades.

Ações que mudam estado via GET

Qualquer URL que altera configuração, status ou usuário via método GET é candidata a CSRF. Ação que muda dados deve ser POST com nonce, sem exceção.

Como se proteger de CSRF no WordPress

A defesa central contra CSRF no WordPress é o nonce, um token de uso único atrelado à ação, ao usuário e a uma janela de 24 horas, que o servidor verifica antes de executar qualquer mudança de estado. O WordPress inclui nonces no core desde a versão 2.0.3, lançada em janeiro de 2007.

Quando um plugin gera o nonce com wp_nonce_field() e valida com wp_verify_nonce(), uma requisição forjada de outro site não consegue adivinhar o token e é rejeitada. Além do nonce no código, três camadas reduzem a superfície de ataque: um Wordfence ou firewall de aplicação (WAF) que bloqueia padrões de requisição forjada; o cabeçalho SameSite=Strict no cookie de sessão; e uma rotina de atualização que aplica patches assim que saem. Em VPS com WooCommerce, a gente vê no suporte da FULL que o gargalo não é configurar o WAF, é manter os plugins atualizados, porque um plugin de checkout desatualizado reabre o vetor mesmo com firewall ativo. Vale seguir o passo a passo de hardening de segurança no WordPress e revisar a auditoria completa de segurança.

Segurança gerenciada no plano da FULL

Proteger contra CSRF exige WAF ativo, plugins premium sempre atualizados e monitoramento contínuo, e fazer isso manualmente em cada site não escala. O plano PRO da FULL custa R$ 849,90 por mês para até 10 sites, o que dá R$ 85 por site, com a camada de segurança gerenciada já configurada no bundle.

Esse bundle inclui Wordfence e o All in One Security pré-configurados, mais os 16 plugins premium. A FULL não hospeda seu site: ela gerencia a camada de plugins e segurança sobre a hospedagem que você já tem, então funciona como complemento, não como troca de servidor. Quem cuida de carteira de clientes troca o custo avulso de cada licença por um valor por site previsível. Você também pode escanear seu site agora: o FULL Scan cruza seus plugins com a base global de CVEs e aponta versões vulneráveis sem instalar nada. Conheça o All in One Security no plano da FULL, os planos da FULL e o repositório de vulnerabilidades.

Legenda: o scanner cruza a versão instalada com a base de CVEs e separa risco atual de CVE já corrigida.

Perguntas frequentes sobre CSRF no WordPress

Próximos passos para blindar seu site contra CSRF

Tratar CSRF no WordPress é menos sobre uma ferramenta única e mais sobre disciplina: validar nonce em toda ação de escrita, recusar GET para mudança de estado e manter cada plugin atualizado. O CSRF não rouba dados como o XSS, mas executa ações em seu nome, e por isso passa despercebido até o estrago aparecer. Comece auditando os plugins com endpoint de escrita e cruzando suas versões com a base de CVEs. Para aprofundar, o FULL Academy reúne os guias de segurança, e a base de guia de segurança para WordPress organiza o caminho do iniciante ao hardening avançado.