arturo0x90/cve-2026-51385Advisory para CVE-2026-51385. Necessário publicá-lo, pois o GRAPHIFY não reconheceu o advisory nem o publicou, e a MITRE atribuiu o CVE-2026-51385; este é o advisory para ele.
Advisory para CVE-2026-51385. Era necessário publicá-lo, pois o GRAPHIFY não reconheceu nem publicou o advisory, e a MITRE atribuiu o CVE-2026-51385; este é o advisory para ele.
ES: Este foi o meu primeiro CVE; para ser honesto, encontrei uma maneira de quebrar a lógica na função ANTI SSRF, e eu realmente queria publicar o meu primeiro CVE. Então pensei em como isso poderia afetar a segurança para demonstrar impacto, embora fosse complexo de executar (é complicado que isso ocorra em uma instância real, mas possível, por isso tem complexity high). Enviei para a MITRE e eles aceitaram. Este é o advisory.
EN: Este foi o meu primeiro CVE; para ser honesto, encontrei uma maneira de quebrar a lógica na função anti-SSRF, e eu realmente queria publicar o CVE. Então pensei em como isso poderia afetar a segurança e encontrei uma justificativa. Enviei para a MITRE e eles aceitaram. Este é o advisory.
Tenha em mente que o relatório foi parcialmente feito com IA, mas supervisionado por um humano
SSRF via DNS rebinding (TOCTOU) no graphify.
Pacote: graphify (PyPI: graphifyy), repositório Graphify-Labs/graphify
Componente afetado: o caminho de ingestão de URLs, graphify add <url>
(commit , PRs #591 / #592)
8.3 (Alto),
(SSRF), (corrida TOCTOU)
Arturo Melgarejo Galindo, pesquisador de segurança independente ()
>=0.3.2, <=0.4.290.5.4CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:Hgraphify add <url> tenta se proteger contra SSRF da mesma forma que muitos fetchers fazem: resolve o hostname, verifica o IP resultante contra uma lista de bloqueio (loopback, RFC1918, link-local, reservado) e só faz o fetch se essa verificação passar.
O problema é que o IP que ele validou não é o IP ao qual ele conecta. A validação faz uma consulta DNS, e depois requests.get(hostname) faz uma segunda, independente. Se você for dono da zona DNS do hostname e definir um TTL muito baixo com dois registros A, um público e um interno, o resolvedor pode legalmente dar uma resposta diferente a cada consulta. A primeira resposta passa pela lista de bloqueio. A segunda resposta é para onde o socket realmente vai. Esse é o bug inteiro. É o bypass clássico de rebinding contra a lógica "verificar o IP, depois conectar pelo nome", e a correção é fixar o IP validado à conexão, que é o que 0.5.4 faz.
Quero ser honesto sobre isso, porque, por si só, parece mais fraco do que é.
Se um humano senta e digita uma URL em que já confia no graphify add, isso é quase inútil. Essa pessoa já pode apontar o graphify para o próprio 127.0.0.1 se quiser. Ela não precisa de um truque de rebinding para isso, e não há atacante nesse cenário.
Ela se torna uma vulnerabilidade real no momento em que o graphify é executado contra uma URL que o operador não escolheu. E, para essa ferramenta, isso não é um caso extremo; é a forma normal de uso. O graphify constrói grafos de conhecimento que são consumidos por assistentes de IA, então o fluxo realista é algum processo chamando graphify add em seu nome: um agente, um job de CI, um script que percorre uma lista de URLs de um README, ou uma URL que veio diretamente da saída de outro modelo. Em todos esses casos, o atacante controla a string de entrada e o humano nunca a inspecionou.
Esse é o caso que importa. Uma vez que a entrada não é confiável e a corrida de rebinding é vencida, o fetch cai em um endereço interno em vez do endereço público que foi validado. Concretamente, ela pode alcançar:
127.0.0.1 e qualquer coisa vinculada ao loopback,169.254.169.254 (metadados de instância na nuvem),100.64.0.0/10, que a lista de bloqueio não cobre de forma alguma, então esse nem precisa da corrida; um registro A comum apontando para ele é suficiente.E alcançar esses endereços só se transforma em dano por causa do que vive neles. Muitos serviços internos e de desenvolvimento expõem endpoints GET que ou devolvem dados ou mudam estado em um GET simples. Então, um fetch do graphify que cai em um deles, com o caminho e a query string errados, não é apenas uma leitura. Se o alvo interno é um scriptText do Jenkins, um debugger Flask/Django em --debug, um painel administrativo ou um endpoint de metadados, esse GET malformado é o atacante agindo de dentro do perímetro. O graphify é o representante que faz a requisição por eles.
Não estou afirmando que isso entrega um RCE. Não, por si só. Mas um SSRF completo que pode ser apontado para loopback, IMDS, RFC1918 e CGN a partir de um caminho automatizado de ingestão é exatamente a primitiva sobre a qual esses ataques são construídos, e esse é o ponto de reportá-lo.
Usei o harness público rbndr.us de Tavis Ormandy, que fornece um hostname que alterna entre dois IPs a cada resolução. 7f000001.08080808.rbndr.us alterna entre 8.8.8.8 e 127.0.0.1.
Inicie algo no alvo interno (aqui, loopback, para a demonstração):
sudo python3 -m http.server 80
Em seguida, acione a ingestão e tente novamente até que a corrida dê certo. Ela acerta aproximadamente 1 em 4 ou 5 tentativas, e um loop trivial leva isso para bem além de 99%:
for i in {1..20}; do
graphify add http://7f000001.08080808.rbndr.us/ && break
sleep 1
done
Em uma tentativa bem-sucedida, o graphify ingere tudo o que o servidor local em 127.0.0.1:80 retornou, mesmo que o hostname tenha passado pela lista de bloqueio de IP primeiro.
0.5.4 (dd86271), 8 dias depois.Arturo Melgarejo Galindo, pesquisador de segurança independente.