Description

WebFetch currently accepts http(s) URLs that contain a userinfo component, such as a username or password embedded before the host.

These URLs are not needed for normal WebFetch usage and can expose sensitive values in user-facing or diagnostic surfaces before the request is completed. WebFetch should reject this input during validation instead of allowing the raw URL to continue through the tool invocation flow.

Expected behavior

WebFetch should reject http(s) URLs that include embedded username or password components.

Examples:

• Accept: https://example.com/page
• Reject: https://user:[email protected]/page
• Reject: http://[email protected]/page

Actual behavior

The current validation accepts these URLs as long as they start with http:// or https://.

Suggested fix

Parse the URL in WebFetchTool.validateToolParamValues() and reject inputs where parsedUrl.username or parsedUrl.password is present.

Impact

This is a small information exposure hardening issue. Rejecting userinfo URLs prevents accidental exposure of embedded credentials through WebFetch validation, confirmation, logging, or error/reporting paths.

Additional context

This should be a small change with focused unit coverage in packages/core/src/tools/web-fetch.test.ts.

I would be happy to work on a small PR for this. Could this issue please be assigned to me?