SSRF no SillyTavern (<= 1.17.0): O que os Proprietários de Sites WordPress Precisam Saber e Como o WP‑Firewall Protege Você

Data: 2026-05-19
Autor: Equipe de Segurança do Firewall WP

Etiquetas: segurança, wordpress, ssrf, vulnerabilidade, waf, resposta a incidentes

Sumário executivo

Em 19 de maio de 2026, uma vulnerabilidade de Falsificação de Requisições do Lado do Servidor (SSRF) de alta severidade afetando o pacote NPM “tavernaboba” (<= 1.17.0) foi publicada (CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j). O problema decorre de um baseUrl parâmetro não validado usado por uma integração de proxy de busca SearXNG. Um atacante pode explorar essa falha para forçar o servidor afetado a fazer requisições HTTP para endereços controlados pelo atacante ou internos, potencialmente expondo credenciais, endpoints de metadados, serviços internos ou permitindo um movimento lateral adicional. O pacote foi corrigido na versão 1.18.0. Se você executar serviços que dependem do sillytavern ou expõem funcionalidade de proxy reverso, trate isso como urgente.

Este post explica os detalhes técnicos em linguagem simples, por que os administradores do WordPress devem se importar, como detectar tentativas de exploração, mitigação imediata e de longo prazo recomendadas, regras de WAF de exemplo que você pode implantar agora (incluindo orientações do WP‑Firewall) e uma lista de verificação de resposta a incidentes que você pode seguir se suspeitar de comprometimento.

Por que isso é importante para os proprietários de sites WordPress

À primeira vista, uma vulnerabilidade de pacote NPM pode não parecer diretamente relacionada ao WordPress. Mas ambientes modernos do WordPress raramente são isolados:

• Sites WordPress frequentemente coexistem com outros serviços na mesma conta de hospedagem ou VM (camadas de cache, frontends/backends headless, agentes de chat, bots ou integrações auto-hospedadas).
• Equipes executam ferramentas de tecnologia mista (microserviços Node.js, frontends de chat, assistentes auto-hospedados) na mesma infraestrutura que a aplicação WordPress.
• Qualquer componente que possa ser induzido a realizar requisições HTTP(S) de saída em nome de um atacante pode ser transformado em uma arma para acessar endpoints internos (por exemplo, APIs de metadados, painéis de administração, portas de banco de dados) ou alcançar serviços internos que nunca deveriam ser públicos.

SSRF é uma classe de bug de alto impacto porque o atacante controla o alvo das requisições HTTP do lado do servidor, potencialmente permitindo acesso a recursos internos inacessíveis de outra forma. Para ambientes WordPress que compartilham rede ou credenciais com outros serviços, um SSRF em mesmo um pacote pode trazer consequências severas.

Contexto técnico — o que aconteceu

SillyTavern usa SearXNG como um proxy de busca para algumas de suas funcionalidades. Nas versões vulneráveis (<= 1.17.0), o baseUrl valor que configura o proxy de busca não foi devidamente validado ou restrito. Isso permitiu que um atacante fornecesse ou manipulasse baseUrl de modo que a aplicação fizesse requisições para URLs arbitrárias determinadas pelo atacante.

Características principais da vulnerabilidade:

• Classe: Falsificação de Requisição do Lado do Servidor (SSRF).
• Causa raiz: validação insuficiente de um parâmetro de URL/configuração (baseUrl) passado para uma chamada de proxy.
• Impacto: o servidor vulnerável pode ser feito para realizar requisições a IPs internos, endpoints de metadados em nuvem (169.254.169.254), outras APIs de gerenciamento interno ou qualquer host que o servidor possa alcançar. O atacante não precisa estar na mesma rede que a vítima — ele só precisa ser capaz de acionar o caminho de código vulnerável.
• Patch: sillytavern v1.18.0 inclui validação e restrições para prevenir controle do atacante. baseUrl valores.

Identificadores de CVE e aviso (para rastreamento): CVE‑2026‑46372, GHSA‑qg89‑qwwh‑5f3j.

Possíveis cenários de exploração (nível alto)

Abaixo estão cenários representativos para ilustrar por que SSRF é perigoso. Evito apresentar código de exploração, mas é importante entender ataques plausíveis:

