arturo0x90/cve-2026-51385Avis pour CVE-2026-51385. Nécessaire pour le publier car GRAPHIFY n'a pas reconnu l'avis ni ne l'a publié, et MITRE a attribué CVE-2026-51385 ; ceci est l'avis correspondant.
Avis de sécurité pour CVE-2026-51385. Il était nécessaire de le publier, car GRAPHIFY n'a ni reconnu ni publié l'avis, et MITRE a attribué CVE-2026-51385 ; voici l'avis correspondant.
ES: C'était mon premier CVE ; pour être honnête, j'ai trouvé un moyen de casser la logique de la fonction ANTI SSRF, et je voulais vraiment publier mon premier CVE. J'ai donc réfléchi à la manière dont cela pouvait affecter la sécurité pour en démontrer l'impact, même si l'exploitation était complexe (il est difficile que cela se produise sur une instance réelle, mais c'est possible, d'où la complexité élevée). Je l'ai envoyé à MITRE et ils l'ont accepté. Ceci est l'avis.
EN: C'était mon premier CVE ; pour être honnête, j'ai trouvé moi-même le moyen de casser la logique de la fonction anti-SSRF, et je voulais vraiment publier ce CVE. J'ai donc réfléchi à la manière dont cela pouvait affecter la sécurité, j'ai trouvé une justification, je l'ai envoyé à MITRE et ils l'ont accepté. Ceci est l'avis.
Gardez à l'esprit que le rapport a été partiellement rédigé avec de l'IA, mais supervisé par un humain
SSRF via rebinding DNS (TOCTOU) dans graphify.
Paquet : graphify (PyPI : graphifyy), dépôt Graphify-Labs/graphify
Composant concerné : le chemin d'ingestion des URL, graphify add <url>
Versions concernées : >=0.3.2, <=0.4.29
Corrigé dans : 0.5.4 (commit dd86271, PRs #591 / #592)
CVSS 3.1 : 8,3 (Élevé), CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
CWE : CWE-918 (SSRF), CWE-367 (course TOCTOU)
Signaleur : Arturo Melgarejo Galindo, chercheur en sécurité indépendant (@Arturo0x90)
graphify add <url> tente de se protéger contre les SSRF comme le font beaucoup de récupérateurs : il résout le nom d'hôte, confronte l'IP obtenue à une liste noire (loopback, RFC1918, link-local, réservées) et ne récupère le contenu que si ce contrôle est validé.
Le problème est que l'IP validée n'est pas celle à laquelle il se connecte. La validation effectue une première résolution DNS, puis requests.get(hostname) en effectue une seconde, indépendante. Si vous contrôlez la zone DNS du nom d'hôte et que vous renvoyez un TTL très bas avec deux enregistrements A, l'un public et l'autre interne, le résolveur peut légitimement donner une réponse différente à chaque requête. La première réponse passe la liste noire. La seconde réponse est celle vers laquelle la socket se connecte réellement. C'est tout le bug. C'est le contournement classique par rebinding contre la logique « vérifier l'IP, puis se connecter par nom », et le correctif consiste à épingler l'IP validée à la connexion, ce que fait 0.5.4.
Je veux être honnête à ce sujet, car pris isolément, ce bug semble plus faible qu'il ne l'est.
Si un humain s'installe et tape une URL en laquelle il a déjà confiance dans graphify add, ce bug est pratiquement sans intérêt. Cette personne peut déjà pointer graphify vers son propre 127.0.0.1 si elle le souhaite. Elle n'a pas besoin d'une astuce de rebinding pour cela, et aucun attaquant n'entre en jeu dans ce scénario.
Cela devient une véritable vulnérabilité dès lors que graphify traite une URL que l'opérateur n'a pas choisie. Et pour cet outil, ce n'est pas un cas limite, c'est la manière normale de l'utiliser. graphify construit des graphes de connaissances consommés par des assistants IA, donc le scénario réaliste est un processus qui appelle graphify add à votre place : un agent, un job CI, un script qui parcourt une liste d'URL tirées d'un README, ou une URL provenant directement de la sortie d'un autre modèle. Dans tous ces cas, l'attaquant contrôle la chaîne d'entrée et l'humain ne l'a jamais inspectée.
C'est le cas qui compte. Dès que l'entrée n'est pas fiable et que la course au rebinding est gagnée, la récupération aboutit sur une adresse interne au lieu de l'adresse publique validée. Concrètement, elle peut atteindre :
127.0.0.1 et tout ce qui est lié à loopback,169.254.169.254 (métadonnées d'instance cloud),100.64.0.0/10, qui n'est pas du tout couverte par la liste noire : celle-ci n'a donc même pas besoin de la course, un simple enregistrement A pointant vers elle suffit.Et le fait d'atteindre ces adresses ne cause de dégâts que par ce qui s'y trouve. Beaucoup de services internes et de développement exposent des endpoints GET qui soit renvoient des données, soit modifient l'état sur un simple GET. Une récupération graphify qui atterrit sur l'un d'eux, avec le mauvais chemin et la mauvaise chaîne de requête, n'est donc pas qu'une simple lecture. Si la cible interne est un scriptText Jenkins, un débogueur Flask/Django en --debug, un panneau d'administration ou un endpoint de métadonnées, ce GET malformé est l'attaquant agissant depuis l'intérieur du périmètre. graphify est le relais qui exécute la requête à sa place.
Je ne prétends pas que cela fournisse une RCE. Ce n'est pas le cas, en soi. Mais une SSRF complète, qui peut être pointée vers loopback, IMDS, RFC1918 et CGN depuis un chemin d'ingestion automatisé, est exactement la primitive sur laquelle ces attaques s'appuient, et c'est tout l'intérêt de ce rapport.
J'ai utilisé le harnais public rbndr.us de Tavis Ormandy, qui vous donne un nom d'hôte qui bascule entre deux IP à chaque résolution. 7f000001.08080808.rbndr.us alterne entre 8.8.8.8 et 127.0.0.1.
Démarrez quelque chose sur la cible interne (ici, loopback, pour la démonstration) :
sudo python3 -m http.server 80
Ensuite, déclenchez l'ingestion et réessayez jusqu'à ce que la course aboutisse. Elle réussit environ une fois sur quatre ou cinq tentatives, et une simple boucle fait passer ce taux bien au-delà de 99 % :
for i in {1..20}; do
graphify add http://7f000001.08080808.rbndr.us/ && break
sleep 1
done
Lors d'une tentative gagnante, graphify ingère tout ce que le serveur local sur 127.0.0.1:80 a renvoyé, même si le nom d'hôte a d'abord passé la liste noire d'IP.
0.5.4 (dd86271), 8 jours plus tard.Arturo Melgarejo Galindo, chercheur en sécurité indépendant.