# SSRF no WordPress: Os 3 tipos e como se proteger 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.

SSRF vs XSS no WordPress: diferenca pratica
Vetor	Onde executa	Defesa principal
SSRF	No servidor, contra a rede interna	Allowlist de destino (wp_safe_remote_get)
XSS	No navegador da vitima	Sanitizacao e escape de saida
SSRF + nuvem	Servidor bate no endpoint de metadados	Bloquear IPs internos e link-local

## 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.

Metodologia desta análise

Este conteúdo cruza dados públicos de CVEs do perfil do WPVulnerability com os registros oficiais do NVD do NIST e a documentação de segurança do core do WordPress, consultados em maio de 2026. Os exemplos de CVE citam ID, CVSS e versão afetada reais, sempre distinguindo risco atual (uma falha sem patch disponível hoje) de histórico já corrigido por uma atualização anterior. Essa distinção evita o erro comum de tratar uma CVE antiga como ameaça presente. As observações de campo vêm do suporte da FULL, que monitora cerca de 150 mil sites WordPress e atua como CNA oficial sob a CISA. Nenhum percentual interno foi estimado sem base: os números de mercado vêm de fontes externas verificáveis como Patchstack e OWASP, e os de CVE, de bancos primários como o NVD do NIST. Os trechos citam apenas funções públicas do WordPress, sem instrução ofensiva acionável.

Perguntas frequentes sobre SSRF no WordPress

O que é SSRF no WordPress e por que ele é diferente de XSS e CSRF?

SSRF é quando o servidor do WordPress dispara uma requisição para um destino que o atacante escolhe, virando um proxy interno. Difere do XSS, que executa script no navegador, e do CSRF, que abusa da sessão do usuário: o SSRF age do lado do servidor, contra a rede interna. A defesa é a allowlist de destino com wp_safe_remote_get, não a sanitização de saída.

Por que um WAF de borda não bloqueia sozinho um ataque SSRF?

Porque o SSRF parte de dentro: a requisição maliciosa sai do próprio servidor confiável, depois que o WAF de borda já liberou o tráfego de entrada. Um firewall que só inspeciona o que entra não vê a chamada para 169.254.169.254 saindo. Por isso não confie apenas no WAF: a proteção real é validar o destino no código com wp_safe_remote_get e inspecionar também o tráfego de saída. Combine os dois, nunca um só.

Qual a diferença entre SSRF cego e SSRF com retorno no WordPress?

No SSRF com retorno, a resposta do serviço interno volta para o atacante na resposta HTTP, expondo dados direto. No SSRF cego, nada volta, mas o servidor executa a chamada mesmo assim, e o atacante infere o resultado pelo tempo de resposta ou por efeito colateral. O SSRF cego é mais difícil de detectar e exige monitorar o log de saída.

É possível ter SSRF em um plugin sem que o site fique fora do ar?

Sim, e esse é o caso mais perigoso: o SSRF não derruba o site nem gera erro visível. Audite todo plugin com endpoint de fetch, mesmo sem incidente aparente. Ele usa o servidor como ponte de forma silenciosa, varrendo a rede interna ou batendo no endpoint 169.254.169.254 da nuvem. O sintoma costuma ser indireto: uma conta de nuvem inflada ou tráfego de saída estranho no log. A regra prática é monitorar a saída, não esperar o site cair.

Quantas requisições internas um SSRF precisa para vazar credenciais de nuvem?

Em ambiente AWS vulnerável, basta 1 requisição bem-sucedida ao endpoint 169.254.169.254 para o servidor devolver credenciais temporárias da instância. Por isso bloquear o acesso a IPs link-local e privados é prioridade. CVEs como a CVE-2019-13635 (CVSS 9.1) no WP Fastest Cache mostram que a janela existe quando não há allowlist de destino no código.

## 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.