• Recuperar metadados em nuvem: Se o servidor puder acessar o endpoint de metadados do provedor de nuvem, um atacante pode solicitar tokens de credenciais ou metadados de instância (por exemplo, AWS IMDS em 169.254.169.254), permitindo que eles escalem para acesso à API da nuvem.
• Acessar interfaces administrativas internas: Muitas aplicações expõem APIs de gerenciamento em localhost ou sub-redes internas. SSRF pode ser usado para acessar essas APIs (por exemplo, um endpoint de gerenciamento vinculado a 127.0.0.1 ou um socket Docker/RPC exposto via HTTP) e acionar ações destrutivas.
• Varredura de portas e descoberta interna: Um atacante pode usar o servidor vulnerável como um pivô para escanear faixas de IP internas e mapear serviços que de outra forma estariam inacessíveis pela Internet.
• Contornar regras de acesso à rede: Algumas redes restringem o acesso externo direto a certos sistemas; SSRF pode contornar essas restrições fazendo com que o servidor vítima faça a requisição em vez disso.
• Exfiltração de dados via endpoints internos: Alguns serviços expõem dados sensíveis via APIs internas ou endpoints de depuração. SSRF pode solicitar esses endpoints e retornar resultados ao atacante (diretamente ou via respostas redirecionadas).

Como o parâmetro vulnerável configura alvos de saída, um atacante pode elaborar requisições que retornem diretamente dados úteis ou estabeleçam uma cadeia de seguimentos que resultem na divulgação de dados.

Como detectar tentativas de exploração

Detectar tentativas de SSRF requer monitorar tanto requisições web quanto a atividade de saída do servidor. Aqui estão sinais práticos de detecção:

• Registros do servidor web: procure por requisições com parâmetros incomuns, especialmente baseUrl, proxy, url, alvo, ou outros parâmetros de URL. Valores incomumente longos ou codificados, credenciais de autenticação básica na URL, ou valores que incluam http://169.254.169.254 ou faixas de IP privadas são sinais de alerta.
• Logs da aplicação: verifique caminhos de código que realizam requisições HTTP e registram endereços de destino. Picos na frequência de requisições de saída ou requisições repetidas a um único endpoint de proxy são suspeitos.
• Logs de rede de saída: inspecione os logs de saída para conexões com intervalos de IP internos feitas a partir do processo do servidor web, ou conexões inesperadas para 169.254.169.254, 127.0.0.1, intervalos privados RFC1918, ou endereços link-local IPv6 (fe80::/10).
• logs de DNS: procure por consultas DNS para subdomínios aleatórios ou domínios com mudanças rápidas de TTL (potencial evasão baseada em DNS).
• Logs do WAF: bloqueie e monitore quaisquer tentativas que incluam valores baseUrl ou padrões que correspondam a intervalos de IP privados.
• Comportamento do processo: novos processos fazendo chamadas de rede a partir do runtime PHP/Node ou picos na atividade de CPU/DNS podem indicar tentativas de exploração automatizada.

Estabeleça essas linhas de base cedo para que desvios se destaquem.

Passos imediatos — o que fazer nas próximas horas

1. Corrija o software
   Se você executar SillyTavern ou qualquer serviço que dependa do sillytavern, atualize para a v1.18.0 imediatamente. Essa é a correção correta e elimina o bug subjacente.
2. Se você não puder atualizar imediatamente, aplique correção virtual
   Implemente regras de WAF para detectar e bloquear o uso malicioso baseUrl (exemplos abaixo).
   Restringir o acesso público a quaisquer endpoints que aceitem baseUrl ou proxy URLs.
3. Restringir conexões de saída
   Use regras de saída de host (grupos de segurança em nuvem, regras de firewall, iptables ou controles de hospedagem) para negar tráfego de saída, exceto para destinos explicitamente permitidos.
   No mínimo, bloqueie o acesso a endpoints de metadados em nuvem (169.254.169.254) e redes de gerenciamento internas.
4. Coloque em quarentena e investigue
   Se você detectar indicadores suspeitos da lista de detecção, isole o host afetado e preserve os logs para análise forense. Verifique sinais de roubo de credenciais ou comprometimento adicional.
5. Rotacione credenciais e segredos (se necessário)
   Se metadados de nuvem ou APIs de administrador puderem ter sido consultados, rotacione as chaves de API e credenciais afetadas.
