arturo0x90/cve-2026-51385Advisory for CVE-2026-51385. Needed to publish it as GRAPHIFY hasnt recognized the advisory neither publish it, and MITRE assigned CVE-2026-51385, this is the advisory for it.
Advisory for CVE-2026-51385. Needed to publish it as GRAPHIFY hasnt recognized the advisory neither publish it, and MITRE assigned CVE-2026-51385, this is the advisory for it.
ES: Este fue mi primer cve, para ser honesto encontre una manera de romper la logica en la funcion ANTI SSRF, y realmente queria publicar mi primer CVE asi que pense como podria afectar a la seguridad para demotrar impacto, aunque fuera compleja de ejecutar (es complicado que esto ocurra en una instancia real, pero posible por eso tiene complexity high). Lo envie al mitre y lo aceptaron. Este es el advisory.
EN: This was my first CVE, to be honest i found myself the way to brake the logic in the anti-SSRF function, and i really wanted to publish the CVE so i tough how it could affect the security, and found a justification, send it to MITRE and they accept it. This is the advisory.
Keep in mind the report was partially made with AI, but supervised by a human
SSRF via DNS rebinding (TOCTOU) in graphify.
Package: graphify (PyPI: graphifyy), repo Graphify-Labs/graphify
Affected component: the URL ingestion path, graphify add <url>
Affected versions: >=0.3.2, <=0.4.29
Fixed in: 0.5.4 (commit dd86271, PRs #591 / #592)
CVSS 3.1: 8.3 (High), 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 (TOCTOU race)
Reporter: Arturo Melgarejo Galindo, independent security researcher (@Arturo0x90)
graphify add <url> tries to protect itself from SSRF the way a lot of fetchers do: it resolves the hostname, checks the resulting IP against a blocklist (loopback, RFC1918, link-local, reserved), and only fetches if that check passes.
The problem is that the IP it validated is not the IP it connects to. The validation does one DNS lookup, and then requests.get(hostname) does a second, independent one. If you own the DNS zone for the hostname and hand back a very low TTL with two A records, one public and one internal, the resolver can legally give a different answer on each query. First answer passes the blocklist. Second answer is where the socket actually goes. That's the whole bug. It's the classic rebinding bypass against "check the IP, then connect by name" logic, and the fix is to pin the validated IP to the connection, which is what 0.5.4 does.
I want to be honest about this, because on its own it looks weaker than it is.
If a human sits down and types a URL they already trust into graphify add, this is close to worthless. That person can already point graphify at their own 127.0.0.1 if they want to. They don't need a rebinding trick for it, and there's no attacker in that picture.
It becomes a real vulnerability the moment graphify runs against a URL the operator didn't choose. And for this tool that isn't a corner case, it's the normal way it gets used. graphify builds knowledge graphs that get consumed by AI assistants, so the realistic flow is some process calling graphify add on your behalf: an agent, a CI job, a script that walks a list of URLs from a README, or a URL that came straight out of another model's output. In all of those, the attacker controls the input string and the human never inspected it.
That's the case that matters. Once the input is untrusted and the rebinding race is won, the fetch lands on an internal address instead of the public one it validated. Concretely it can reach:
127.0.0.1 and anything bound to loopback,169.254.169.254 (cloud instance metadata),100.64.0.0/10, which the blocklist doesn't cover at all, so that one doesn't even need the race, a plain A record pointing into it is enough.And reaching those addresses only turns into damage because of what lives there. A lot of internal and dev services expose GET endpoints that either hand back data or change state on a bare GET. So a graphify fetch that lands on one of them, with the wrong path and query string, isn't just a read. If the internal target is a Jenkins scriptText, a Flask/Django debugger in --debug, an admin panel, or a metadata endpoint, that malformed GET is the attacker acting from inside the perimeter. graphify is the deputy that makes the request for them.
I'm not claiming this ships an RCE. It doesn't, by itself. But a full SSRF that can be pointed at loopback, IMDS, RFC1918 and CGN from an automated ingestion path is exactly the primitive those attacks are built on, and that's the point of reporting it.
I used Tavis Ormandy's public rbndr.us harness, which gives you a hostname that flips between two IPs on each resolution. 7f000001.08080808.rbndr.us alternates between 8.8.8.8 and 127.0.0.1.
Start something on the internal target (here, loopback, for the demo):
sudo python3 -m http.server 80
Then trigger the ingestion and retry until the race lands. It hits roughly 1 in 4 or 5 tries, and a trivial loop pushes that well past 99%:
for i in {1..20}; do
graphify add http://7f000001.08080808.rbndr.us/ && break
sleep 1
done
On a winning attempt, graphify ingests whatever the local server on 127.0.0.1:80 returned, even though the hostname passed the IP blocklist first.
0.5.4 (dd86271), 8 days later.Arturo Melgarejo Galindo, independent security researcher.