SSRF no WordPress faz o seu servidor disparar requisições para alvos que o atacante escolhe, virando um proxy interno. Segundo o WPScan (2024), falhas de validação de entrada como o SSRF estão entre as mais reportadas no ecossistema de plugins. A defesa real é validar o destino com wp_safe_remote_get, não só o firewall. Entender o mecanismo evita confundir SSRF com XSS.

O SSRF (Server-Side Request Forgery) é uma falha em que um endpoint do WordPress aceita uma URL controlada pelo usuário e o próprio servidor dispara a requisição para esse destino, sem validar se ele é legítimo. Diferente do XSS, que executa script no navegador da vítima, o SSRF age do lado do servidor: ele transforma a sua máquina, confiável dentro da rede, em uma ponte para alcançar serviços internos que estariam fora do alcance de qualquer um na internet. No WordPress, a porta de entrada quase sempre é um plugin que importa imagens, busca feeds ou consome APIs externas a partir de uma URL que o visitante informa. Quem cuida de vários sites, como a gente vê no suporte da FULL, encontra esse padrão em integrações antigas sem auditoria. Este guia faz parte do hub de vulnerabilidades WordPress da FULL.

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

O SSRF no WordPress explora a confiança que a rede deposita no servidor, e basta 1 requisição forjada para o ataque começar: se o seu servidor consegue alcançar um banco de dados interno ou o endpoint de metadados da nuvem, o atacante passa a alcançar também, usando o WordPress como intermediário. O alvo clássico em ambientes AWS é o endereço 169.254.169.254, que expõe credenciais temporárias da instância.

Um atacante envia uma URL maliciosa para um endpoint que aceita endereço remoto; o servidor, sem checar o destino, conecta e devolve (ou apenas processa) a resposta. A OWASP, que mantém o catálogo de referência de ataques web, classifica o SSRF como falha de validação de destino, não de identidade. Por isso senha forte e proteção contra XSS não resolvem SSRF sozinhas: o problema é o servidor confiar cegamente em qualquer URL que recebe pela REST API ou por um formulário.

Os 3 tipos de SSRF que aparecem no WordPress

Existem 3 tipos de SSRF que cobrem a grande maioria dos casos reais no WordPress, e separá-los muda a forma de detectar cada um. O primeiro é o SSRF com retorno, em que a resposta da requisição interna volta para o atacante na tela; o segundo é o SSRF cego, em que nada volta, mas o servidor executa a chamada mesmo assim; o terceiro abusa de esquemas como file:// e gopher:// para ler arquivos locais.

No SSRF com retorno, o atacante vê o conteúdo de um serviço interno direto na resposta HTTP. No SSRF cego, ele infere o resultado pelo tempo de resposta, padrão comum em firewall mal posicionado que só olha a borda. Já o SSRF por wrapper de protocolo, com PHP 8.2 e wrappers ativos, tende a permitir leitura de wp-config.php. Essa distinção conecta o SSRF ao conceito de falha de validação de destino, e não de roubo de credencial pelo navegador.

Exemplo real: CVE de SSRF em plugins WordPress

O SSRF não é teoria: ele aparece em CVEs reais de plugins amplamente instalados, e 2 exemplos bastam para ver o padrão. O WP Fastest Cache, segundo o perfil público do WPVulnerability, acumulou 48 CVEs históricas (2 críticas, 7 altas), todas já corrigidas, o que indica manutenção ativa e auditoria constante, não abandono.

Um caso histórico relevante é a CVE-2019-13635, registrada no NVD do NIST, com CVSS 9.1, que afetava versões anteriores a 0.8.9.6 do WP Fastest Cache e foi corrigida nesse patch. No Elementor, que soma 61 CVEs históricas, a CVE-2020-7055 (CVSS 9.9) mostrou como falhas de validação em versões anteriores a 2.7.5 abriam caminho para requisiçõ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 SSRF no seu WordPress

Detectar exposição a SSRF começa por mapear quais plugins aceitam URL do usuário e fazem fetch no servidor, e isso é auditável em poucos minutos. A pista mais forte é um endpoint REST API que recebe um endereço remoto e chama wp_remote_get sem allowlist de destino. Ferramentas como Wordfence e WPScan ajudam a cruzar a versão instalada com vulnerabilidades conhecidas, separando risco atual de CVE já corrigida.

Na prática, dois sinais merecem atenção imediata e aparecem nos logs antes de qualquer estrago visível.

Plugins que buscam URL remota sem validação

Plugins de import, de preview de link ou de feed que aceitam endereço arbitrário concentram risco: se o autor parou de auditar, a falta de allowlist fica aberta. Verifique a data do último release no repositório oficial do WordPress.org e considere a lista de ferramentas para verificar vulnerabilidades.

Requisições de saída para ips internos no log

Qualquer chamada de saída para 127.0.0.1, faixas privadas (10.x) ou o link-local 169.254.169.254 é candidata a SSRF. Monitore o log: tráfego interno inesperado é o sintoma mais confiável.

Como se proteger de SSRF no WordPress

A defesa central contra SSRF no WordPress é a allowlist de destino no código, aplicada pela função nativa wp_safe_remote_get, que recusa por padrão requisições para IPs privados e link-local antes de conectar. Essa função existe no core e deveria ser o padrão de todo plugin que busca URL remota, em vez do wp_remote_get cru.

Quando um plugin valida o destino com wp_safe_remote_get e bloqueia esquemas como file:// e gopher://, uma URL forjada para a rede interna é rejeitada antes da conexão. Além disso, três camadas reduzem a superfície: um firewall que inspeciona o tráfego de saída; a segmentação de rede que isola o endpoint de metadados; e patches em dia. Nos tickets da FULL, a gente vê que o gargalo raramente é o firewall de borda: é um plugin de integração desatualizado que reabre o vetor mesmo com WAF ativo. Vale seguir o hardening de segurança no WordPress e revisar a auditoria completa de segurança. Comparado ao XSS e ao SQL injection, o SSRF exige proteger a saída.

Segurança gerenciada no plano da FULL

Proteger contra SSRF exige WAF com inspeção de saída, plugins premium sempre atualizados e monitoramento contínuo de log, 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 e a rotina de patch. 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, o comparativo de plugins de segurança 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 SSRF no WordPress

Próximos passos para blindar seu site contra SSRF

Tratar SSRF no WordPress é menos sobre uma ferramenta única e mais sobre disciplina: validar todo destino de saída com wp_safe_remote_get, bloquear IPs internos e link-local e manter cada plugin de integração atualizado. O SSRF não rouba dados do navegador como o XSS, mas transforma o seu servidor em proxy do atacante, e por isso passa despercebido até a conta de nuvem ou o log denunciar. Comece auditando os plugins que aceitam URL remota 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.