6. Monitore ações subsequentes
   Procure novas contas de usuário, configuração alterada, arquivos modificados ou tarefas agendadas que possam indicar atividade de acompanhamento.

Mitigações do WP‑Firewall e regras de exemplo

Como fornecedor de firewall de aplicação web, recomendamos uma abordagem em camadas: conjuntos de regras WAF imediatos para corrigir virtualmente este vetor específico, além de controles de saída de host/rede para defesa em profundidade.

Abaixo estão regras de exemplo que você pode implantar imediatamente. Estes são exemplos de regras genéricas (estilo ModSecurity) destinadas a serem adaptadas para sua plataforma. Teste as regras em um ambiente de teste antes de implantar em produção para evitar quebrar o tráfego legítimo.

Nota importante: estas são padrões de detecção e bloqueio. Eles são intencionalmente defensivos; não os use como a única proteção — atualizar o pacote vulnerável continua sendo obrigatório.

1) Bloquear solicitações com baseUrl referência a IPs privados ou endpoints de metadados

# Verifique se o parâmetro baseUrl contém IPs privados ou endpoints de metadados SecRule ARGS_NAMES|ARGS "@rx (?i)^(baseurl|base_url|proxy_url|target_url)$" "phase:2,pass,id:100001,log,ctl:ruleRemoveById=981172" SecRule ARGS:baseUrl|ARGS:base_url|ARGS:proxy_url|ARGS:target_url \n    "@rx (?i)(127\.0\.0\.1|localhost|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2[0-9]|3[0-1])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.169\.254|fe80:|::1)" \n    "phase:2,deny,status:403,msg:'Bloqueado potencial SSRF - alvo não permitido em baseUrl',id:100002,log"

O que isso faz:

• Detecta parâmetros como baseUrl e nega solicitações se o valor contiver localhost, faixas privadas RFC1918, IP de metadados da AWS ou endereços locais IPv6.

2) Negar URLs com credenciais embutidas ou protocolos suspeitos

# Bloquear URLs com credenciais de autenticação básica ou protocolos perigosos SecRule ARGS "@rx [a-z0-9+\-.]+://[^@]+@|^(file|gopher|dict|scp|ssh):" \n    "phase:2,deny,status:403,msg:'Bloqueado potencial SSRF - credenciais ou esquema inseguro encontrado',id:100003,log"

3) Limitar a taxa ou bloquear solicitações de proxy repetidas

Se um único IP remoto estiver enviando muitas solicitações de proxy ou muitos valores únicos, baseUrl limite ou bloqueie:

Exemplo de limitação de taxa # (conceitual)"

(O acima ilustra a integração de uma verificação de limite de taxa personalizada para reduzir a exploração automatizada.)

4) Bloquear consultas DNS que resolvem para endereços privados

Uma abordagem mais avançada é realizar uma resolução DNS do host fornecido e bloquear se ele resolver para IPs privados. Isso requer suporte do WAF para verificações externas ou uso de um serviço de proxy.

5) Regras gerenciadas do WP‑Firewall

Clientes do WP‑Firewall receberão assinaturas gerenciadas que:

• Detectam e bloqueiam padrões comuns de SSRF em parâmetros de consulta e cargas úteis JSON.
• Negam solicitações direcionadas a metadados ou faixas de IP RFC1918.
• Aplicam heurísticas para detectar reatribuição de DNS ou nomes de host que resolvem para endereços internos.

Se você é um cliente do WP‑Firewall, certifique-se de que as regras gerenciadas estão ativadas e que as atualizações automáticas de regras estão ativas.

Diretrizes de endurecimento para desenvolvedores (correções no código)

Se você mantém ou desenvolve código que aceita URLs externas ou configuração de proxy, adote estas práticas de codificação segura:

• Use uma lista de permissão: permita apenas nomes de host específicos (ou um conjunto claramente definido de nomes de host) que a aplicação realmente precisa contatar.
• Rejeite esquemas não‑HTTP: aceite apenas http e https onde apropriado. Negue file:, gopher:, ssh:, etc.
• Aplique validação de host: analise a URL do lado do servidor e valide o componente do host contra uma lista de permissão. Rejeite IPs em faixas privadas.
• Previna credenciais incorporadas: desautorize URLs contendo usuário:senha@host.
• Resolva nomes de host e valide endereços IP: se você permitir nomes de host, realize uma resolução DNS e negue se o IP resolvido for privado ou de outra forma suspeito. Esteja atento a condições de corrida de DNS e use verificações resilientes (por exemplo, realize a resolução usando um resolvedor seguro).
• Timeouts e limites: defina timeouts de solicitação e limites em redirecionamentos para evitar o smuggling de solicitações e conexões de longa duração.
• Evite usar valores fornecidos pelo usuário diretamente como configuração: trate os parâmetros de configuração como entradas sensíveis que requerem validação rigorosa antes do uso.

