CVE-2026-34207

O filtro SSRF verificava o texto do hostname, mas o destino real era decidido mais tarde pelo DNS. Essa lacuna permitia que URLs de Webhook controladas pelo atacante alcançassem loopback, metadados e alvos de rede privada.

Introdução

Encontrei esse problema ao revisar Typebot, um construtor de chatbots open-source, com uma simples questão de segurança em mente:

O que acontece se a proteção SSRF valida o texto do hostname, mas o destino real é decidido mais tarde pelo DNS?

Neste caso, essa questão levou a um bug real.

A proteção SSRF do Typebot para blocos Webhook / HTTP Request validava apenas:

• a string da URL,
• hostnames literais bloqueados,
• e formatos literais de IP

Ela não resolvia hostnames antes de permitir a requisição.

Isso significava que um hostname como ssrf-repro.example poderia parecer inofensivo durante a validação, mas depois resolver para:

• 127.0.0.1
• 169.254.169.254
• ou espaço de rede RFC1918/rede privada

e ainda ser obtido pelo cliente HTTP do backend.

Esse problema se tornou CVE-2026-34207.

Typebot: Typebot no GitHub
CVE: CVE-2026-34207
Corrigido em: 3.16.0

Isso afetou Typebot, uma plataforma de chatbot open-source amplamente utilizada. Em seu site oficial, o Typebot é apresentado como confiável por 650+ empresas mundialmente. O site também anuncia 2M+ chats mensais e 1.5M+ bots publicados.

---

Cadeia de Ataque

attacker-controlled Webhook URL -> hostname passes literal-only SSRF validation -> no DNS resolution before allow decision -> backend HTTP client resolves hostname to internal target -> server-side request reaches loopback / metadata / private network -> response data becomes available through execution logs

---

O Que o Typebot Faz

Typebot é um construtor de chatbots.

Ele permite que usuários criem fluxos que podem:

• fazer perguntas
• coletar entrada estruturada
• chamar serviços externos
• encadear lógica de negócios
• e disparar requisições HTTP de saída através de blocos Webhook / HTTP Request

Isso significa que a execução de requisições de saída é uma fronteira de segurança real.

A questão importante aqui não era se o Typebot suportava blocos Webhook.

A verdadeira questão era:

A proteção SSRF valida o destino real ao qual o servidor se conectará, ou apenas o texto do hostname que aparece na URL?

Neste caso, ela validou apenas a forma textual primeiro.

Esse foi o erro.

---

Por Que Esta Superfície Valia a Pena Ser Examinada

Defesas SSRF falham de maneiras muito previsíveis.

Na maioria das vezes, os erros interessantes não são:

• "você esqueceu de bloquear 169.254.169.254"
• ou "você esqueceu de bloquear localhost"

Os erros mais fortes são erros de fronteira:

• validação ocorre antes da canonicalização
• validação ocorre antes de redirecionamentos
• validação ocorre antes da resolução DNS
• validação ocorre em uma representação, mas a pilha de rede usa outra

Esse era o lugar certo para olhar aqui.

O Typebot já possuía lógica de hardening SSRF para IPs de metadados literais, loopback, faixas privadas e truques de IP codificados.

Isso tornou a próxima pergunta óbvia:

E se o hostname não é literalmente perigoso, mas resolve para um destino perigoso mais tarde?

Foi exatamente o que aconteceu.

---

Causa Raiz

A raiz do problema foi validação de destino baseada no texto do hostname em vez do endereço IP resolvido.

Na implementação vulnerável, validateHttpReqUrl():

• analisava a URL
• permitia apenas http: e https:
• bloqueava uma pequena lista de hostnames literais como metadata.google.internal, metadata.goog, metadata e localhost
• detectava truques literais de IP decimal/hex/octal
• analisava endereços IPv4/IPv6 literais
• validava o endereço apenas se o próprio hostname já fosse um IP literal

Essa é a parte importante.

