IsValidRemoteURL only blocks literal localhost/127.0.0.1 — misses [::1], 127.0.0.0/8, 0.0.0.0, and private/link-local addresses
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
Research direction
Start in internal/validators/utils.go at IsValidRemoteURL and inspect the auth domain-verification dialer and validateRealmURL for existing address checks. Verify handling for loopback, unspecified, private, link-local, and IPv4-mapped addresses, then confirm that the listed local and internal URLs are rejected while existing public URLs remain valid.
Written by the indexing model from the issue text.
Description
IsValidRemoteURL (internal/validators/utils.go) is meant to reject remote URLs pointing at local/internal hosts ("stricter than packages - no localhost allowed"). The current host check is:
hostname := u.Hostname()
if hostname == "localhost" || hostname == "127.0.0.1" || strings.HasSuffix(hostname, ".localhost") {
return false
}
Because it compares string literals, it only catches localhost, 127.0.0.1, and *.localhost. These all currently pass validation:
IPv6 loopback: https://[::1]/
Rest of 127.0.0.0/8: https://127.0.0.2/
Unspecified: https://0.0.0.0/, https://[::]/
IPv4-mapped loopback: https://[::ffff:127.0.0.1]/
RFC1918 / link-local: https://10.0.0.1/, https://192.168.1.1/, https://169.254.169.254/
So a published server entry can register a remote URL pointing at loopback/internal addresses despite the intended restriction. This is also inconsistent with the codebase's own handling elsewhere (the auth domain-verification dialer already blocks these ranges, and validateRealmURL blocks 0.0.0.0/::).
Happy to send a PR that resolves the host with net.ParseIP and rejects loopback/unspecified/private/link-local addresses.
- Dominant language
- Go
- Stars
- 7.3k
- Forks
- 994
- Avg merge
- 4d 12h
- Merged PRs (30d)
- 19
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/registry
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
modelcontextprotocol/registry#1654 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
modelcontextprotocol/registry#1652 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
modelcontextprotocol/registry#1359 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
modelcontextprotocol/registry#1651 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
modelcontextprotocol/registry#1649 · 1 reaction ·
All issues in modelcontextprotocol/registry
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
priority: p3
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
googleapis/librarian#7636 ·