Estes são os tipos de correções que os mantenedores do SillyTavern implementaram na versão v1.18.0 para fechar a vulnerabilidade.

Proteções em nível de host e rede

Confiar exclusivamente em correções de aplicativo não é suficiente. Adicione controles de rede:

• Impedir que processos da web acessem serviços apenas internos, a menos que explicitamente necessário. Use regras de firewall de saída do host (iptables / nftables), grupos de segurança em nuvem ou proxies de saída para restringir HTTP de saída.
• Bloquear o acesso a metadados da nuvem a partir de instâncias de aplicativo se as APIs da nuvem não forem necessárias pelo aplicativo. Por exemplo, bloqueie o tráfego de saída para 169.254.169.254 a partir do processo da web ou use políticas de função de instância que limitem a exposição.
• Execute serviços em segmentos de rede separados com rede de menor privilégio entre os componentes.
• Sempre que possível, force solicitações de saída através de um proxy monitorado e controlado que aplique listas de permissão e registre a atividade.

Essas medidas limitam o que um SSRF pode alcançar, mesmo que o aplicativo seja vulnerável.

Lista de verificação de resposta a incidentes (passos práticos)

Se você suspeitar de exploração, siga esta lista de verificação ordenada:

1. Preserve as evidências.
   Capture logs (web, aplicativo, firewall, DNS e fluxos de rede). Não sobrescreva logs.
2. Conter
   Desative temporariamente o recurso ou endpoint vulnerável.
   Coloque o host atrás de um controle de acesso (restrição de IP) ou desative o acesso público ao serviço.
3. Corrigir
   Atualize o sillytavern para v1.18.0 ou aplique a remediação recomendada pelo fornecedor.
4. Analisar
   Inspecione logs de acesso em busca de atividades suspeitas baseUrl valores, solicitações de proxy repetidas ou solicitações contendo alvos de IP privados.
   Verifique conexões de saída e consultas DNS originadas do host.
5. Rotacione segredos
   Se você tiver qualquer motivo para acreditar que metadados da nuvem ou credenciais foram expostos, gire chaves de API, tokens e credenciais de serviço.
6. Escaneie e limpe
   Execute uma verificação completa de malware e verificação de integridade no servidor para detectar possíveis artefatos pós-exploração.
7. Restaure e monitore
   Retome as operações normais apenas após ter certeza de que o sistema está limpo e endurecido. Aumente a monitoração por pelo menos 30 dias.
8. Relatar
   Onde necessário, notifique sua equipe de segurança, provedor de hospedagem ou clientes, dependendo de sua política de resposta a incidentes e obrigações regulatórias.

Detecção e exemplos de log para pesquisar

Pesquise seus logs (ou forneça essas consultas ao seu provedor de hospedagem) em busca de sinais de tentativa de exploração:

• Solicitações com parâmetros:
  • ?baseUrl=
  • ?proxy= ou ?target=
  • Corpos POST/JSON contendo baseUrl ou proxy_url
• Valores em parâmetros contendo:
  • 169.254.169.254
  • 127.0.0.1 ou localhost
  • 10. / 172.16.–172.31. / 192.168.
  • fe80: ou ::1
  • @ (indicando credenciais incorporadas)
• Picos repentinos em solicitações de saída para faixas privadas originadas do IP do seu servidor web.
• Logs do WAF mostrando as assinaturas mencionadas acima sendo acionadas repetidamente.

Coletar e correlacionar essas descobertas em logs de web, rede e DNS.

Por que a atualização ainda é o passo mais importante

Regras do WAF, filtragem de saída e restrições de host reduzem o risco, mas são controles compensatórios. A verdadeira solução é corrigir o software vulnerável. Patches virtuais podem falhar se os atacantes alterarem suas cargas, ou se usos legítimos forem necessários. Atualizar para sillytavern v1.18.0 elimina a vulnerabilidade na fonte e reduz sua superfície de ataque a longo prazo.

