The vulnerability is a Server-Side Request Forgery (SSRF) in the @utcp/http package, caused by a combination of insufficient URL validation and a failure to re-validate URLs at runtime. The registerManual functions across HttpCommunicationProtocol, SseCommunicationProtocol, and StreamableHttpCommunicationProtocol used a weak startsWith check for URL validation, which could be bypassed (e.g., http://localhost.evil.com). More critically, the HttpCommunicationProtocol.callTool function, which executes tool calls, did not perform any validation on the URL it was about to request. This URL was derived from an OpenAPI specification processed by OpenApiConverter.convert, which blindly trusted the servers[0].url field. This allowed an attacker to host a malicious OpenAPI specification on a legitimate HTTPS server, but with the servers[0].url pointing to an internal network address (e.g., http://169.254.169.254) or a loopback address. When the application would discover and then invoke this tool, the callTool function would make a request to the attacker-specified internal address, leading to SSRF. The patch rectifies this by introducing a robust, centralized URL validation helper (ensureSecureUrl) and applying it at two critical trust boundaries: during the initial manual discovery in all registerManual functions, and immediately before the HTTP request is made in callTool. Additionally, the OpenApiConverter was updated to prevent a remotely-hosted spec from declaring a loopback server, thus closing the loopback-redirect attack vector.