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
What happened?
validateOriginHeader()andvalidateHostHeader()accept invalid header values containing URL userinfo when the hostname after@is allowlisted.Both helpers parse through
URLand compare only.hostname. URL parsing removes username and password components before returning the hostname, so these values currently pass localhost validation:Userinfo is not valid in a serialized
Originor HTTPHostfield. 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:
Ordinary hostnames, optional ports, IPv4, and bracketed IPv6 should remain accepted.
Code to reproduce
SDK version
@modelcontextprotocol/server@2.0.0-beta.4Area
Server