Como o WP‑Firewall ajuda a proteger ambientes WordPress

No WP‑Firewall, focamos em combinar regras gerenciadas, detecção proativa e remediação fácil para proteger sites WordPress e a infraestrutura ao redor deles:

• Assinaturas gerenciadas: nossas atualizações de regras incluem padrões de detecção de SSRF e heurísticas ajustadas para bloquear tentativas de explorar não validadas baseUrl ou parâmetros de proxy.
• Correção virtual: quando uma vulnerabilidade urgente é divulgada, o WP‑Firewall pode implantar patches virtuais através do WAF para reduzir a exposição enquanto você planeja atualizações de código.
• Verificação de malware: nós escaneamos em busca de indicadores de comprometimento e mudanças suspeitas que podem seguir um pivô SSRF.
• Controle de saída e de taxa: O WP‑Firewall pode ser configurado para limitar endpoints suspeitos e detectar padrões incomuns de solicitações de saída.
• Orientação e suporte a incidentes: nossos especialistas fornecem orientação de remediação passo a passo e podem ajudá-lo a interpretar logs e responder a incidentes.

Combine as proteções do WP‑Firewall com o patch do fornecedor (v1.18.0) e o endurecimento da rede do host para a melhor defesa.

Lista de verificação de configuração segura (resumo)

• Atualize sillytavern para v1.18.0 (ou posterior).
• Ative as regras gerenciadas do WP‑Firewall e assegure que as atualizações automáticas de assinatura estejam ativadas.
• Implemente regras do WAF bloqueando baseUrl apontando para faixas privadas, IPs de metadados e credenciais incorporadas.
• Restringir o acesso à rede de saída para processos web; bloquear endpoints de metadados em nuvem de processos de aplicativo.
• Revise o código do aplicativo para quaisquer outros parâmetros de URL fornecidos pelo usuário e endureça conforme necessário.
• Monitore logs para uso suspeito de proxy e implemente alertas para conexões de saída anômalas.
• Rotacione credenciais se metadados ou endpoints internos puderam ter sido acessados.
• Realize uma investigação completa e uma varredura de malware se a exploração for suspeita.

Inscreva-se para proteção imediata: Comece com o Plano Gratuito do WP‑Firewall

Proteja seu site rapidamente com o Plano Gratuito do WP‑Firewall

Se você ainda não está protegido, o plano Básico (Gratuito) do WP‑Firewall é uma excelente maneira de obter mitigação imediata enquanto você atualiza componentes vulneráveis. O plano gratuito inclui proteções essenciais, como um firewall de aplicativo web gerenciado (WAF), scanner de malware, largura de banda ilimitada e mitigação para os riscos do OWASP Top 10 — tudo o que é necessário para bloquear padrões comuns de exploração SSRF e reduzir a exposição imediata. Você pode se inscrever e habilitar a proteção rapidamente em:

https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Se você deseja automação adicional (remoção automática de malware, blacklist/whitelist de IP) ou recursos avançados (relatórios de segurança mensais, patching virtual automático e serviços de segurança gerenciados), considere atualizar para nossos níveis Standard ou Pro como seu próximo passo.

Considerações finais

As vulnerabilidades SSRF são poderosas porque transformam seu próprio host em uma plataforma de reconhecimento e ataque. Para proprietários e operadores de sites WordPress que compartilham infraestrutura com serviços Node.js ou executam ambientes mistos, este problema de SSRF do SillyTavern é um lembrete oportuno para:

• Aplique o patch imediatamente.
• Usar WAFs para fornecer patches virtuais rápidos.
• Reforçar regras de saída e segmentação de rede.
• Monitorar logs e estar pronto para responder.

Se você precisar de assistência para avaliar a exposição ou aplicar mitigação guiada, a equipe de segurança do WP‑Firewall pode ajudá-lo a aplicar patches virtuais, criar regras de WAF personalizadas e conduzir investigações. Comece com o plano gratuito para adicionar proteção rapidamente e entre em contato com nossa equipe para suporte mais profundo se você encontrar indicadores de exploração.

Fique seguro — mantenha o software atualizado, valide entradas e minimize o que cada servidor pode fazer na rede.