[v2] Origin and Host validators accept userinfo before allowlisted hostnames
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 65/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- typescript
Research direction
Search the server package for validateOriginHeader() and validateHostHeader(), then reproduce the userinfo examples from the issue. Done means both helpers reject userinfo while ordinary hostnames, optional ports, IPv4, and bracketed IPv6 remain accepted.
Written by the indexing model from the issue text.
Description
What happened?
validateOriginHeader() and validateHostHeader() accept invalid header values containing URL userinfo when the hostname after @ is allowlisted.
Both helpers parse through URL and compare only .hostname. URL parsing removes username and password components before returning the hostname, so these values currently pass localhost validation:
validateOriginHeader('http://user@localhost', ['localhost']);
// { ok: true, hostname: 'localhost', ... }
validateHostHeader('user@localhost:3000', ['localhost']);
// { ok: true, hostname: 'localhost' }
Userinfo is not valid in a serialized Origin or HTTP Host field. Invalid header syntax should be rejected before hostname allowlist matching.
Browsers do not normally generate an Origin containing userinfo or permit JavaScript to set Host directly. These public helpers may also receive values from proxies, custom transports, and non-browser clients, so accepting the values is still surprising at the parser boundary.
What did you expect?
Both values should be rejected as malformed headers:
validateOriginHeader('http://user@localhost', ['localhost']);
// { ok: false, errorCode: 'invalid_origin_header', ... }
validateHostHeader('user@localhost:3000', ['localhost']);
// { ok: false, errorCode: 'invalid_host_header', ... }
Ordinary hostnames, optional ports, IPv4, and bracketed IPv6 should remain accepted.
Code to reproduce
import {
localhostAllowedHostnames,
localhostAllowedOrigins,
validateHostHeader,
validateOriginHeader
} from '@modelcontextprotocol/server';
console.log(validateOriginHeader('http://user@localhost', localhostAllowedOrigins()));
console.log(validateOriginHeader('http://user:pass@localhost', localhostAllowedOrigins()));
console.log(validateHostHeader('user@localhost:3000', localhostAllowedHostnames()));
console.log(validateHostHeader('user:pass@localhost:3000', localhostAllowedHostnames()));
SDK version
@modelcontextprotocol/server@2.0.0-beta.4
Area
Server
- Dominant language
- TypeScript
- Stars
- 13.4k
- Forks
- 2.2k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 3
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/typescript-sdk
-
Auth metadata discovery: fallback URL built on resource host instead of authorization-server host Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
modelcontextprotocol/typescript-sdk#2783 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
modelcontextprotocol/typescript-sdk#2766 · 1 comment ·
-
Difficulty 2/5 1-2 days Newbie friendliness 72/100
All issues in modelcontextprotocol/typescript-sdk
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
EclipseFdn/open-vsx.org#13385 · 1 comment ·
-
S: triage
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Open
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
snapshot-labs/stamp#666 ·
-
vangogh
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
knaw-huc/textannoviz#691 ·