Se o hostname fosse um valor normal como:

ssrf-repro.example

então parseIPAddress(hostname) retornava null, e o validador parava por aí.

Nenhuma resolução DNS ocorria antes da aprovação.

Então a lógica vulnerável efetivamente se resumia a:

const ip = parseIPAddress(hostname);
if (ip) {
  validateIPAddress(ip);
}

Isso significa que:

• IPs literais perigosos eram bloqueados
• IPs codificados perigosos eram bloqueados
• mas hostnames que resolvem para IPs perigosos não eram

A segunda metade do bug estava no caminho de execução.

Em executeHttpRequest(), o Typebot primeiro executava a validação e depois realizava a requisição real com ky(request.url, ...).

Então a sequência era:

• validar a string da URL
• aceitar o hostname
• mais tarde resolver o hostname durante a requisição de saída real
• conectar ao destino interno resolvido

Essa é a vulnerabilidade completa.

---

Por Que Isso É um Problema de Segurança, Não Apenas Filtragem Incompleta

A distinção importante é onde a decisão de confiança foi tomada.

Muitos bugs parecem pequenos se descritos mal.

Se descrevermos este como:

"o filtro de hostname estava incompleto"

parece um problema de qualidade.

Esse não é o verdadeiro problema.

O verdadeiro problema era:

• o servidor tomou uma decisão de segurança antes de saber o destino real
• a pilha de rede depois se conectou a outro lugar
• e a aplicação tratou essa requisição como válida

Isso não é uma fraqueza cosmética de filtragem.

Isso é uma falha na fronteira de confiança.

E porque o executor HTTP gravava dados de resposta nos logs de execução, o problema nem era cego nos casos mais fortes.

Então não era apenas:

• "tráfego interno inesperado aconteceu"

Era:

• tráfego interno aconteceu
• e o atacante muitas vezes podia recuperar a prova e o conteúdo da resposta através do comportamento normal da aplicação

Isso é uma verdadeira vulnerabilidade SSRF.

---

Prova de Conceito

Usei duas camadas de prova porque demonstravam duas coisas diferentes.

PoC 1: demonstração autossuficiente com resolvedor local

A primeira PoC isolou a causa raiz de forma limpa.

Usei uma pequena estrutura local que:

• iniciava um servidor HTTP de loopback em 127.0.0.1
• validava uma URL como http://ssrf-repro.example:18080/...
• usava um resolvedor controlado para que ssrf-repro.example resolvesse para 127.0.0.1
• depois executava a requisição

Isso demonstrou a falha exata:

• a validação passou porque o hostname não era um valor literal bloqueado
• a requisição posterior ainda alcançou o loopback

A saída capturada mostrava:

• resultado do validador: aprovado
• resultado da execução da requisição: loopback alcançado
• corpo da resposta retornado pelo serviço de loopback

Isso comprovou a lacuna de validação diretamente.

---

PoC 2: caminho de execução real do Typebot

A segunda PoC mostrou o bug através do caminho real do recurso que importa.

A reprodução mais simples era:

1. Mapear um hostname benigno para loopback na máquina onde o backend do Typebot resolve DNS
2. Iniciar um serviço HTTP local
3. Criar um bloco Webhook apontando para esse hostname benigno
4. Acionar o bloco através de um caminho normal de pré-visualização autenticada ou execução ao vivo

Um bloco representativo se parecia com:

{
  "id": "blk-webhook",
  "type": "Webhook",
  "options": {
    "webhook": {
      "method": "GET",
      "url": "http://ssrf-repro.example:8000/"
    }
  }
}

Com uma entrada no arquivo hosts como:

127.0.0.1 ssrf-repro.example

o validador ainda aceitava a URL porque:

• ssrf-repro.example não estava em blockedHostnames
• não era localhost
• parseIPAddress("ssrf-repro.example") retornou null
• nenhuma validação de IP de destino ocorreu